Le blog de nlehuby

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 13, 2016

Migration du blog

Après quelques années de bons et loyaux services, mon hébergeur DrupalGardens jette l'éponge. C'est pour moi l'occasion de déménager mon blog vers 5apps, et j'en profite au passage pour le migrer de Drupal vers Pelican.

Drupal c'est cool. Je suis tombée dedans il y a longtemps, alors que j'étais encore en école d'ingé, et j'ai même eu l'occasion de m'impliquer dans la communauté francophone de Drupal pendant quelques années.

Mais faire mon blog avec Drupal, c'est un peu comme louer une cuisine professionnelle pour se faire un oeuf sur le plat : ça marche, mais pour le KISS, on repassera.

Donc j'ai décidé de passer à un site statique.

Pelican, c'est assez fun à utiliser : on écrit ses articles en rst ou en markdown, puis pélican compile / transforme tout ça en pages html, qu'on peut héberger très simplement puisque c'est juste du html tout con.

Un peu comme Sphinx, mais pour un blog.

Quelques détails sur la migration :

J'ai commencé par installer Pelican. Ça s'installe en local (voir à ce propos le très bon article de SpF sur ce sujet) et c'est sans difficicultés particulières.

Ensuite, j'ai migré le contenu existant en utilisant l'import par flux RSS.

C'est loin d'être parfait : j'ai dû repassé sur tous les articles pour virer les balises html en trop dans le fichier md généré... C'est là que je suis bien contente de n'avoir que 24 articles publiés !

Mais ça m'a permis d'avoir une nouvelle instance de blog qui tourne en quelques heures, avec tous mes anciens contenus.

Bon, ce n'est qu'une façade, car tous les liens pointent encore sur l'ancien site, ainsi que les images, mais bon si les migrations entre services étaient si faciles, ça se saurait ;)

Pour l'hébergement, J'ai choisi 5apps.com, car je l'utilise déjà pour héberger mes petites appli en html (dont Horaires-Bus, mon appli pour consulter les horaires des bus même quand y a plus de réseau) et j'en suis très satisfaite.

C'est aussi simple à utiliser qu'un hébergement web chez github (on fait git push pour déployer), mais avec des services sympa en plus (notamment la génération automatique d'AppCache. Si vous utilisez cette techno et que je vous le faites à la mano, je pense que vous voyez pourquoi c'est cool :p)

Bref, je vais m'arrêter là, parce que j'ai toujours trouvé ça très méta les gens qui tiennent un blog pour ... parler de leur blog.

Tout ça pour dire que la nouvelle adresse de ce blog est https://nlehuby.5apps.com (ou https://nlehuby.5apps.com/feeds/all.atom.xml pour les lecteurs de flux)

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 ;)

Jun 11, 2015

Les horaires de bus dans la poche

Je me suis enfin décidée à publier ma deuxième application FirefoxOS.

Elle a une mission très simple : sauvegarder et restituer les horaires théoriques de passage de bus à un arrêt.

Son fonctionnement est simple : en deux étapes

l'initialisation (quand j'ai une connexion internet)

  • je choisis mon arrêt.
  • je sélectionne la ligne et la direction
  • je vois alors les horaires, et je peux les enregistrer

init 

l'utilisation (quand je suis en déplacement, potentiellement sans connexion internet)

  • je vois la liste de mes fiches horaires enregistrées
  • je sélectionne celle que je veux, et je consulte les horaires

liste détail

Cette application utilise les données opendata d'Île-de-France, grâce à l'API navitia.io

Si vous voulez l'utiliser ailleurs, faites-moi signe : si votre région est couverte par navitia.io, je peux vous en déployer une version avec les horaires qui vous intéressent.

Cette application a été initiée pendant un hackathon chez Mozilla Paris en novembre 2014, puis peufinée par mes soins avec plus ou moins d'assiduité et de motivation pendant plusieurs mois.

C'est bien sûr open-source si vous voulez contribuer au code ou remonter des bugs. Si vous voulez supporter le coup de développement (énorme !) de l'appli, j'accepte les Flattries (et les bières, toujours).

Le but initial était de pouvoir avoir toujours sur moi les horaires de mon bus de banlieue peu fréquent, pour adapter mon itinéraire en connaissance de cause, et ce même si ça ne capte pas ...

Dans la pratique, j'ai déménagé depuis et ne prends plus ce bus de banlieue, et ses horaires ne sont toujours pas en opendata, donc j'aurais une utilisation assez limitée de l'application.

EDIT : le STIF a ouvert les données transport théoriques de toute l'Île-de-France donc ... l'appli fonctionne à présent sur les bus de banlieue !

J'espère que d'autres en auront l'usage ou sauront s'en inspirer pour d'autres utilisations.

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.

Jun 12, 2014

Mozilla l20n pour les nuls (par une nulle)

Comme je me suis lancée récemment dans l'internationalisation (je l'ai écrit une fois, maintenant, ça sera i18n et puis c'est tout) de mon petit site OpenBeerMap, et comme c'est ma première expérience en tant que développeur sur ce sujet et que j'ai vraiment galéré, je vous propose un article à mi-parcours entre le tutoriel et le retour d'expérience sur l'utilisation de l20n en javascript.

Comment j'ai pas tout bien compris, si vous avez des retours et repérez des erreurs, n'hésitez pas à me le signaler ;)

Commençons par les basiques : c'est quoi ?

L'i18n, c'est tout simplement avoir du texte adapté à la langue de la personne qui utilise le site ou le appli. Mais ce n'est pas tout, c'est aussi respecter les conventions propres à un pays (voire une région) par exemple le format de date.

Il existe des bibliothèques dans un peu tous les langages de programmation pour réaliser ceci. Mon site étant en html et javascript, j'ai opté pour une bibliothèque js.

Bon, j'ai pas choisi la plus facile mais j'avais envie d'expérimenter la solution Mozilla : l20n.

En particulier, le format des fichiers de traduction permet de gérer des tas de choses qui doivent donner bien mal à la tête en temps normal, comme par exemple les langues avec des déclinaisons (l'allemand, le polonais, etc), les pluriels (qui s'expriment potentiellement différemment dans les différentes langues), etc. Mais ... je ne vous parlerai pas de ça dans cet article : la documentation sur le super format de fichiers de traduction est abondante et facile à trouver. Je vais "seulement" vous montrer comment commencer l'i18n d'un site et arriver au moment où vous écrivez ces fichiers de traduction au format si merveilleux.

Comment ça fonctionne ?

Un peu de théorie avant de partir tête baissée !

L'idée de base, c'est que l20n recherche tous les éléments textuels qu'on a identifié comme à traduire, puis les remplace par leur valeur dans la langue que le navigateur web lui demande d'utiliser, ou par une valeur dans la langue par défaut (ou par une clef de traduction si la valeur n'a pas été renseignée nulle part).

Bon, j'avoue que sur la partie en italique : c'est une approximation ... Il y a moyen de raffiner énormément avec l'API de l20n mais 1) j'ai rien compris et 2) pour commencer, la langue du navigateur, c'est déjà pas mal et ça couvre l'essentiel des besoins.

En bref, l20n repasse sur toute la page HTML une fois qu'elle est affichée entièrement et remplace le texte par les traductions donc

  • le texte écrit dans le HTML ne sert à rien : on peut mettre lorem ipsum à la place, ça marche tout aussi  bien
  • si le traducteur d'une langue qu'on ne maitrise pas veut nous faire un coup bas, il ya surement moyen d'injecter du code malicieux dans les traductions et de le voir interprété par l20n ... mais bon, il parait qu'ils ont pris leur précaution, ça doit être mon côté parano ...
  • si y a des bouts de HTML qui sont ajoutés dynamiquement par du javascript, ben ... ça va pas être évident, il faudra demander spécifiquement la traduction à la l20n au moment où on ajoute ce texte dynamique !

Allons-y !

Prenons donc notre super site en HTML et javascript, et introduisons un peu de l20n dedans !

Première étape : ajouter l20n.js à la liste des scripts à exécuter

  <script src="l20n.js"></script>

Étape 1 bis : trouver une version de l20n.js qui fonctionne

ça a l'air de rien, mais j'ai déjà commencé à galérer à cette étape.

La doc indique que la dernière version à jour se trouve ici.

Perso, je n'ai pas trouvé cette version super fonctionnelle et j'ai opté pour la version proposée en téléchargement sur le site officiel

Étape 2 : configurer l20n avec le manifeste

Le manifeste permet d'indiquer quelles langues sont supportées et quelle est la langue par défaut.

Le remplissage de ce fichier est assez trivial.

image : c'est trivial

Une fois le manifeste rempli, il faut indiquer où le trouver dans le html.

  <script type="application/l10n-data+json">

J'avoue avoir sauté cette étape et utilisé la version proposée dans le dépot github, dans un premier temps.

Étape 3 : marquer les chaines à traduire

Les chaines à traduire sont identifiées en ajoutant un attribut aux balises HTML.

Par exemple, si j'ai le texte suivant et que je veux le traduire :

    <h1>Bonjour bonjour !</h1>

je le transforme en :

        <h1 data-l10n-id="code_hello">Bonjour bonjour !</h1>

Là, si vous enregistrez et retournez sur votre site, il ne plus bonjour mais "code_hello". C'est normal, don't panic !

Étape 4 : traduire !

En effet, il faut maintenant créer les traductions associées aux éléments identifiés dans le HTML, à l'aide du fameux format de fichier trop bien qui gère tout un tas de trucs.

C'est là que vous pouvez retourner sur la documentation de l20n et trouver votre bonheur !

il faut donc créer un fichier pour chaque langue définie dans le manifeste, à l'endroit défini par le manifeste

locales
├── ast.l20n
├── en.l20n
├── es.l20n
├── fr.l20n
└── manifest.json

Et dans ce fichier, on peut écrire les chaines à utiliser comme traduction :

      <code_hello "Hello !">

Voilà, y a plus qu'à reproduire les étapes 3 et 4 à l'infini !

Bon, ça ne fonctionne pas super bien avec le navigateur Chromium ... Mais sous Firefox, c'est impec.

Encore quelques petites remarques :

Comment tester ?

l20n se fonde sur la langue du navigateur pour choisir la langue parmi celles du manifeste. S'il ne la trouve pas dans son manifeste, il prend la langue par défaut du manifeste.

Pour changer la langue du navigateur : dans Firefox, c'est dans Outils > Options ou Édition > Préférences, onglet Contenu.

Il faut bien sûr recharger la page pour que ça prenne effet.

Subtilités (simples) du format génial :

Si vous avez du texte un peu long : il est possible d'avoir la traduction sur plusieurs lignes

      <about_long_contenu """ Voilà un texte très très long !
                              Tellement long qu'il tient sur plusieurs
                              lignes """>

Vous remarquerez peut-être qu'il n'est pas possible de mettre des balises HTML dans le fichier de traduction :(

Pour gérer le cas où on veut traduire tout un paragraphe qui contient des liens, voici comment procéder

    <div data-l10n-id="credits_contenu">
    Carte fournie par <a href="http://www.openstreetmap.org" target="_blank">OpenStreetMap</a>
    </div>

puis

    <credits "Carte fournie par <a>OpenStreetMap</a>">

pas très intuitif, mais tout à fait efficace.

Pour le reste, je vous invite à jeter un oeil à cette adresse.

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

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 !