Le blog de nlehuby

Mar 21, 2017

Contribuez à OSM : les arrêts de bus sans nom

Les arrêts de bus qui n'ont pas de nom dans OpenStreetMap sont un de mes vieux TOC (troubles obsessionnels cartographiques). Déjà, en 2014, j'avais concocté un script qui permettait d'enrichir ces arrêts sans nom à partir de l'opendata RATP.

Aujourd'hui, je vous propose d'aller encore plus loin . Oui, vous !
Car ajouter le nom d'un arrêt, c'est ridiculement simple.

Voici un tutoriel en trois étapes :

Étape 1 : téléchargez MAPS.ME
N'oubliez pas de télécharger les cartes pour utilisation hors ligne et de vous authentifier dans les paramètres.

Étape 2 : cliquez sur le lien ci-dessous
pour télécharger la liste des arrêts de bus sans nom d'Île-de-France
Faites le depuis votre téléphone : cette liste devrait alors être chargée directement dans l'application MAPS.ME.

oh, la belle bleue

ici les signets rouges sont mes endroits (des adresses où je me rends souvent, des points de rendez-vous que j'ai enregistrés, etc) et les autres sont des arrêts de bus sans nom.

Étape 3 : contribuez !
Quand vous vous promenez et que vous passez à proximité d'un arrêt de bus sans nom, cliquez sur "Modifier le lieu" et renseignez son nom.

ajouter un nom sur un arrêt de bus, c'est très facile

Félicitations, vous faites partie de la communauté des bussophiles agguerris \o/

Allez hop hop, sur le terrain, la carte ne va pas se remplir toute seule et il reste encore 3277 arrêts de bus sans nom en Île-de-France !

Jan 21, 2017

Analyse des arrêts d'un parcours de bus

Quand je parle de mon trouble obsessionnel cartographique favori, les lignes de bus, les gens me demandent parfois si je trouve encore des choses à cartographier sur cette thématique, surtout en Île-de-France, où OSM est déjà très riche et densément mappé.
Mais c'est une fausse impression de complétude : il y a encore beaucoup à faire et bien que j'ai commencé en 2014 (souvenez-vous, je vous ai fait découvrir mes expériences sur ce blog), je continue de contribuer régulièrement sur cette thématique.

D'après le référentiel opendata du STIF, il y a plus de 1800 lignes (tous modes confondus) alors qu'à date dans OSM, on en a moins de 500.
Pourtant, il suffit de jetter un coup d'oeil au fond transport pour constater que les contributeurs sont très actifs sur cette thématique.
En effet, la donnée brute existe déjà en grande partie dans OSM, mais il reste pas mal de travail d'uniformisation sur les tags établis.
Car, cartographier une ligne de bus, ce n'est pas si facile ! Mais ça sera surement l'object d'un prochain article tutoriel ;)
Concentrons nous donc plutôt sur les arrêts.

Voici quelques captures des arrêts du parcours de la ligne 306 du réseau RATP en direction de Saint-Maur, dans l'opendata (le petit point en bout de flèche) et dans OSM (le picto à la base de la flèche) un arrêt OSM et son arrêt opendata associé

La distance entre les deux sources est très variable.
Pour certains, l'arrêt opendata est à moins de 10 mètres de l'arrêt OSM : un pas bien loin Mais dans d'autres, il faut rechercher à 150 mètres pour le retrouver : et un bien plus loin

Cette grande distance semble souvent imputable à la précision de géoloc des données opendata, mais il s'agit aussi parfois d'arrêt OSM positionnés approximativement (souvent signalés avec un tag FIXME : position à corriger).
Sans vouloir faire des généralisations hâtives, il semblerait qu'on constate assez systématiquement des grands écarts de distance sur les gares routières, où l'opendata se contente du centre de la gare. une gare routière

Mais malgré ça, on arrive quand même à trouver un arrêt opendata pour chaque arrêt OSM \o/
Deux exceptions :

  • Un arrêt manque à l'appel dans OSM : l'arrêt Rue du Monument. need survey
  • Des arrêts semblent être en trop dans OSM : il y a en effet trois arrêts Villiers-sur-Marne–Le Plessis-Trévise RER rattachés à ce parcours de bus.also need survey L'un est indiqué comme étant un arrêt de descente pour tous les bus, ce qui est en effet une pratique répendue dans les gares routières, mais l'un des deux autres est clairement en trop. Fausse manip d'un contributeur ou défaut de mise à jour ?

Bref, même sur cette ligne qui semble plutôt complète, il reste des imprécisions.

À noter qu'on trouve aussi de belles imprécisions dans l'opendata, avec :

  • des arrêts à l'intérieur de bâtiments c'est pratique ceci dit, d'attendre son bus au chaud
  • des arrêts pas situés dans la bonne rue bon courage pour choper ce bus si tu l'attends dans cette rue

Si vous souhaitez vous faire votre propre idée sur les lignes qui passent près de chez vous, voici quelques éléments pour reproduire mon analyse :
Pour les arrêt OSM, j'ai utilisé une extraction via l'API Overpass de type

relation({id de la relation});node(r:"{platform ou stop selon la version du schéma}");out meta;

Il vous faudra renseigner

  • l'id de la relation du parcours
  • "stop" s'il s'agit d'un parcours encore en public_transport:version = 1 ou "platform" s'il s'agit d'un public_transport:version = 2.

Pour les arrêts opendata, j'ai réalisé une extraction par parcours à l'aide de l'API navitia.io car filtrer les données opendata par parcours est un peu fastidieux. Cela me permet également de récupérer l'identifiant de l'arrêt dans le référentiel STIF dans la foulée.
Le script python est sur github.
On peut ensuite visualiser ça dans JOSM à l'aide du plugin opendata.

Pour faire le rapprochement entre l'opendata et OSM, j'ai utilisé le plugin conflation de JOSM.

Cette analyse est très orienté parcours, mais on peut imaginer qu'une fois que le référentiel des arrêts du STIF aura été proprement intégré dans OSM on pourra réaliser cela par quartier, ou tout autre découpage, géographique ou non.
Mais c'est un peu prématuré ... Sur le parcours en question, seuls 11 arrêts disposaient de leur identifiant STIF, et 4 étaient erronés.
argh, des ref:FR:STIF fausses La cause est difficile à déterminer à ce stade : il s'agit parfois de la référence d'un arrêt desservi par la ligne 306 dans l'autre sens, et parfois d'une référence qui n'existe pas ou plus dans le référentiel du STIF.

Bref, même en Île-de-France, il reste du boulot sur les arrêts de bus :)

Jul 24, 2016

Extraire des infos thématiques d'OSM

Quand on souhaite réaliser une analyse thématique à partir des données OSM, on passe forcément par l'étape de récupération des données. Pour cela, on a plusieurs solutions.

La plus simple pour se lancer, c'est d'utiliser Overpass, via Overpass Turbo.
J'en ai déjà parlé dans un précédent article : on donne nos contraintes et en un rien de temps, on a un résultat visuel et les objets qui nous intéressent ressortent sur la carte.
On peut alors récupérer directement ces objets ou bien la requête Overpass pour la faire exécuter par un autre applicatif (comme uMap par exemple, cf mon tutoriel sur le sujet)

À noter que l'API Overpass permet également de récupérer des objets au format csv, ce qui peut s'avérer pratique s'il s'agit d'une extraction pour analyse (et pas juste pour un affichage). Voici par exemple le nécessaire pour récupérer dans Overpass-Turbo les distributeurs de billets alentours, en csv :

[out:csv(::"id", ::lat, ::lon, operator)][timeout:25];
(
    node["amenity"="atm"]({{bbox}});
);
out ;

Bref, malgré une courbe d'apprentissage de la syntaxe un peu rude (Overpass Turbo et le wiki sont là pour aider), Overpass, c'est génial !

Cependant, dès qu'on souhaite requêter une trop grande quantité de données, une trop grande surface ou à une fréquence trop élevée, on se retrouve confrontés aux limites de l'API.

Dans ce cas de figure, la solution royale, c'est de récupérer directement toutes les données brutes d'OSM et de faire sa propre extraction à la main.

En général, on télécharge les données, au format pbf, sur Geofabrik par exemple.

Puis, une solution courante est d'insérer ces données en base (avec imposm ou osm2pgsql), puis de faire des requêtes SQL pour extraire les infos souhaitées.

Mais, lorsque l'extraction est assez simple, sachez qu'il existe une alternative en ligne de commande, basée sur Osmosis et Osmconvert.

On utilisera osmosis pour ne conserver dans les données que les objets qui nous intéressent.
Puis on utilisera osmconvert pour extraire ces objets au format csv.

Par exemple, si je souhaite extraire tous les distributeurs de billets (amenity = atm) des données OSM que j'ai téléchargées, je peux procéder ainsi :

osmosis --read-pbf file="data.osm.pbf" --nkv keyValueList="amenity.atm" --write-pbf atm.osm.pbf

À ce stade, j'ai obtenu un fichier pbf ne contenant que les noeuds taggés avec amenity = atm. Puis, pour avoir tout ça dans un format plus habituel et extraire uniquement les tags qui m'intéressent :

osmconvert atm.osm.pbf --csv="@id @lat @lon name operator network fee" --csv-headline --csv-separator=";" -o=osm_atm.csv

Et je peux aussi réaliser des unions : par exemple, admettons que je souhaite également récupérer les horloges publiques (amenity = clock) pour réaliser une analyse particulièrement innovante sur les distributeurs et les horloges ...
Je commence par procéder de même :

osmosis --read-pbf file="data.osm.pbf" --nkv keyValueList="amenity.clock" --write-pbf clock.osm.pbf

Puis, je fusionne mes deux fichiers précédemment obtenus en un seul :

osmosis --read-pbf atm.osm.pbf --read-pbf clock.osm.pbf --merge --write-pbf clock_and_atm.osm.pbf

Puis, je peux, comme précédemment utiliser osmconvert pour récupérer les objets et les tags utiles.

À noter que si on souhaite extraire autre chose que des noeuds, il reste possible d'utiliser osmosis, mais c'est un peu plus complexe.
La requête suivante permet par exemple de récupérer les parcours de bus (qui sont des relations taggées avec route=bus) :

osmosis --read-pbf data.osm.pbf --tf accept-relations route=bus --used-way --used-node --write-pbf route_bus.osm.pbf

On a alors un pbf contenant les relations parcours de bus, ainsi que tous les objets (chemins et noeuds) qui constituent ces relations.

Jun 23, 2016

OSM pour les noobs sur Android

Quand on connait OpenStreetMap et qu'on est sur Android, on pense tout de suite à OsmAnd. OsmAnd, c'est génial, c'est un véritable couteau suisse pour utiliser de la donnée OSM en situation de mobilité. La liste de ces fonctionnalités est énorme, et il m'arrive encore d'en découvrir une pratique par hasard au détour de clics dans l'appli.
J'ai même déjà réussi à trouver comment afficher tous les tags d'un noeud OSM ! Une fois.
Car oui, OsmAnd ça fait le café, mais quand même, c'est po si simple à utiliser.
Et pourtant l'ergonomie s'est beaucoup améliorée, l'appli fait plutôt moderne pour une appli opensource :p. Mais ça n'empêche, elle fait tellement de choses que pour trouver une fonctionnalité en particulier, des fois, c'est galère.

Moi, ça ne m'empêche pas de l'utiliser, mais lorsque je veux faire découvrir OSM à un non initié, je ne suis pas à l'aise avec l'idée de lui faire installer OsmAnd.
Soyons francs : notre capacité d'attention lorsqu'on teste une appli est limitée : si on ne trouve pas en un éclair comment ça fonctionne, on zappe, on désinstalle et on passe à la suite.
En tout cas, ce que j'ai pu constater avec mes acolytes.

Donc j'ai changé mon fusil d'épaule.
Ne serait-ce que parce que ça me choque de voir des gens utiliser G**gle Maps alors qu'il existe plusieurs alternatives sérieuses, et qui remplissent les 3 ou 4 fonctionnalités qu'on peut attendre de ce genre de services.
On pourrait citer Scout, ou Magical Earth par exemple. Pour ma part, j'ai opté pour Maps.me

Elle remplit les critères de base que j'ai fixé pour une appli Android à présenter lorsque je fais découvrir OSM :

  • elle permet de voir sa position sur une carte (la base quoi)
  • elle fonctionne hors ligne : on peut télécharger une zone géographique et jouir de cartes sans user sa connexion de données : c'est un peu la killer feature pour convaincre de tenter le coup.
  • elle permet de chercher des points d'intérêts : où sont les toilettes publiques les plus proches ? Où puis-je acheter mon pain en tant que touriste ?
  • elle permet de rechercher des adresses et de calculer des itinéraires piéton (je n'ai pas testé en voiture, je n'en ai pas trop l'usage, mais c'est également une fonctinnalité disponible)
  • elle permet de sauvegarder des lieux (comme l'adresse de ses amis)
  • elle est opensource (parce qu'éthiquement, c'est mieux, j'ai plus confiance donc je rechigne moins à la présenter à des gens)
  • elle a une ergonomie et une utilisabilité potable (parce que sinon, je sais qu'elle ne sera pas utilisée)

À noter qu'elle permet aussi, depuis peu, d'ajouter des points d'intérêts et de signaler des erreurs de carto.
L'interface est plutôt orientée débutants : on ne voit pas les tags OSM (ni même les objets OSM), mais on peut ajouter des infos de manière très simple et fluide.
Cela permet donc de montrer à notre OSM-noob le côté collaboratif afin de l'inciter, lui aussi, à ajouter la boite aux lettre ou la borne de recyclage manquante en bas de chez lui.

un point d'intérêt une recherche de points d'intérêts un itinéraire

Bref, une corde de plus à mon arc de prosélyte d'OpenStreetMap ;)

May 13, 2016

Faire une carte dynamique et éditable, avec MapContrib

Il y a deux ans, je voulais visualiser et modifier dans OSM les tags spécifiant les bières pression servies dans les bars.
Et c'était galère, alors j'ai fait un outil pour ça :  l'aventure OpenBeerMap a commencé.

Puis, il y a à peu près un an, j'ai voulu visualiser dans OSM où déposer mes déchets en verre pour les recycler.
Et c'était galère, alors j'ai fait un tuto expliquant comment faire une carte dynamique pour afficher facilement des données OSM.

Les choses bougent vite, la communauté OSM est très active : maintenant, il est devenu plutôt facile de réaliser ce genre de carte.
Je le dis, je le prouve : voici une carte des bouches de métro, avec un code couleur selon la complétude de l'info, réalisée en 10 minutes top chrono

L'outil qui a permis cela s'appelle MapContrib, et son job est de fabriquer des cartes dynamiques à partir des données OSM.
Et il permet également de modifier les données OSM affichées directement depuis la carte générée, de manière simple et efficace.

Si vous avez suivi mon tuto précédent, vous pouvez prendre en main MapContrib en un temps record : le concept est très similaire, on crée des calques de données, dans lequel on met une requête Overpass et ça marche tout seul.
Un peu de personalisation des marqueurs et hop, on a une carte partageable à diffuser à nos contributeurs !

Bref, plus le temps passe et moins vous avez d'excuses pour ne pas contribuer à OpenStreetMap ;)

Feb 23, 2015

[tuto] Faire une carte dynamique

Ce que j’apprécie particulièrement avec OpenStreetMap, c’est que c’est un écosystème très riche et qu’on peut découvrir chaque jour un nouveau truc génial à faire avec.

Voici un petit exemple d’une fonctionnalité que j’ai découverte récemment, et utilisée dans mon précédent article sur les points de collecte de recyclage de verre.

OpenStreetMap, c’est avant tout une grosse base de données. Mais pour mettre en évidence ces données, il faut avoir un certain niveau de connaissance d’OpenStreetMap.

Voici un solution simple pour afficher des données issues de la base OSM sur un fond de carte (OSM, évidemment), avec mise à jour automatique des données en fonction des modifications apportées sur la base par les contributeurs.

Voir en plein écran

Ici, une carte des boulangeries de Paris présentes dans OSM.

Pour récupérer les données, on utilisera par exemple l’API Overpass.

Et comme faire une requête Overpass qui fonctionne du premier coup est une opération un peu hasardeuse, on utilisera bien sûr Overpass Turbo.

Le tag pour une boulangerie est le suivant : shop = bakery

En utilisant le wizard d'Overpass Turbo, on obtient le résultat suivant :

image : export Overpass

Le résultat est ok, mais un peu moche.

Pour aller plus loin, on va afficher ces données dans uMap, un service opensource de création de carte personnalisable simple d’accès.

uMap permet en effet de choisir un fond de carte OSM et d’y ajouter des données de la provenance de son choix, de personnaliser un peu le design général, puis de partager sa carte.

Il nous faut donc indiquer à uMap où trouver les données à afficher.

Pour cela, dans Overpass Turbo : Exporter > Requête > format compact

image : overpass turbo

On obtient alors les paramètres, sous un format compact, à passer à l’API Overpass pour avoir un résultat.

Pour obtenir ce résultat, il faut passer ces paramètres à une instance Overpass (par exemple, l’instance mondiale « principale » ou l’instance française).

En concaténant les deux bouts de mon url, j’ai une requête que me retourne les données OSM au format json :

http://api.openstreetmap.fr/oapi/interpreter?data=[out:json][timeout:25]...

Muni de cette précieuse requête, allons sur uMap créer notre jolie carte !

Sur une carte, les données sont regroupées par « calque ».

Créons une carte.

Par défaut, elle contient un seul calque, vide, appelé calque 1.

Nous allons éditer ce calque pour y ajouter nos données récupérées via Overpass

image : édition du calque

Cliquons sur Données distantes

Dans le champ url, renseigner la requête Overpass, et sélectionner le format de données « osm »

Enfin, cocher la case « Dynamique »

image : dynamique

Vous devriez voir vos données s’afficher sur la carte.

C’est bien, mais … on peut mieux faire !

En effet, on aimerait bien pouvoir se déplacer sur la carte pour voir les boulangeries ailleurs que sur le petit coin que j’ai choisi.

Il faut donc indiquer à uMap de modifier la requête Overpass en fonction de l’endroit où se situe l’utilisateur sur la carte.

Cela se fait très simplement en remplacer toutes les occurrences des coordonnées dans la requête par les mots-clefs suivants {south},{west},{north},{east} qui sont interprétés par uMap.

La requête Overpass devient alors :

http://api.openstreetmap.fr/oapi/interpreter?data=[out:json][timeout:25];(node"shop"="bakery";way"shop"="bakery";relation"shop"="bakery";);out body;>;out skel qt;

Il ne reste plus qu’à personnaliser la carte selon nos goûts, nos envies et nos besoins : on peut changer le fond de carte, choisir des marqueurs plus jolis, etc

Ne pas oublier également de préciser la licence (ODbL, car utilisation de données OSM).

Puis, il ne reste plus qu’à partager sa carte avec le monde entier.

Pour cela, on peut soit fournir un lien, soit l’embarquer directement dans la page comme je l’ai fait ici

image : umap

Et voilà. C’est simple et efficace :)

Si vous avez des besoins plus sophistiqués, il faudra coder un peu et partir sur des solutions à bases de modules de Leaflet, telles que celles que j’ai mises en place pour OpenBeerMap.

Feb 01, 2015

Où recycler son verre ?

J'ai déménagé récemment. Et est arrivé le moment où j'ai envie de me débarrasser des bocaux et bouteilles de verre que j'ai descendus depuis mon arrivée.

Et surprise, pas de bac de recyclage pour le verre dans ma commune.

Le dépliant sur le recylage m'indique que je dois déposer tout ça dans l'un des 60 points de collecte de la ville.

Ok, c'est cool, mais ça me fait une belle jambe...

En effet, un container de collecte de verre usagé, c'est un élément de mobilier urbain qu'on ne remarque que si on est en train d'en chercher un ... On peut passer à côté tous les jours et ne même pas le remarquer.

Et c'est exatement ce qui m'est arrivé : là comme ça, je serais bien incapable de savoir où est le plus proche de moi.

Mais là où il y a un problème de données, il y a une solution dans OSM.

Une petite requête overpass plus tard, je découvre que je passe tous les jours devant un bac de collecte pour aller travailler, et assez régulièrement devant un second.

Et comme ce n'est pas la première fois que je me retrouve confrontée à ce genre de situation (par exemple en vacances, loin de chez soi, dans un endroit où la collecte du verre se fait également dans des bacs répartis dans la ville) et que je ne suis surement pas la seule à avoir ce genre de problèmes, je nous ai conconcté une petite carte de tous les points de collecte du verre cartographiés dans OSM :

Voir en plein écran

May 19, 2014

OpenBeerMap – où trouver ma bière préférée ?

Parfois, lorsque je sors avec des acolytes, on se retrouve dans un bar qui sert une bière blonde dégueulasse tout juste bonne à faire des panachés classique, et on découvre en sortant que le bar d’à côté sert de la bière belge d’abbaye.

Je ne suis pas une grande amatrice de bière, mais je trouve ça plutôt frustrant.

Et qui dit frustration dit besoin sous-jacent.

Et qui dit besoin dit « il me faut une application pour ça ! »

Bref, c’est ainsi qu’il m’est venu l’idée de faire une carte affichant les bars et les bières qui y sont servies, à partir des données OpenStreetMap bien sûr !

Le résultat est visible ici : http://openbeermap.github.io/

Voici comment ça s’est déroulé.

Bon, j’ai commencé par apprendre les bases du javascript (parce que mon langage de prédilection, c’est plutôt le python, mais c’est quand même nettement moins adapté pour faire des cartes sur le web).

Je suis parti d’un plugin Leaflet (qui est un bibliothèque javascript efficace pour afficher des cartes) pour afficher des données à partir de l’API Overpass.

L’API Overpass (qui est testable sur cet IDE (http://overpass-turbo.eu/) permet de faire des requêtes sur les données OSM avec toutes sortes de filtres.

Dans mon cas, c’est amenity = pub (ou bar ou cafe) et brewery = {nom de ma bière}

Assez rapidement et sans y connaitre grand-chose, j’ai pu faire une joli carte avec des cases à cocher pour les différents types de bière :

image : OBM

Puis, j’ai intégré tout ça dans BootLeaf, une template basé sur Leaflet et Bootstrap, afin d’avoir quelque chose de responsive et surtout de plus joli, notamment sur mes info-bulles

image : OBM

Puis, je me suis rendue compte que j’avais pas beaucoup de bars où l’information était fournie …

Un petit tour sur Taginfo m’apprend qu’il n’y a que 15 objets dans OSM sur toute la France avec le tag brewery de renseigné !

Autant dire qu’il y a du travail de contribution à prévoir si je veux que mon site ait vraiment un intérêt.

Du coup, j’en profite pour rajouter un petit formulaire permettant de renseigner directement sur le site les bières dispo, et les autres infos pertinentes (pour l’instant, j’ai retenu uniquement nom du bar, accès wifi, heures d’ouverture et heures d’happy hours) :

image : OBM

Les informations saisies dans le formulaires partent directement enrichir la base de données OpenStreetMap, ce qui me permet de les re-consommer derrière pour afficher quelles bières sont dispo : un cercle vertueux à consommer sans modération ;)

C'était la partie la plus délicate à réaliser pour moi qui n'était pas familière avec l'API d'édition d'OSM et toute la cinématique nécessaire pour réaliser des modifications ... D'ailleurs, la gestion des conflits a été soigneusement éludée pour le moment...

Bon, j’ai finalement temporairement retiré les heures (opening_hours et happy_hours) car je pense qu’un simple champ texte n’est pas très adapté pour enrichir ce type de donnée : j’oublie moi-même tout le temps le format de ce tag et je n’ai pas très envie d’implémenter une vérification du format dans le formulaire, donc ce n’est pas optimal … affaire à suivre.

Maintenant, y a plus qu’à !

Je compte sur vous pour participer et ajouter les bières servies dans vos débits de boisson favoris.

Et sinon, c’est tout open-source, et toute contribution est la bienvenue !

Par exemple, si une âme charitable avec des compétences en graphisme pouvait me fournir des images (en SVG et libre de droit) des verres à bières, ça serait merveilleux. J’ai essayé de dessiné le verre de la Kwak … mais j’ai renoncé !

EDIT : c'est chose faite, tout juste 4 mois après le lancement du projet : Affligem, Carmélite Triple, Chouffe, Guinness et même Kwak ont leurs icônes intégrées dans OpenBeerMap 

image : kwak

Et l'ergonomie pourrait être améliorée sur le choix des bières (aussi bien sur l'affichage que la contribution) j'imagine.

EDIT : pour suivre l'actualité d'OpenBeerMap, suivez le mot-dièse #OpenBeerMap et le journal OSM https://www.openstreetmap.org/user/OpenBeerMapContributor/diary

May 16, 2014

Ordre des arrêts de bus dans OSM

Oui, encore un article sur les lignes de bus dans OSM ! Promis, après j'arrête. D'ailleurs, je fais faire très court !

Toujours dans l'idée d'enrichir et d'améliorer la qualité des données OSM à l'aide des données opendata disponibles dans navitia, voici un quick hack, facile et, si j'ose dire, à la portée de n'importe qui :p

Prenons, par exemple, la ligne 325 de la RATP : c'est une ligne très simple, sans fourche ou boucle ou autres joyeusetés.

Dans OSM, elle est plutôt pas mal cartographiée, on a l'essentiel des routes et une grande partie des arrêts.

Mais, en utilisant sketch-line (l'outil de génération de thermomètre de ligne à partir des données OSM), le résultat est ... décevant ...

image : bus 325 dans le désordre

source : http://overpass-api.de/api/sketch-line?network=RATP&ref=325&style=paris%C2%A0

Déjà, OSM n'arrive même pas clairement à déterminer son origine et sa destination ... Ensuite, ses parcours ont l'air assez chaotiques.

C'est un cas typique où les arrêts sont mal ordonnés dans les relations (car oui, les relations sont ordonnées ! relisez la partie théorique de mon article sur la carto d'une ligne de bus si vous avez un doute).

Comment remédier à tout ça et avoir nettoyer la donnée dans OSM ?

En utilisant navitia.io évidemment :p

Pas de script cette fois-ci, juste un appel pour récupérer l'ordre des dessertes :

image : bus 325 dans navitia.io

Puis, il suffit de regarder ce qu'il y a dans OSM et de corriger si nécessaire dans JOSM (car l'éditeur iD ne permet pas de modifier l'ordre des éléments dans une relation) :

image : bus 325 dans le désordre

On peut aussi en profiter pour corriger les fautes dans les noms (Brunesseau ou Bruneseau ? École vétérinaire de Maisons Alfort ou Maisons Alfort école vétérinaire ? etc)

C'est un peu long mais pas difficile. 

Et assez rapidement, on se retrouve avec un thermomètre de ligne tout beau tout propre, et surtout qui reflète nettement mieux la réalité !

image : bus 325 tout bien

Apr 29, 2014

Script d’intégration des arrêts de bus dans OSM à partir de navitia.io

Vous l'aurez compris, mon TOC (trouble obsessionnel cartographique) du moment, c'est les arrêts de bus !

Et en travaillant sur le projet KartoKartier, avec mes collègues, dans le cadre du concours Cartoviz, je me suis rendue compte qu'il y avait une belle marge de manoeuvre pour améliorer la qualité des données OSM pour les arrêts de bus : j'en parlais ici.

C'est ainsi que je me suis mise en tête de faire un script qui se nourrit de l'opendata RATP  via l'API navitia.io, pour enrichir les données OSM en ajoutant, pour commencer, les noms des arrêts manquants.

Ce script est disponible sur github, et librement réutilisable.

Que fait ce script ?

Tout d’abord, il récupère la liste de tous les arrêts de bus, situé dans la ville de Paris (par exemple), qui n’ont pas de nom renseigné.

J'ai commencé par l'utiliser sur des villes plus proches de la mienne, voici quelques métriques :

  • nombre d’arrêts sans nom à Paris : 267
  • nombre d’arrêts sans nom à Boissy-Saint-Léger : 21
  • nombre d’arrêts sans nom à Sucy-en-Brie : 38
  • nombre d’arrêts sans nom à Créteil : 25
  • nombre d’arrêts sans nom à Bonneuil-sur-Marne : 3

Ensuite, pour chacun de ces arrêts, j’appelle navitia.io (une API pour les transports en commun, développée par Canal TP, et qui s'alimente, entre autres, des données opendata RATP) et je lui demande de me retourner les points d’arrêts à proximité des coordonnées du point OSM.

Les données opendata de la RATP, qui sont utilisées dans navitia.io ont une géolocalisation peu précise, donc en faisant varier la distance d’accroche, on obtient des résultats plus ou moins pertinents :

Métriques sur Paris :

  • Nombre d’arrêts OSM ayant un arrêt RATP à moins de 100 mètres : 249
  • Nombre d’arrêts OSM ayant un arrêt RATP à moins de 50 mètres : 221
  • Nombre d’arrêts OSM ayant un arrêt RATP à moins de 20 mètres : 145
  • Nombre d’arrêts OSM ayant un arrêt RATP à moins de 10 mètres : 74

Sur ces arrêts, j’ai choisi, dans un premier temps, de ne conserver que
ceux qui ont un unique arrêt RATP (ou plusieurs arrêts avec le même nom)
ce sont les plus faciles à intégrer.

Pour ceux-là, je crée un fichier JOSM avec le nom pré-rempli.

Il n’y a plus alors qu’à ouvrir le fichier dans JOSM, à charger les données existantes autour du point, à vérifier que les infos sont cohérentes, puis à envoyer la modification dans OSM.

image : retour

exemple de retour du script

image : retour du script sur Boissy

ci-dessus, le retour du script sur Boissy-St-Léger : il n'y a un seul arrêt RATP (l'arrêt noctilien que j'ai cartographié [dans l'article précédent)]({filename}retour-dexperience-cartographie-osm-de-quelques-lignes-de-bus.md), et il a déjà un nom !

Dans la pratique, l’intégration :

J’ai choisi d’y aller itérativement, et de commencer par les moins ambigus, donc ceux ayant un arrêt RATP très proche. J'ai aussi choisi de commencer par ceux proches de chez moi, pour pouvoir faire une vérification sur le terrain en cas de doute.

Les premiers arrêts que j'ai intégrés étaient parfaits : c'est le cas typique

  • où navitia a trouvé une correspondance entre mon arrêt sans nom et les données opendata
  • où il n'y a que deux arrêts de bus dans tout le quartier, placé chacun d'un côté de la route (le sens aller et le sens retour)
  • le second arrêt a déjà un nom, et c'est le même que celui trouvé par navitia
  • éventuellement, mon arrêt a un tag name:RATP rempli, et concordant (mais il a peut-être été aussi généré par un script, je ne sais pas si c'est vraiment une mesure de fiabilité)

Là, on peut intégrer les yeux fermés :)

Malheureusement, c'est loin de représenter la majorité des cas ...

À vrai dire, j'ai même trouvé une bonne poignée d'exemples carrément invalides (c'est le cas de le dire) : par exemple, cet arrêt

image : cet arrêt

Il est situé à 16 mètres d’un arrêt de bus que l’opendata RATP appelle Invalides.

Mais, dans les données déjà présentes sur OSM, il est indiqué que c’est un arrêt desservi par les cars Air France.

En conséquence, navitia, alimenté par des données opendata RATP et SNCF (et pas Air France) n’est pas une source fiable pour me fournir le nom de l’arret.

Ça ne veut pas dire que l'arrêt ne s'appelle pas Invalides, mais à moins d'aller voir sur place, je ne peux pas en être certaine ...

On l'oublie souvent, mais il n'y a pas que la RATP comme opérateur de transport, même à Paris !

J’ai même découvert des opérateurs de transport que je ne connaissais pas :

image : opérateur

Enfin, il ya aussi des exceptions géographiques étranges : je pense par exemple aux arrêts de bus autour de Porte Dorée : on trouve deux arrêts, chacun d'un côté de la route, et il y en a un des deux qui ne s'appelle pas Porte Dorée !

image : cet arrêt

Bref, on aurait pu croire qu’on pouvait tout importer automatiquement, mais en creusant un peu, on se rend compte que souvent, il y a des petites subtilités et qu’une vérification humaine est effectivement nécessaire. On comprend ainsi beaucoup mieux les réticences de la communauté OSM face aux imports massif de données d’autres sources (c'est d'ailleurs pour ça qu'on parle ici d'intégration, et non d'import).

État des lieux :

En bref ... aujourd'hui, j'ai intégré tous les arrêts RATP des villes proches de chez moi (Boissy, Sucy, Bonneil, Créteil). Mais malheureusement, ils ne représentent pas la majorité des arrêts de bus de ces villes, qui sont massivement desservies par d'autres compagnies, dont les données de transport ne sont pas en opendata, et donc pas dans navitia.io !

Sur Paris, il m'en reste aujourd'hui moins de 100 !

Et après ?

Les possibilités sont multiples : par exemple, l'intégration dans Osmose pourrait permettre à d'autres contributeurs de vérifier avant d'envoyer les modifications dans OSM (comme ce qui est fait pour les données opendata des écoles par exemple).

Il serait intéressant également de regarder les rejets de mon script, comme les arrêts OSM ayant plusieurs arrêts opendata (avec un nom différent) à proximité : sur ceux-là, une vérification sur le terrain s'impose pour choisir entre les possibilités.

Ensuite, pourquoi pas réfléchir à l'intégration des lignes de bus RATP à partir de navitia.io !

De plus, OSM est un projet international, et navitia aussi, donc le modèle pourrait s'exporter sans soucis ...

Mais j'attends surtout l’opendata des données transports sur toute l’Île-de-France, pour compléter les villes près de chez moi !

Next → Page 1 of 2