(English below, thanks to Deepl.com)
Ce post a été initialement publié ici.
Des données OSM en anglais, mais aussi en français, accessibles dans l’IFL pour les pays francophones du Sud
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 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 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.
This post was originally published here.
OSM data in English, but also in French, accessible in IFL for French-speaking countries in the South
Downloadable OSM data with attributes in a language other than English, not with a web service, but with a platform dedicated to sharing geographic data and metadata, where you can understand, view, query and filter before downloading: that’s what this ETL (Extract, Transform, Load) approach in the Libres Géographes Spatial Data Infrastructure makes possible. In this post, I’ll go back over the background and history of this personal project carried out in my spare time, before explaining the technical approach implemented and, of course, how to access this data.
The context: moving away from “English fits for all”
While English dominates the OSM ecosystem and remains the project’s reference language, several initiatives allow non-English speakers to participate in and benefit from the project: a multilingual forum, translation of the wiki and certain self-learning platforms, translated user interfaces for applications and editors, including OSM tag presets.
But regardless of the technology or service used, the raw OSM data, once downloaded, remains exclusively in English, and any searching or filtering of OSM data in GIS software can only be done in that language
Having trained extensively in the use of OSM data in geomatics (particularly QGIS) since 2011, I was quickly confronted with the difficulties many non-English speakers have in exploiting the attributes of OSM data. These difficulties were even more frustrating in the case of developing countries, as this was often the first detailed data available for their territory. One barrier was removed, but another followed.
This limitation therefore tends to slow down the learning process for non-English speaking OSM contributors, but more importantly, it remains an obstacle to adoption by audiences outside the OSM community: for example, public services accustomed to creating/distributing/using data in the official language, or one of the official languages, of their country.
In fact, from the beginning of my involvement with OSM, I have always had the idea of making it possible to use OSM data without necessarily having to use English.
Background: a service that could have been here in 2013
Despite the enthusiasm generated by the community response to the Haiti earthquake in January 2010, it remained difficult to promote OSM to humanitarian geomaticians without a service that allowed them to retrieve OSM data in the most common GIS formats without having to deploy a local PostgreSQL database. In short, these geomaticians wanted shapefiles.
As part of the USAID-funded HOT STM020 project in Saint-Marc, Haiti, designed and implemented with Nicolas in the spring of 2012, we were eager to include in the budget a line for a “data download point” that would become HOT Exports (then with a final “s”), developed by GeoFabrik. The following year, the CAP103 project, this time in northern and northeastern Haiti, was an opportunity to fund the addition of tag transformation and translation capabilities to HOT Exports. One of the few surviving visualizations of this v1 testifies to this (below, in Expert Functions):
In fact, it would have been possible to offer a translation of OSM’s English tags into another language as early as 2013. But no one took it up immediately. For my part, I started working on it in the spring of 2015 during a volunteer stay in Dakar and made a first list of OSM tags translated into French and implemented in HOT Exports. Some geomatics students in Senegal were able to benefit from this during sessions dedicated to the use of OSM data in QGIS. But in mid-2015, HOT Export v2 was released, completely rewritten, and all tag transformation and translation capabilities were removed. Again, no choice, English or nothing.
I took over the project in my spare time from the 2020 confinement, this time with the aim of using as a platform IFL, the Spatial Data Infrastructure (IDS) Francophone Libre of the Libres Géographes (based on the geOrchestra project), which was already providing custom layers for some of the association’s projects. I’ve also completed the translation, which now covers 1400 tags linked to the most common OSM keys identified by taginfo, and using translations of OSM wiki Map features or JOSM presets.
The first provisional version, covering only a few West African countries, was presented at GeoCom 2023 (the annual geOrchestra conference), SotM France 2024 and global SotM 2024 in Nairobi. Optimized in response to audience feedback at these conferences, the service now covers all 28 French-speaking countries in the South (those listed here in Wikipédia + Mauritius, Lebanon and Haiti), with continuous updates via minute replications. Why not all the French-speaking countries? Because data for metropolitan France would take up too much space on the IFL.
The Technical Approach: Detailed Planet and Thematic OSM Layers, in English or French
Typically, data is hosted in pg databases (PostgreSQL/PostGIS) fed by imposm, which was considered the most efficient osm.pbf data transformation tool in 2020. This is probably no longer the case, as its development and maintenance have dried up, while osm2pgsql has been relaunched, largely thanks to funding from OSMF. At SotM 2024 in Nairobi, Jochen Topf explained to me the advantages of osm2pgsql over imposm, and maybe I’ll make the switch someday, but for now imposm covers the need, and the imposm run update feature comes in very handy. The OSM data is taken from extraction points and minute replications put online by the association OpenStreetMap France, whose manager has kindly agreed to add a few missing countries.
As for the layers, there are two ready-made datasets for each country concerned, one in the original English, the other translated on the fly into French using a reference translation table published here on GitLab. Comments, suggestions and additions are welcome.
Each dataset contains both ready-made thematic layers and planet layers (i.e. a point layer that groups all point objects in OSM, and two others dedicated to linear and polygonal objects, respectively), allowing you to create your own thematic layers. In fact, I’ve always found it a bit unfortunate that existing services offer only thematic layers by default (download from Geofabrik or Bbbike) or only planet layers (HOT Export). The themes available are: administrative boundaries, places, transportation, obstacles, buildings, land cover, hydrography, and points of interest (POI).
Some themes include several layers if they are represented by different types of geometry (points, lines or polygons). POIs are available not only in their original form (points or polygons), but also in a synthesis layer that includes point objects and the centers of polygonal objects.
In addition, each OSM layer in the IFL can be used to retrieve all tags: the most commonly used keys in each theme each have a dedicated field in the attribute table, but there is also a field in jsonb format that contains all the original tags for each object. Furthermore, if none of these layers contains OSM metadata, an added_at field provides the date when each object was integrated into the IFL pg database. This makes it possible to identify the most recently edited objects in OSM after the extraction date used to create the database.
These layers are therefore not accessible via a web service, but via an IDS. Why an IDS and not a specific web site? Both for practical reasons, but also to prove that an IDS does this very well. On the practical side, the IFL already exists, so there’s no need to develop an ad hoc web site. On the proof of concept side, an open source IDS like geOrchestra has all the functionality provided by OGC standards and open source software building blocks like PostgreSQL/PostGIS, GeoServer, GeoNetwork and MapStore to provide data processing, a searchable map interface, metadata and download tools. In the end, the data is ready to download without the need to create custom download points as with HOT Export, which requires server-side storage that is difficult to estimate.
There are two ways to access OSM data on French-speaking countries in the South from the IFL: via metadata sheets or map applications.
Metadata includes :
- Metadata sheets dedicated to the presentation of each theme available;
- Metadata sheets dedicated to each French-speaking country covered, with an integrated download link via drop-down menus and a link to a cartographic application dedicated to each country;
- A parent metadata sheet describing the ETL in detail and linking the metadata sheets.
Map applications for viewing, querying, filtering and downloading are dedicated to each country. Thanks to MapStore’s functionality, it is possible to download a theme for an entire country, but also to filter on attributes, on a hand-drawn area, or on the area of another layer, such as administrative boundaries. It is therefore perfectly possible to retrieve, from the POI layer, the hospitals, clinics and pharmacies of a region or urban district, as shown below in the Yaoundé Urban Community:
Online or downloadable videos show these different access points:
So much for this long presentation. In conclusion, I’d like to say that at a time when announcements of mega datasets that mix multiple sources or come from AI, this ETL shows that there are still ways to do smaller, but still fine, meaningful things with OpenStreetMap that are adapted to local contexts.
OpenStreetMap Blogs
►
►
the role of open-source software and digital commons in modern technology, mentioning OpenStreetMap as an exemplary community-driven project. The piece emphasised the critical importance of resources such as OSM for public services and sovereignty initiatives, including France’s national geographic agency using OSM for digital twins of territories.
►
►
►