Des données OSM téléchargeables avec des attributs dans une langue autre que l’anglais, non pas avec un service web, mais une plateforme dédiée au partage de données et métadonnées géographiques, où l’on peut comprendre, voir, interroger, filtrer avant de télécharger : c’est ce que permet cette approche ETL (pour Extract, Transform, Load, soit en français « Extraction, Transformation et Chargement ») dans l’Infrastructure de Données Spatiales des Libres Géographes. Dans ce billet, je reviens sur le contexte et l’historique de ce projet personnel mené sur mon temps libre, avant d’expliquer l’approche technique mise en œuvre et, évidemment, comment accéder à ces données.
Le contexte : sortir du « english fits for all »
Si l’anglais domine l’écosystème OSM et reste la langue de référence du projet, plusieurs initiatives permettent aux non-anglophones de participer au projet et d’en bénéficier : un forum multilingue, la traduction du wiki et de certaines plateformes d’auto-apprentissage, des interfaces utilisateur traduites pour les applications et les éditeurs, y compris les préréglages d’étiquettes OSM.
Mais quelle que soit la technologie ou le service utilisé, les données OSM brutes, une fois téléchargées, restent exclusivement en anglais, et toute recherche ou filtrage des données OSM dans un logiciel SIG ne peut se faire que dans cette langue.
Ayant beaucoup formé à l’utilisation des données OSM en géomatique (notamment QGIS) depuis 2011, j’ai été vite confronté aux difficultés qu’ont pas mal de francophones non anglophones à exploiter les attributs des données OSM. Difficultés d’autant plus frustrantes, dans le cas des pays du Sud, qu’il s’agissait souvent des premières données détaillées disponibles sur leur territoire. Une barrière se levait, mais une autre lui succédait.
Cette contrainte a donc tendance ralentir le processus d’apprentissage pour les contributeurs OSM non anglophones, mais surtout, elle reste un obstacle à l’adoption par des publics extérieurs à la communauté OSM : par exemple, les services publics habitués à créer/distribuer/utiliser des données dans la langue officielle, ou l’une des langues officielles, de leur pays.
De fait, dès mes débuts dans OSM, j’ai toujours eu en tête de permettre l’utilisation des données OSM sans devoir forcément passer par l’anglais.
L’historique : un service qui aurait pu exister dès 2013
Malgré l’engouement né de la réponse communautaire au tremblement de terre à Haïti en janvier 2010, il restait difficile de promouvoir OSM auprès des géomaticiens humanitaires sans service permettant de récupérer la donnée OSM dans les formats SIG les plus courants sans devoir déployer une base PostgreSQL locale. Pour résumer, ces géomaticiens voulaient du shapefile.
Dans le cadre du projet HOT STM020 à Saint-Marc en Haïti financé par l’USAID, co-conçu et mis en œuvre avec Nicolas au printemps 2012, nous avions tenu à inclure dans le budget une ligne pour un « Data download point » qui allait devenir le HOT Exports (alors avec un « s » final), développé par GeoFabrik. L’année suivante, le projet CAP103, cette fois dans le nord et nord-est haïtiens, fut l’occasion de financer l’ajout de capacités de transformations de tags et de traductions au HOT Exports. L’un des rares visuels existants encore de cette v1 en atteste (en bas, dans les Expert functions) :
De fait, dès 2013, il aurait été possible de proposer une traduction des tags OSM en anglais dans une autre langue. Mais personne ne s’en est immédiatement saisi. Pour ma part, j’ai commencé à travailler dessus au printemps 2015 lors d’une résidence volontaire à Dakar et élaboré une première liste d’étiquettes OSM traduites en français et implémentées dans le HOT Exports. Certains étudiants et étudiantes en géomatique au Sénégal ont pu en bénéficier lors de sessions consacrées à l’usage des données OSM dans QGIS. Mais à la mi-2015 est sorti HOT Export v2, totalement réécrit, et toutes les capacités de transformations et traductions de tags y ont été supprimées. À nouveau, pas le choix, l’anglais ou rien.
J’ai repris le projet sur mon temps libre à partir du confinement de 2020, dans le but d’utiliser cette fois comme plateforme l’IFL, l’Infrastructure de Données Spatiales (IDS) Francophone Libre des Libres Géographes basée sur le projet geOrchestra), qui fournissait déjà des couches métiers dans le cadre de certains projets de l’association. J’ai aussi complété la traduction, couvrant désormais 1400 étiquettes liées aux clés OSM les plus courantes identifiées par taginfo, et en utilisant les traductions des Map features du wiki OSM ou des préréglages de JOSM.
La première version provisoire, qui ne concernait que quelques pays d’Afrique de l’Ouest, a été présentée lors du GeoCom (la conférence annuelle geOrchestra) de 2023, le SotM France 2024 et le SotM 2024 à Nairobi. Optimisé suite à des remarques de l’audience lors de ces conférences, le service concerne désormais tous les 28 pays francophones du Sud (ceux listés dans la page Afrique Francophone de Wikipédia + Maurice, le Liban et Haïti) et les mises à jour sont faites en continu, via des réplications minutes. Pourquoi pas tous les pays francophones ? Parce que les données sur la France métropolitaine prendraient trop de place sur l’IFL.
L’approche technique : des couches Planet et thématiques OSM détaillées, en anglais ou français
Classiquement, les données sont hébergées dans des bases pg (PostgreSQL/PostGIS) alimentées par imposm, qui était en 2020 l’outil de transformation des données osm.pbf considéré comme le plus performant. Ce n’est sans doute plus le cas désormais que ses développements et sa maintenance se sont taries, alors qu’osm2pgsql a au contraire été relancé, notamment via un financement de l’OSMF. Lors du SotM 2024 à Nairobi, Jochen Topf m’a d’ailleurs présenté les avantages d’osm2pgsql par rapport à imposm, et peut-être ferai-je la migration un jour, mais en l’état actuel imposm couvre le besoin et la fonction d’update imposm run est bien pratique. Les données OSM sont récupérées depuis les points d’extractions et réplications minute mises en ligne par l’association OpenStreetMap France, dont le gestionnaire a gentiment accepté d’y rajouter quelques pays qui manquaient.
Concernant les couches, il y a donc pour chaque pays concerné deux jeux de données déjà prêts, l’un dans l’anglais original, l’autre traduite à la volée en français en utilisant un tableau de traduction de référence, publié ici sur GitLab. Les remarques, suggestions ou compléments y sont bienvenus.
Chaque jeu de données contient à la fois des couches thématiques toutes prêtes, mais aussi des couches Planet (c’est-à-dire une couche de points regroupant tous les objets ponctuels dans OSM, et deux autres dédiées respectivement aux objets linéaires et polygonaux) permettant de créer sa propre thématique. En effet, j’ai toujours trouvé dommage que les services existants ne proposent par défaut que des thématiques (Download de Geofabrik ou Bbbike) ou que des couches Planet (HOT Export). Les thématiques disponibles sont : limites administratives, lieux, transports, obstacles, édifices, couverture du sol, hydrographie et points d’intérêts (POI).
Certaines thématiques comportent plusieurs couches, lorsqu’elles sont représentées par des types de géométrie différents (points, lignes ou polygones). Les POI sont disponibles non seulement sous leur forme originelle (points ou polygones), mais aussi dans une couche de synthèse qui comprend les objets ponctuels et les centres des objets polygonaux.
Par ailleurs, chaque couche OSM dans l’IFL permet de retrouver l’ensemble des tags : les clés les plus utilisées dans chaque thématique disposent chacune d’un champ dédié dans la table attributaire, mais il y a également un champ au format jsonb qui contient tous les tags originels de chaque objet. Par ailleurs, si aucune de ces couches ne contient de métadonnées OSM, un champ ajoute_a permet de connaître la date à laquelle chaque objet a été intégré dans la base pg de l’IFL. Il est donc possible d’identifier les derniers objets édités dans OSM, postérieurs à la date de l’extraction utilisée au départ de la création de la base.
Ces couches sont donc accessibles non pas au travers d’un service web, mais d’une IDS. Pourquoi une IDS et pas un site web spécifique ? À la fois pour des raisons pratiques, mais aussi pour prouver qu’une IDS fait cela très bien. Côté pratique, l’IFL étant déjà en place, nul besoin de développer un site web ad hoc. Côté preuve du concept, une IDS libre comme geOrchestra dispose de toutes les fonctionnalités offertes par les standards OGC et les briques logicielles libres comme PostgreSQL/PostGIS, GeoServer, GeoNetwork et MapStore, pour proposer des traitements sur les données, une interface cartographique interrogeable, des métadonnées et des outils de téléchargement. Enfin, la donnée est déjà prête à être téléchargée, sans passer par la création de points de téléchargement personnalisés comme dans le HOT Export, approche qui nécessite ensuite un stockage côté serveur difficile à estimer.
L’accès aux données : via des fiches de métadonnées ou des applications cartographiques par pays
Il y a deux entrées possibles depuis l’IFL pour accéder aux données OSM sur les pays francophones du Sud : via des fiches de métadonnées ou des applications cartographiques.
Les métadonnées comprennent :
- des fiches de métadonnées consacrées à la présentation de chaque thématique disponible ;
- des fiches de métadonnées dédiées à chaque pays francophone couvert avec un lien de téléchargement intégré via des menus déroulants et un lien vers une application cartographique dédiée à chaque pays ;
- une fiche de métadonnées parent qui détaille l’ETL et relie les fiches de métadonnées entre elles.
Des applications cartographiques de visualisation, interrogation, filtrage et téléchargement, sont dévolues à chacun des pays. Il est possible, grâce aux fonctionnalités de MapStore, de télécharger une thématique sur un pays entier, mais aussi de filtrer sur les attributs, sur une zone dessinée à la main ou la zone d’une autre couche, par exemple les limites administratives. Il est donc tout à fait possible, à partir de la couche de POI, de récupérer les hôpitaux, cliniques et pharmacies d’une région ou d’un district urbain, comme ci-dessous dans la Communauté urbaine de Yaoundé :
Des vidéos en ligne ou téléchargeables montrent ces différents accès :
Voilà pour cette longue présentation. Pour conclure, je dirais qu’à une période où les annonces de méga jeux de données mixant plusieurs sources ou issus de l’IA, cet ETL montre qu’il y a encore moyen de faire des choses fines, porteuses de sens et adaptées à des contextes locaux avec OpenStreetMap.
