Photo par Michel Villeneuve sous licence CC-By-SA 2.0
Vous occupez un poste en géomatique ? Vous êtes en effectif réduit, voire seul(e) à gérer l’ensemble des données géographiques de votre structure ? Et face à vous, une horde de collègues, usagers ou clients qui souhaitent tous profiter de vos compétences ? Malheureusement, vous n’avez pas encore la capacité de vous dédoubler, les demandes s’accumulent, vous prenez du retard ou déclinez certaines demandes.
Cette situation vous dérange et créée de la frustration auprès des personnes en attente de vos services. Vous voudriez embaucher quelqu’un de plus, mais votre hiérarchie refuse. N’y-a-t’il rien à faire pour rendre votre service SIG plus efficace dans ce contexte ? Peut-être bien que si…
Un collègue à la demande
Quand vous déménagez, vous ne vous dites pas : « je vais me débrouiller pour déménager tous mes meubles sur mon vélo ». Ce serait la meilleure façon d’y passer 3 semaines, voire pire, de se blesser. À la place, vous faites appel à des amis, de la famille ou des déménageurs : un soutien humain le temps d’un week-end pour vous aider à accomplir une tâche inhabituellement démesurée. Vous vous appuyez également sur des outils et du matériel dont vous ne disposez pas habituellement : un camion, un chariot, des cartons… Tout cela coûte un peu, mais rien en comparaison de l’achat d’un camion, de l’embauche en CDI d’un déménageur…
Demander de l’aide pour déménager est tout ce qu’il y a de plus commun. Alors pourquoi se laisser déborder par de trop nombreuses demandes en géomatique ? Pourquoi risquer le surmenage à vouloir trop en faire, alors que des ressources existent pour vous soutenir ? Et si vous disposiez d’un collègue à la demande ? À qui vous pourriez déléguer vos tâches urgentes simplement ? Cela vous aiderait à accomplir plus malgré les contraintes que vous subissez. C’est précisément là que j’interviens !
Un géomaticien et développeur quand vous en avez besoin
Si vous n’avez pas possibilité de recruter une personne supplémentaire pour répondre aux demandes, faites appel à un géomaticien indépendant. Tel le déménageur qui vous prête une fourgonnette et déplace votre canapé, je vous accompagne dans vos projets et met à votre disposition mes compétences en géomatique et développement logiciel. C’est une bonne façon de faire face aux demandes fluctuantes, et une dépense moindre pour votre service SIG comparé à un recrutement à temps plein.
Mais comment faire confiance à un prestataire indépendant ? Et s’il n’était pas sérieux ? J’ai déjà eu de mauvaises surprises…
Tout le monde se pose des questions avant de confier une mission à un indépendant, rien de plus normal. Moi-même je choisis avec soin les partenaires avec lesquels je travaille. Ces quelques éléments pourront vous rassurer sur ma capacité à vous être utile, avec des valeurs qui vous ressemblent :
Mais un prestataire ce n’est pas juste un panier de compétences. C’est également une personne à votre écoute. Contrairement à une multi-nationale où vous aurez autant d’interlocuteurs que de services, ici vous avez un seul et même interlocuteur, du premier courriel à la livraison. Pratique, surtout quand celui-ci comprend les enjeux de votre métier, son langage et ses contraintes. Plus besoin de réexpliquer 10 fois votre problème.
Un prestataire oui, mais pour quoi faire ?
Pouvoir compter sur quelqu’un de compétent et qui vous comprend c’est une chose, c’est encore mieux si on sait quelles missions lui confier. Voici une liste non-exhaustive de tâches que vous pouvez me déléguer en toute confiance.
À court terme
Réalisation de cartes statiques ou atlas suivant la charte graphique de votre structure
Écriture de requêtes SQL pour l’automatisation de tâches d’analyse de données
Développement et publication de cartes web interactives
À moyen terme
Formation méthodologique et technique (tous niveaux)
Constitution ou mise à jour de données de références : adresses, occupation des sols, réseaux, commerces…
Développement d’outils métiers à façon
À long terme
Accompagnement à la mise en place de solutions techniques
Conseil en stratégie de diffusion de données ouvertes ou en interne
Ne perdez plus de temps avec des tâches répétitives ou chronophages : commencez par me confier ce qui vous embête le plus. Puis, voyons ensemble comment automatiser ces tâches sur le long terme. Ainsi, vous visez une optimisation pérenne : gain de temps immédiat, et mise en place de routines efficaces pour l’avenir.
En tant que géomaticien(ne), on fonde de grands espoirs sur la capacité du SIG à servir l’ensemble de l’organisation. C’est normal, les données géographiques sont partout, et les cas d’usages sont nombreux. Alors ensemble, réalisons vos objectifs et faisons de votre service SIG la ressource indispensable qu’il se doit d’être.
I’m working with a small team to develop ProjetDuMois.fr (project of the month) to encourage thematic contribution on OpenStreetMap during a month in France. This website will offer to community a dashboard with contribution statistics, a web map for efficient mapping, and badges for gamification. To offer precise and up-to-date statistics, it was necessary to start working with full-history OpenStreetMap files (.osh.pbf). It was a new topic to discover, and I will share with you this process journey, hoping to make it easier for others to work with these files.
What are full-history OpenStreetMap files ?
As a reminder, OpenStreetMap is a worldwide geographic database, we sometimes call the Wikipedia of maps. Anyone can contribute and make it better. Like many other collaborative systems, an history of all changes made is available. When someone edits the map, a changeset is created to describe what has been edited. Cumulating all changesets leads you to what database currently is.
10 years of OpenStreetMap edits
Most of the time, when you want to play with OpenStreetMap data, you’re interested in current state of database. This is available through many forms and providers. These extracts are perfect fits for creating web maps, geographical or statistical analysis, routing and so on. But what if you want to look at OpenStreetMap’s history ? What if you want to see how OSM looked 1 week ago ? 1 month ago ? Or 5 years ago ? In that case, you need to use full-history files. These files are different from simple extracts as they cumulate all changesets since the very beginning of OSM (all changes since 2007, data between 2004-2007 is provided in its 2007 state). Quite like an history book you can read with appropriate toolbox. Full-history files offer a rich set of information :
Geometry (nodes, ways, relations) and their attributes (tags)
In every version they went through
With changes metadata (user, date, used software…)
This is a literal goldmine for statistics. And as all treasures, you have to go on a quest before getting it !
Note (2020/08/18) : this article is meant to go into technical details on how to manipulate OSM historical files. If you want a simpler way to go through OSM historical analysis, you can try Ohsome API.
Picture by Sajan Shakya24 via Wikimedia Commons under CC-By-SA
Getting full-history OSM files
Let’s get practical, and see how we can work with full-history files, beginning with download.
Manual downloading of full-history files
Depending on what you want to do, you might be interested in different files :
Note that, as these files contain personal information about European Union citizens, you may comply with General Data Protection Regulation (GDPR) if you go beyond playing around on your personal computer with these files. That’s also why Geofabrik extracts are only accessible with an OpenStreetMap account, to quote their homepage :
These files may only be used for OpenStreetMap internal purposes, e.g. quality assurance. You must ensure that derived databases and works based on these files are only accessible to OpenStreetMap contributors.
As legal aspects are now clear, let’s continue our journey. In this article, we will work with a regional extract, because they are lighter to download and process. But all instructions below will be identical with world file. So let’s go on Geofabrik, what we look for is a file called your_region-internal.osh.pbf. They can be found on dedicated page of your area or country.
Link to download « Bretagne » area (French subdivision)
And this is it for downloading manually. If you’re not interested in automating this part, you can skip to section « Completing full-history file« .
Automatic download of full-history files
As you have seen, we need to first log-in with OSM account to get regional extracts with user metadata. The process is straightforward when done by hand, but needs more steps when done through a script. Let’s see how you can automate this task.
To protect its files with a login page, the Geofabrik team has created sendfile-osm-oauth-protector, an Apache module to enable OpenStreetMap authentication. We are here interested only by the Python client, which enables file access with OSM login and password. Before going further, you have to download the software repository and install client dependencies.
Once done, you should have access and be able to use the Python script called oauth_cookie_client.py. Its job is to give you cookies (yummy !) which we will use later for downloading OSM full-history file. Run the following command to generate a cookie file :
The cookie file will contain a token which enables you to connect to Geofabrik site. Now, we can download through command line the regional extract of our choice, for example with wget. For some (unknown) reason, the generated cookie file can’t be taken directly by Wget, that’s why in the command it is processed before being used. So, run the following command (just change URL to get wanted extract) :
Now, we have a full-history file of OpenStreetMap. Full-history… really ? Well, not really. As said above, everything before 2007 is summarized as how database looked when the API changed to 0.5 to 0.6. But it’s not the worst part… It’s full-history until last export made available roughly every week-end. And this export contains data from 4 days before extract is made available. So the full-history file contains data until ~7 to 14 days ago, which is fine for many uses. But statistics I was looking for needs to be maximum 1 day late, so I needed to catch-up missing data.
If you’re not interested in catching-up data very recent data, you can go directly to section « Playing around with your full-history file« .
So, to complete our history file, we need to retrieve very fresh data. And OpenStreetMap most fresh data is available through its replication system (also called diff files). Replication files are minute/hourly/daily XML files which contains all changes that happened to database during a given amount of time. These files are made available in OsmChange format (.osc.gz), basically the same as classic OSM XML files, but with indication of what to create, edit or delete. Like other data files from OSM, they can be found either on official website or through mirrors.
What we will do here is to complete our history file using replication files. There are several ways to do so, here is the most convenient one I found. We will use two tools : Osmupdate and Osmium. First one will generate a complete OsmChange file, from the minute your full-history file stops until now. Second one will merge this OsmChange file with your full-history file to get you a single, up-to-date, full-history file.
Let’s start with Osmupdate. You can install it following instructions here (or through your distribution package, sometimes it is called osmctools). Once done, we will ask it to download recent changes from OSM :
Note here the option --day : it only retrieves daily replication files. This get your history until last midnight, which is enough for my use case. But you can change it to --minute or --hour if you want to, however it will take longer to retrieve as it will download lot of small files. You can also use another source than official one using --base-url option. Note that it’s better if the mirror offers daily and hourly replication files, otherwise it will be quite long to catch-up. OsmUpdate will look to your full-history file, check the date of last contained data, then download everything missing. It will finally produce the desired OsmChange file. This file will contain more or less data if you are using a mirror with regional data or official website with planet data. In my case, I used main website so the file contains planet data. However, I’m working with a regional extract. Merging it as is will result in a mix of regional then worldwide data, which will be inconsistent. I need first to filter changes to only keep regional changes, so that’s where Osmium comes to the rescue.
Install and configure Osmium according to documentation. Before going further, we also need another small file named your-region.poly. This is available on Geofabrik next to the extract you choose. This describe the area of your region, that will be helpful to cut planet data. Once downloaded, you can run this Osmium command to reduce OsmChange file to only contain changes in your region :
Depending of the size of your region and how old your full-history is, this file will be more or less heavy. Last step is to merge this changes file with your full-history, to make it really complete :
This can take some minutes depending of input file size and capacity of your computer. Now, that’s what I call a full-history OpenStreetMap file, so here starts our time travel through OSM data !
Picture by JMortonPhoto.com & OtoGodfrey.com via Wikimedia Commons under CC-By-SA
Playing around with your full-history file
You have many possibilities using these files, we will see two of them here. Osmium documentation give a pretty good overview of what is possible and how to proceed. Let’s start with a simple use case.
Counting features at a certain time
For ProjetDuMois.fr, I was looking for showing evolution of features in OSM in a certain period. We will make use to do so of two commands in Osmium : time-filter and tags-count. What they do is pretty self-explanatory, but you can see their documentation using osmium tags-filter --help for example. Let’s say we want to know how many charging stations there was on 01/08/2020, just run :
Note that we really have two separated steps here : first we get a classic .osm.pbf file of what data looked like at the time, then this result is sent to run counting operation. This processing can be automated using a loop to have count for every day or every hour for a certain type of feature. If you want to loop over time, you may want to pre-filter your full-history file to only keep features you’re counting (for faster processing). This can be done with this command :
For a leaderboard of contributors on a specific theme, I needed to know who edited a certain type of features over time, either creating, editing or deleting them. This needs several steps to offer a complete view of changes, in order to keep track of feature before and after it gets wanted tag :
Extract features over time having wanted tags
Summarize this as a list of OSM IDs
Extract list of all changes happening to features based on their ID
Convert result into a single CSV file
So first step is to extract features based on their tag. We’ve seen it before, it’s with Osmium tags-filter command :
Note the -R option to only keep features themselves and not their dependencies (nodes being part of a way, nodes and ways part of a relation).
We have an OsmChange file, which is not really convenient for the next steps. We need a simple list of OSM IDs to use osmium getid. To transform the XML file into a simple list of IDs, we will use xsltproc command, old fashioned tool for manipulating XML. Download the XSLT file here and then launch this command :
This reads the list of IDs, find features in your full-history, then writes them into an OsmChange file. Note that if you work with a large dataset, Osmium can be killed because it uses too much memory. Splitting the list of IDs into smaller files (with split utility for example) and looping over osmium getid solves the issue. Now, you have an OsmChange only containing history of features which had at some point the tag you’re looking for. Last part is to make this usable in a classic spreadsheet software or database. We transform it as a CSV file, again using xsltproc. You can find another XSLT configuration file here for this part, then run :
Awesome, you can see whoever created, edited or deleted a charging station in your area !
Conclusion
We made it through the full-history OpenStreetMap data analysis. We saw together where to find these files, how to complete them to be up-to-date, and what kind of processing we can do. They need a quite different toolbox compared to other OSM files, but allows a whole new world possibilities. Remember that they should only be used for analysis for the community. When using it, keep in mind that you’re manipulating metadata about people’s workflow and daily contributions. With great power comes great responsibility ! Also thanks to Frederik Ramm and Michael Reichert for their help on using Geofabrik extracts behind OSM login system.
Looking for OpenStreetMap data expertise for your projects ? Contact me and let’s discuss !
Osm2pgsql tool is quite famous in the OpenStreetMap community : it allows to transform raw OSM data into a ready-to-use PostgreSQL database. It is commonly used for setting up rendering or geocoding databases. People also use it to run various data analysis, which are made quite simple using extensions like PostGIS. However, for a quite long time, it was not so intuitive to fine tune osm2pgsql to go further. This is now past as Jochen Topf released a new « flex back-end » (still in experimental phase). This mode allows to configure how the database should look at the end of data process. In particular, you can process relations and copy tags they carry on other features like nodes or ways. Some documentation and examples are now available.
As I’m working on GeoDataMine (an easy-to-use OSM data extractor for local authorities), I was stuck on a very simple use case : getting street names from associatedStreet relations. In street numbers exports I was producing, street name were available when it was set as addr:street tag on nodes, but not when a node was a part of associatedStreet relation. This was frustrating : information exists, but you can’t access it. When Flex back-end was released, I was curious about if it allowed to solve this issue. TL;DR : it does ! Let’s get through my Flex journey.
Compiling osm2pgsql
First step is to make available latest osm2pgsql version available on your machine. If it is not (yet) available in your distribution repositories, you can compile it. Don’t be afraid, the process is quite straightforward. Just make sure you’re getting latest version (master branch of the Git repository).
Configuring Flex back-end
Next step is to create a Lua script to define what the database will look like after osm2pgsql import process. Some examples are available in the repository. I’m going for the compatible.lua file, as it mimics original back-end structure.
Columns
I want to have a rel_tags columns, similar to tagshstore but for storing all tags coming from relation. So, I just add a new column in my existing tables structure :
Note that this will work for addresses, as each node will only be part of one associatedStreet relation. If you’re working with bus lines for example, you will need a database structure handling features being part of several relations of same type.
Relation tags > node table
Creating your custom tables is a really interesting new feature in this Flex back-end. Here, I will create a table to associate relation tags to a node ID. This can be done after other tables declaration :
tables.relation_node = osm2pgsql.define_relation_table('planet_osm_relation_node',-- The name of the table{{ column ='node_id',type='bigint'},{ column ='rel_tags',type='hstore'}}-- List of supplementary columns)
We do this only for nodes, as ways will be processed using another mechanism.
Stage 1 : default initial processing. Each OSM object is reviewed, but you can only access information concerning directly this object. For a node its tags and coordinates, for a way its tags and list of nodes, for a relation its tags and list of members. So no way to get relation tags when reviewing a node or way. But you can mark here a feature as needing a second review, after every feature has already been seen.
Stage 2 : marked features are viewed a second time. There, you can access global variables from your script where you have stored useful information. For example, for a way ID, all tags of relations it is a part of. You can then put these tags in the database for definitive storage. Note that features marking only works for ways and relations as now (that’s why I’m using the relation_node table above) !
So let’s use this system to store relation metadata in a global variable, then associate it to ways. First, we create an empty global variable (near the start of script) :
by_way_id ={}
Then, we set-up the two stages system in the way-processing function, near the start lines of this function :
-- Ways are processed in stage 2 to retrieve relation tagsif osm2pgsql.stage ==1then
osm2pgsql.mark_way(object.id)returnend
Everything put in this function after these lines will be executed only in stage 2. That’s where we will add the code to get relation metadata and store it into the rel_tags we created earlier. This can be done using these lines (to put before any :add_row call) :
-- If there is any data from relations, add it inlocal d = by_way_id[object.id]if d then
object.rel_tags = d
end
Everything is now ready for both nodes and ways.
Store in memory relations metadata
Now, we have to edit osm2pgsql.process_relation(object) function to define what we want to save in memory or in relation_node table. This will be done by looping through all members of each relation.
-- Go through all the members and store relation tagsfor _, member inipairs(object.members)do-- When member is a nodeif member.type=='n'then-- We add metadata to relation_node tablelocal d ={}
copy_rel_tags(type, d, object)
tables.relation_node:add_row({ node_id = member.ref, rel_tags = d })-- When member is a wayelseif member.type=='w'then-- We put metadata in by_way_id global variableifnot by_way_id[member.ref]then
by_way_id[member.ref]={}endlocal d = by_way_id[member.ref]
copy_rel_tags(type, d, object)endend-- Outside of the process_relation, you can make available-- the copy_rel_tags function, which is an helper to merge-- all tags coming from various relationsfunction copy_rel_tags(rel_type, d, object)for k,v inpairs(object.tags)doif k ~="type"then
d[rel_type ..'_'.. k]= v
endendend
So, we’re good : metadata is stored, ways processed in stage 2 will retrieve it. The complete Lua script is here (a bit different because less tags are used in my database compared to compatible.lua file). Let’s run osm2pgsql.
Launch osm2pgsql
Just run the osm2pgsql command using appropriate option to use Flex back-end :
If you have Lua-related issues, they are most likely to be originating in your script. As I’m no Lua expert, I had to redo this several times before having the perfectly-working script. Once done, your database is ready to explore.
Database final processing
Connect to your PostgreSQL database. You will see the four tables you defined. Check that each of them has data and its columns filled. For our street names use case, we’re not done yet ! In fact, ways have their rel_tags filled, but not nodes (point table). Let’s run a SQL request to fill rel_tags columns in point table :
UPDATE planet_osm_point
SET rel_tags = a.rel_tags
FROM(-- Merge all tags for a certain nodeSELECT node_id, array_to_string(array_agg(rel_tags),',')::hstore AS rel_tags
FROM planet_osm_relation_node
GROUPBY node_id
) a
WHERE a.node_id = osm_id; DROPTABLE planet_osm_relation_node;
At this point, you have your rel_tags columns filled everywhere. So now, we can get street names from both nodes and relations tag. For example :
SELECT
osm_id,"addr:housenumber",-- Take first not null valueCOALESCE(rel_tags->'associatedStreet_name', tags->'addr:street')AS street
FROM planet_osm_point
WHERE"addr:housenumber"ISNOTNULL;
Quite handy, right ?
Conclusion
I’m really glad the osm2pgsql development team has released this new feature. Even if Lua is not the programming language I use the most, it’s still relatively easy to create your own configuration file. The given examples are really useful, I hope more will be released in the future to cover more use cases. I was a bit disappointed by the two-stages system not being available for nodes, but it seems temporary and shown workaround works well. It will definitely make advanced reuses of OSM data easier for developers and data analysts. You should give it a try !
Looking for OpenStreetMap data expertise for your projects ? Contact me and let’s discuss !
Pas le temps de lire ? Gribrouillon.fr est l’outil simple pour gribouiller sur une carte web, essayez-le !
L’art du dessin et des cartes numériques
Certains d’entre vous se souviennent sans doute de l’époque glorieuse de Microsoft Paint. Pour les plus jeunes, Paint était un logiciel de dessin ultra simpliste, où chacun pouvait laisser s’exprimer sa créativité.
Microsoft Paint à l’heure de Windows XP
Avec sa vingtaine de couleurs et son outil pinceau, Paint n’avait rien à envier aux plus prestigieux outils de graphisme. Bien au contraire : sa simplicité d’usage permettait aux petits et grands de s’essayer à toutes formes d’art.
En parallèle, les cartes sur le web sont un autre type d’objet graphique commun. L’émergence d’outils comme uMap ou Google My Maps permettent de créer sa carte et d’y faire apparaître des marqueurs ou formes géométriques.
Carte uMap des Groupes locaux OpenStreetMap en France
Ces outils sont parfaits pour la création de cartes « propres » ou professionnelles, en tout cas de cartes qui ont vocation à être exposées. Mais pour revenir au domaine artistique, avant d’exposer un dessin ou une toile, il a été nécessaire de gribouiller, raturer, gommer… Souvent sur un support séparé comme du papier brouillon. Même si la conception d’une carte prendra chemin différent de celui emprunté pour la réalisation d’une œuvre d’art, il est pertinent de disposer d’un support pour gribouiller / raturer une carte à l’ère du numérique.
Une carte à gribouiller : pourquoi faire ?
Prenons le temps d’étudier quelques cas d’usages où le dessin libre par dessus une carte aurait tout son sens.
Pour s’organiser
Les personnes contribuant à OpenStreetMap le savent bien : organiser une cartopartie n’est pas chose aisée. Si OpenStreetMap ne vous est pas familier, il s’agit de l’équivalent de Wikipédia pour la géographie. Régulièrement, des bénévoles se réunissent pour compléter la carte d’une ville, d’un quartier : ce sont les « cartoparties« . Afin de fluidifier la contribution, le territoire est découpé en zones et les groupes se répartissent la tâche.
Cartopartie à Managua (Nicaragua)
Différents outils pour organiser existent : Tasks Manager, MapCraft, uMap… Mais tous nécessitent d’être coutumiers avec la manipulation de données géographiques. Et ne sont pas forcément prévus pour la prise de note sur le terrain. Ces prises de notes se font souvent sur la base de cartes imprimées et annotées à la main. Pourtant, pouvoir partager une carte numérique sur laquelle chacun peut se localiser et annoter aurait du sens.
Pour s’exprimer
Les cartes traditionnelles sont le reflet de l’aménagement du territoire, une spatialisation relativement objective des infrastructures. Le vécu n’a pas sa place sur ce type de cartes, et pourtant les êtres humains sont sensibles : nous percevons différemment les espaces selon notre vécu et nos habitudes. La cartographie sensible ou subjective a vocation à faire apparaître ces émotions spatialisées sur des cartes.
Ces cartes sont souvent réalisées sur papier ou à l’aide de matériaux variés, une version numérique pourrait être un support complémentaire durant la phase exploratoire.
Pour s’amuser
Au même titre qu’une photo, une vidéo ou une page blanche, la carte est un objet graphique laissant place au détournement et la personnalisation. Les nombreuses cartes parodiques liées à l’actualité ou le ressenti des habitants régions par régions tranche avec le sérieux habituel de la cartographie.
Parodie du redécoupage régional
Mettre à disposition un nouvel outil numérique de dessin sur une carte permettra plus facilement à tout un chacun de s’exprimer sur les sujets de son choix.
On peut imaginer un aspect ludique à un tel outil : mettre au défi ses amis de dessiner sur la carte le drapeau d’un pays à tour de rôle, une bonne mise à l’épreuve de ses connaissances en géographie !
La solution : Gribrouillon !
Vous l’aurez compris, l’outil Gribrouillon (gribrouillon.fr) permet de répondre à ces besoins. Gribrouillon = gribouillis + brouillon, le tout sur une carte web.
Mode navigation (à gauche) et mode dessin (à droite)
Le principe est simple : déplacez la carte sur la zone où vous souhaitez dessiner. Une fois la carte positionnée, cliquez sur le bouton Pinceau pour passer en mode dessin. Vous aurez alors à disposition les outils de dessin classiques. Libre à vous de dessiner pour vous organiser, vous amuser ou vous exprimer !
Partage de carte
L’avantage de Gribrouillon est qu’il permet le dessin à plusieurs simultanément : partagez le lien de votre gribouillis, et dessinez en parallèle sur une même carte. Il est également possible de changer le fond de carte par le biais du menu latéral. L’outil est disponible sur le web pour mobile et ordinateur de bureau.
Les calculs d’itinéraires sont un type d’analyse spatiale très classique, permettant de connaître l’itinéraire le plus court d’un point A à un point B. Pour réaliser ces calculs, nous devons nous appuyer sur des données géographiques de bonne qualité. Cet article va vous présenter comment réaliser des calculs d’itinéraires à grande échelle simplement avec :
PostgreSQL, la base de données libre de référence pour les données relationnelles volumineuses
PostGIS, l’extension pour l’analyse géospatiale sur PostgreSQL
PgRouting, l’extension pour les calculs d’itinéraires sur PostgreSQL
OpenStreetMap, la base de données géographique mondiale de référence
Osm2PgRouting, l’outil d’import de données OpenStreetMap pour PgRouting
Osmium, un outil de traitement de données OpenStreetMap pour convertir le format de fichier, filtrer les données et découper en plusieurs zones.
Notez que d’autres outils existent pour réaliser des calculs d’itinéraires à grande échelle sur des réseaux complexes. Ces outils sont plus pertinents dans les cas d’usages classiques (calculs pour affichage sur une page web). Ici, utiliser PgRouting présente plusieurs avantages, notamment une mise en place simple (faible besoin en compétences d’administration système) et la gestion centralisée de toutes les données dans PostgreSQL.
Vue d’ensemble de la chaîne de traitement
Je passe volontairement sur l’installation des différents outils, qui est documenté sur leurs sites respectifs. L’installation dépend largement du système d’exploitation utilisé, mais reste la plus simple à mon avis sous GNU/Linux.
La logique de traitement que nous allons mettre en place est la suivante :
Commençons tout de suite par la récupération des données.
Télécharger un extrait OSM sur Geofabrik
Geofabrik est une société allemande spécialisée sur OpenStreetMap. Cette société propose des extraits quotidiens de la base OpenStreetMap, découpés par régions (continent, pays, région administrative). Vous pouvez donc télécharger la zone de votre choix, au format .osm.pbf (le plus compact et rapide à traiter). Ici, on récupère le fichier france-latest.osm.pbf.
Filtre thématique avec Osmium
L’outil d’import Osm2PgRouting est bien pratique, mais présente deux limitations qui ont leur importance dans le choix des traitements à mettre en place :
Il lit uniquement des fichiers OSM XML (format .osm)
Il charge l’intégralité des données d’entrée en mémoire vive pour réaliser son analyse avant import en base de données.
Nous devons donc nous assurer que les fichiers en entrée de cet outil soient les plus légers possibles. Heureusement, il est possible de réaliser l’import de manière progressive en découpant par zones géographiques distinctes nos données. C’est pourquoi on utilise l’outil Osmium : pour filtrer et découper le fichier PBF téléchargé en plusieurs fichiers OSM XML correspondants au réseau par zone géographique.
On commence donc par filtrer les données OpenStreetMap pour ne garder uniquement le réseau routier. À noter qu’il est possible de s’intéresser à d’autres réseaux (eau, électricité, gaz, Internet, chemins de fer…), à condition de changer quelques configurations. La commande pour filtrer avec Osmium est la suivante :
On peut modifier les options de cette commande pour prendre par exemple toutes les routes (au lieu d’une sélection ici), ou justement sélectionner d’autres types d’objets. Le fichier en sortie france-roads.pbf contient donc uniquement le réseau routier.
Découpage géographique avec Osmium
Nous allons désormais découper ce fichier en plusieurs zones distinctes. Cette étape est fastidieuse car vous devez définir le découpage à mettre en œuvre. L’idée est d’avoir un fichier GeoJSON par zone distincte, plus un fichier JSON décrivant votre découpage pour Osmium. Pour vos zones, vous pouvez utiliser des découpages administratifs, ou créer une grille régulière avec QGIS. Au final, vous devez avoir :
Plusieurs fichiers GeoJSON, contenant chacun la géométrie de la zone concernée. On peut les nommer area_1.geojson, area_2.geojson, area_3.geojson…
Un fichier de configuration global nommé areas.json
Pour ce fichier areas.json, il doit avoir la structure suivante :
Vous devez avoir autant d’objets dans le tableau extracts que vous avez de zone à prendre en compte. Chacun de ces objets permet de connaître le nom du fichier GeoJSON à utiliser, et le nom du fichier OSM XML en sortie. Une fois tous ces fichiers en place, vous pouvez lancer la commande Osmium suivante :
osmium extract -c areas.json france-roads.pbf
Après quelques instants, vos fichiers filtrés et découpés, au format XML, seront disponibles dans le dossier de sortie choisi. On peut désormais créer la base de données.
Création de la base de données PostgreSQL
On commence donc par mettre en place la base et ses extensions :
La base est désormais prête pour l’import des données. On utilise l’outil osm2pgrouting, qui transforme directement les données brutes OSM filtrées en données utilisables en base pour réaliser des calculs d’itinéraires. De nombreuses options sont disponibles, nous utiliserons ici les commandes suivantes :
# Import des premières zones
osm2pgrouting \
-f/tmp/area_1.osm \
-c/usr/local/share/osm2pgrouting/mapconfig_for_cars.xml \
--tags \
--addnodes \
--no-index \
-d osmroads -U postgres
# Import de la dernière zone (avec création des index)
osm2pgrouting \
-f/tmp/area_n.osm \
-c/usr/local/share/osm2pgrouting/mapconfig_for_cars.xml \
--tags \
--addnodes \
-d osmroads -U postgres
La première commande est à répéter autant de fois que vous avez de zones lors du découpage. La dernière zone à importer utilise la seconde commande, qui lance la création des index en base de données. L’option --addnodes est essentielle pour permettre l’import progressif des données. Ces commandes peuvent prendre un certain temps à s’exécuter selon les capacités de votre machine.
Vous avez désormais à disposition une base prête à réaliser des calculs d’itinéraires pour automobile (principalement avec la table ways).
Calculer un premier itinéraire
L’extension PgRouting dispose de nombreuses fonctions pour réaliser toutes sortes de calculs. Ici, on va réaliser un premier calcul en utilisant l’algorithme A*. Il permet d’obtenir un chemin relativement court de manière efficace. Le calcul est à lancer en SQL de cette façon :
SELECT*FROM pgr_bdAstar('SELECT gid AS id, source, target, cost, reverse_cost, x1, y1, x2, y2 FROM ways',-- Requête de sélection2365623,-- ID noeud de départ1779025-- ID noeud d'arrivée) p;
La fonction pgr_bdAstar prend trois paramètres :
Une requête SQL, permettant de récupérer les chemins à prendre en compte. On peut ici par exemple filtrer certains chemins non-pertinents, ou changer les valeurs de coûts de traversée (cost et reverse_cost).
Deux identifiants de nœuds (point de départ et d’arrivée). Ceux-ci correspondent à la colonne id de la table ways_vertices_pgr. Ce sont les intersections et extrémités de chemins de votre réseau routier.
Chaque ligne correspond à un point de passage sur le graphe routier. Le premier est le point de départ, le deuxième le premier nœud intermédiaire, le troisième est le deuxième nœud intermédiaire… Jusqu’au nœud d’arrivée. À noter que si la requête ne renvoie pas de résultats, c’est qu’aucun itinéraire n’a été trouvé entre les deux points précisés. On retrouve en colonnes l’ordre de passage, le nœud visité, le segment visité, le coût de traversée du segment, et enfin le coût agrégé de l’itinéraire. Ce type d’interrogation simple peut être réalisé graphiquement à l’aide de QGIS et PgRoutingLayer.
Si l’on souhaite obtenir un résultat plus concis, à savoir la géométrie du parcours et son coût total, on peut joindre la table ways au résultat et fusionner les segments :
SELECT ST_LineMerge(ST_Union(w.the_geom))AS geom,MAX(a.agg_cost)AS total_cost
FROM pgr_bdAstar('SELECT gid AS id, source, target, cost, reverse_cost, x1, y1, x2, y2 FROM ways',-- Requête de sélection2365623,-- ID noeud de départ1779025-- ID noeud d'arrivée) a
LEFTJOIN ways w ON a.edge !=-1AND w.gid = a.edge;
Voilà, vous avez créé votre premier itinéraire !
Aller plus loin
Grâce à ces quelques conseils, vous êtes désormais en mesure de réaliser des calculs d’itinéraires à grande échelle avec un ensemble de logiciels plutôt portables. Vous pouvez adapter ce scénario à différents cas d’usages, et par exemple :
Changer de type de réseau : électrique, hydrographique, piéton, vélo… Vous pouvez imaginer toutes sortes de cas d’usages. La seule contrainte est d’adapter le fichier mapconfig.xml de osm2pgrouting selon les attributs utilisés.
Réaliser des calculs d’itinéraires en lot. Les fonctions « Many to many » de PgRouting permettent de calculer de n’importe quel point de départ vers n’importe quel point d’arrivée. Si vous êtes sur une logique de combinaisons départ > arrivée plus restreinte, l’idéal est de passer sur une fonction PLPgSQL pour boucler sur vos combinaisons.
Envie d’être accompagné sur ce sujet ? Je vous propose des formations sur ces thématiques, ou contactez-moi pour que nous discutions de vos besoins précis.
La cartographie d’intérieur sur OpenStreetMap est un vaste sujet, présent depuis des années au sein de la communauté. Par cartographie d’intérieur, on entend le fait de détailler l’architecture d’un bâtiment, niveau par niveau de manière précise : pièces, couloirs, escaliers, et les activités qui se déroulent dans chacun de ces espaces. Cela est rendu possible par un ensemble d’attributs (schéma « Simple Indoor Tagging« ) qui permettent d’indiquer sur chaque objet sa typologie (salle, espace, mur) et son étage (0 pour le rez-de-chaussée, 1 pour le 1er étage…).
Exemple simple de description de l’intérieur d’un centre commercial sur OpenStreetMap
La méthode de description est au final relativement simple. On s’attendrait alors que de très nombreux lieux soient ainsi décrits. Après tout, OSM est bien la base de données de référence sur d’autres thématiques, pourquoi pas celle-ci ? Malheureusement, ce n’est pas encore le cas.
Un monde à construire
Localisation des lieux cartographiés en intérieur
À ce jour, plus de 2500 bâtiments sont cartographiés en intérieur. Pour l’instant, l’essentiel des lieux renseignés se situe dans l’hémisphère Nord, en plus particulièrement en Europe. Une dynamique liée à la communauté, puisque le projet OpenStreetMap est né au Royaume-Uni et s’est d’abord diffusé à travers l’Europe.
Nombre de bâtiments cartographiés ramenés à la population
Si on compare à la population, la tendance se confirme. Le sujet prédomine en France, Allemagne, Autriche. Mention spéciale à l’île d’Åland, avec ses 9 bâtiments cartographiés pour 27000 habitants, ce qui en fait la région où le sujet s’est le plus répandu dans la population !
Nombre absolu de bâtiments cartographiés par pays
Si l’on regarde le nombre absolu de bâtiments renseignés, l’Allemagne et la France sont au coude-à-coude, suivi par les États-Unis. Ces chiffres sont probablement liés à l’activité de certaines structures autour du sujet. On peut citer les travaux de la SNCF Transilien en France ou de la American Printing House aux États-Unis, qui ont permis la cartographie de nombreux lieux sur OpenStreetMap.
Ces chiffres sont encourageants, mais restent au final épisodiques comparés aux nombres de lieux potentiels à cartographier :
Plus de 400 000 centres commerciaux
Environ 100 000 gares
Plus de 100 000 universités et établissements d’enseignement supérieurs
Pourquoi donc la communauté n’avance pas plus vite sur cette thématique ?
Un sujet qui traîne…
À cause des schémas
La première trace notable de la cartographie d’intérieur sur OpenStreetMap remonte à 2011. Une première proposition d’attributs nommée IndoorOSM est publiée. Elle introduit le tag buildingpart=* ainsi que l’utilisation de relations pour créer de la cohérence entre espaces, niveaux et bâtiment. Malgré les défauts de conception du schéma, celui-ci est utilisé en partie pour commencer à décrire l’intérieur des bâtiments. Ce n’est qu’en 2014 que le schéma Simple Indoor Tagging est publié, et propose une alternative plus simple à mettre en œuvre.
Bâtiments décrits en intérieur en suivant l’ancien schéma IndoorOSM
5 ans après, environ 260 bâtiments (1 sur 10) utilisent toujours l’ancien schéma IndoorOSM. Cette co-existence des deux schémas complexifie le rendu et la réutilisation des données d’intérieur.
À cause des outils
La cartographie d’intérieur pose un défi technique : gérer les niveaux. OpenStreetMap est une base de données à plat, représentant des données principalement en 2D. C’est la logique traditionnelle des cartes papiers puis numériques. Le problème est que notre monde est en 3D, il nous manque donc la représentation de la hauteur. Pour le schéma Simple Indoor Tagging, cela est géré simplement par l’attribut level=*. Il permet d’indiquer à quel étage se trouve un objet. Problème résolu ? Pas vraiment…
Comme l’ensemble des outils autour d’OSM fonctionne sur une logique 2D, leurs interfaces ne sont pas prévues pour gérer cette notion d’étage. Donc dès qu’un bâtiment est composé de plus d’un niveau, les données se superposent. On a donc un effet vrac du plus impressionnant.
Gare de l’Est à Paris : trop de données et pas assez de sélecteur de niveau
C’est d’autant plus frustrant que jusqu’à présent, l’ajout de données dans OpenStreetMap venait enrichir la carte et donc améliorer son rendu. Dans le cas de la cartographie d’intérieur, le rendu principal devient de moins en moins lisible au fur et à mesure que l’on détaille. Heureusement que des outils dédiés à la visualisation de ces données ont émergé au cours du temps (OpenLevelUp et OpenStationMap étant les deux seuls encore actifs).
C’était également le cas pour les éditeurs : tout se superposait sans possibilité de filtrer niveau par niveau. Sur ce point, la situation a récemment évolué :
JOSM, l’éditeur historique et le plus complet, dispose désormais d’un sélecteur de niveaux
OsmInEdit, un nouvel éditeur dédié à la cartographie d’intérieur, gère nativement le filtrage par niveau. Il propose de nombreux outils facilitant la contribution.
OsmInEdit, l’éditeur pour la cartographie d’intérieur
Ce manque d’outils et de visualisations a donc largement freiné la contribution sur la thématique.
À cause du cadre
Enfin, les derniers freins ne sont pas liés à OpenStreetMap, mais à la cartographie en intérieur de manière générale. Les systèmes de navigation type GPS ne sont pas disponibles dans l’enceinte des bâtiments (les signaux traversent mal les murs), ce qui rend complexe l’acquisition de données. On doit passer sur d’autres méthodes, à savoir :
Si on a les moyens, du matériel professionnel d’acquisition (LIDAR)
Sinon, papier + crayon + mètre (fastidieux) ou le décalquage depuis les plans d’évacuation ou d’architecte du bâtiment.
À Rennes, on cartographie les stations de métro avec papier + crayon
Sur OpenStreetMap, la grande majorité des contributions sont bénévoles, et donc se font avec relativement peu de moyens. La récolte de données complètement faite « à la main » avec notes et mesures est très fastidieuse, seuls les plus motivés s’y mettront. Par ailleurs, le contexte sécuritaire rend les relevés spontanés plus délicats, il vous faudra de bons arguments pour expliquer aux agents de sécurité pourquoi vous mesurez au centimètre près tout le bâtiment…
La contribution à partir de plans existants est largement plus accessible et plus rapide, mais pose la question des droits d’auteurs. Peut-on considérer un plan de bâtiment comme une création artistique qui tombe sous le joug du droit d’auteur ? Cette question n’a pas encore clairement été tranchée, et dépend des législations en vigueur dans chaque pays.
Ces contraintes pèsent donc fortement sur la simplicité de créer des données à l’intérieur des bâtiments.
Des solutions à envisager ?
Ces constats nous permettent de mettre en lumière les contraintes qui pèsent sur la cartographie d’intérieur dans OpenStreetMap. Maintenant, voyons comment on peut avancer concrètement pour lever ces freins.
Nettoyer les données
Localisation des éléments avec l’attribut buildingpart=*
Première proposition, qui sera probablement la plus simple à mettre en oeuvre : finaliser la migration des données de l’ancien vers le nouveau schéma. Prenons le temps de convertir ces 260 bâtiments renseignés avec le schéma IndoorOSM vers le modèle Simple Indoor Tagging. On peut partir sur une transition douce, en dupliquant les attributs, ou une migration plus « directe » en remplaçant les attributs. On peut également envisager d’ajouter des règles de validations dans les outils (MapCSS pour JOSM et Osmose) pour que la migration soit distribuée entre plusieurs contributeurs. Une ébauche de règles pour JOSM a été créée, à compléter et surtout éditer les règles pré-existantes pour prendre en compte les évolutions.
Améliorer nos outils
Pour que la contribution sur la cartographie d’intérieur prenne de l’ampleur, il faut remettre en place le cercle vertueux de contribution d’OpenStreetMap : je vois la carte, j’ajoute des données visiblement manquantes, la carte s’améliore, je trouve de nouveaux manques, j’ajoute à nouveau… Cela passe donc par des outils de visualisation et d’édition efficaces.
Pour l’édition, je ne peux que vous encourager à tester OsmInEdit et à prendre part à son évolution : c’est un outil à la fois simple à utiliser et adapté au contexte de la cartographie d’intérieur. Avoir un sélecteur de niveau dans l’éditeur iD serait également un plus.
Pour la visualisation, de gros efforts sont encore possibles :
Le rendu principal openstreetmap-carto devrait pouvoir afficher un rendu plus propre dans les lieux cartographiés en intérieur. Pour l’instant, les différentes demandes issues de la communauté n’ont pas trouvé d’écho.
Les applications telles que Maps.me ou OsmAnd devraient pouvoir filtrer les données étages par étages dans les zones où les bâtiments décrits.
Les rendus web dédiés comme OpenLevelUp doivent s’améliorer pour être plus rapides et ergonomiques, et possiblement utilisables sur mobile.
L’absence d’outils de visualisation efficace est bloquante dans la mise en place du cercle vertueux de contribution. La communauté et les équipes de développement doivent se mobiliser pour avancer sur le sujet.
Simplifier la collecte terrain
Dernier point : la facilitation de la collecte terrain. Nous avons vu que les relevés peuvent se montrer fastidieux si l’on ne se base pas sur le plan d’évacuation du bâtiment. Clarifier la loi pour déterminer si ces plans sont soumis au droit d’auteur permettra de lever le doute actuel. On peut imaginer un travail en collaboration avec les services des pompiers, qui disposent dans certains cas des plans des bâtiments dans leur zone d’intervention.
On peut également envisager une autre approche : que les opérateurs des lieux recevant du public se chargent de la contribution sur OpenStreetMap. Cela présente plusieurs avantages :
Les opérateurs n’ont pas à diffuser leurs plans d’évacuation sous licence ouverte. La question de la propriété intellectuelle de ces plans ne se pose plus. De plus, l’opérateur garde la main sur les données diffusées (uniquement les espaces ouverts au public par exemple).
Chaque opérateur est au fait des changements qui ont lieu dans son bâtiment. Il sera plus simple de réaliser les mises à jour rapidement et garantir un bon suivi des données dans OpenStreetMap.
Il sera plus simple d’arriver rapidement à une couverture globale. Plutôt que la communauté de bénévoles se charge seule de l’ajout de ce type de données, chaque opérateur se charge de son établissement. De la même manière que le bénévole connaît bien sa rue, l’opérateur connaît bien son établissement et sera plus à même de le détailler rapidement.
Dans cette logique, la communauté et les professionnels autour d’OpenStreetMap doivent se mobiliser pour sensibiliser ces acteurs à cette thématique. Toutefois, les opérateurs de lieux recevant du public seront plus sensibles si la chaîne d’outils est complète et cohérente, sur la même logique que pour les contributeurs bénévoles.
En conclusion
Depuis les débuts de la cartographie d’intérieur sur OpenStreetMap en 2011, la communauté a largement progressé. Nous nous sommes dotés d’outils pour rendre possible l’ajout de ces données dans la base. Les premières initiatives à large échelle ont permis d’obtenir des retours concrets et pragmatiques sur la méthodologie. Il nous reste encore plusieurs étapes avant de devenir la base de référence en intérieur :
Améliorer nos outils, à la fois pour les contributeurs et les réutilisateurs
Lever les flous juridiques autour des plans d’évacuation des bâtiments
Embarquer dans l’aventure les gestionnaires de lieux recevant du public
La communauté sait y faire pour relever des défis de taille !
Mais ces défis ne doivent pas nous effrayer : en 15 ans, OSM a su s’imposer comme la base de données géographique de référence pour l’extérieur. Faisons la même chose pour l’intérieur des bâtiments 😉
Pic4Review est un éditeur facilitant la contribution à la carte collaborative OpenStreetMap. Il propose de renseigner des informations sur des objets géolocalisés à partir de photos de rues libres de droits. Lancé fin 2017, il a permis à des centaines de contributeurs d’améliorer la description de centaines de milliers d’objets à travers le monde. Le principe est simple : vous participez à des missions thématiques sur une zone donnée, et pour chaque objet les photos disponibles sont présentées. Cela vous permet de répondre facilement à une question posée.
Exemple de mission pour renseigner le type de marqueur signalant un gazoduc.
Au départ, l’outil se concentrait sur la mise à jour d’objets existants côté OpenStreetMap. La nouvelle version publiée le 2 avril 2019 permet désormais de créer de nouveaux points, et ainsi compléter la base OpenStreetMap.
Intégrer les détections automatiques d’objets
La collecte et mise à disposition de photos de rues n’est pas un sujet récent. Deux fournisseurs de photos ont cependant changé la donne : Mapillary et OpenStreetCam. Ces deux initiatives ont pour objectif de mettre à disposition des photos de rues du monde entier, sous licence libre. Au-delà des photos, les équipes travaillent à la détection et l’extraction automatique des objets visibles sur les photos. On pense en particulier aux panneaux routiers, mais cela concerne également marquages au sol, mobilier urbain, équipements techniques….
Détections automatiques de panneaux routiers (source : Mapillary)
Les localisations de ces objets sont intéressantes, mais comme ils sont détectés automatiquement, il peut y avoir quelques erreurs (objets confondus, pas d’objets…). Et par ailleurs, ces objets sont stockés dans des bases de données indépendantes. Pourtant, il serait plus intéressant de les rendre disponibles au sein de cette base commune qu’est OpenStreetMap.
Pour intégrer ces données tout en vérifiant leur pertinence, on s’appuie sur une validation humaine. Pic4Review facilite ce processus, et propose désormais de valider l’intégration des détections issues de Mapillary dans OpenStreetMap.
Intégration des détections de bornes incendies
Pour le contributeur c’est très simple : on se rend sur la page de la mission, et on visualise un premier objet. On vérifie sa présence sur les photos, sa bonne localisation à l’aide de la carte (on peut déplacer si besoin) et on valide l’intégration. Plutôt simple, non ?
Pour l’instant, une vingtaine de catégories d’objets sont disponibles : bornes incendies, poteaux électriques, boîtes aux lettres, panneaux routiers… Et d’autres seront ajoutées dans le futur.
Intégrer des données ouvertes (avec Osmose)
Osmose est un outil de la communauté OpenStreetMap permettant d’identifier de potentielles améliorations dans les données (nom mal écrit, rue isolée, description incohérente…). Il permet également la mise en relation de jeux de données ouvertes avec OpenStreetMap. Plusieurs types de données sont disponibles : points de recyclage, parkings à vélos, pharmacies, postes électriques… Les données manquantes côté OpenStreetMap sont rendues visibles sur une carte et proposées aux contributeurs.
Données ouvertes à intégrer sur différents sujets (il y a de quoi s’occuper !)
Sur le même principe que les détections automatiques, l’utilisation de photos pour vérifier et intégrer ces données a du sens. C’est pour cela que Pic4Review permet de facilement intégrer les données ouvertes listées par Osmose.
Mission d’intégration des postes électriques Enedis via Osmose et Pic4Review
Ici encore, la tâche est très simple pour le contributeur : on vérifie les photos, et on valide l’intégration si l’objet est visible. Rien de plus facile, cela rend possible l’ajout de dizaines d’objets très rapidement.
Lancez-vous !
Envie de lancer une mission sur votre zone de prédilection ? C’est simple : cliquez sur « Créer une mission » dans le bandeau d’en-tête de la page, choisissez « Créer à partir d’un modèle », choisissez le type de mission et la zone, et c’est parti !
Pour les contributeurs plus expérimentés, il est également possible de créer une mission complètement paramétrable. Créez votre mission « À partir de zéro », et vous accédez à l’outil complet pour définir une mission. Choisissez une source de données et une zone, ajoutez des détails sur les attendus de la mission, et validez ! Un peu plus long à mettre en place, mais vous avez le choix sur l’ensemble des configurations.
En résumé, Pic4Review facilite désormais l’ajout de données ouvertes structurées à OpenStreetMap. Les développements futurs auront pour objectif de faciliter davantage l’intégration de jeux de données ouverts, par exemple issus de portails open data de collectivités. À noter que l’outil étant libre, il peut être utilisé également dans des contextes d’enrichissement de bases de données privées au sein d’une entreprise / administration (contactez-moi pour en savoir plus).
Pour aller plus loin
Envie d’en savoir plus ? De contribuer au développement ? Voici quelques liens utiles :
Vous l’avez vu, ce site s’est offert un coup de jeune. L’occasion pour moi de tester les nouveautés de WordPress 5. Globalement l’interface est la même qu’avant, mis à part l’éditeur d’articles et pages qui s’est largement simplifié, et qui permet de facilement organiser le contenu.
Afin de faciliter la maintenance et mise à jour du site, je cherche à disposer de pages générées automatiquement à partir de contenus structurés. J’avais en tête un mécanisme qui lirait un fichier type JSON pour en générer une page propre et bien présentée. Et comme WordPress est bien pensé, ce mécanisme existe : les « Custom Content Types » (types de contenus personnalisés). L’idée est de gérer ses propres données à la manière des articles : une page de saisie standardisée, et un affichage automatique. Impeccable, comment ça marche ? C’est là que ça se complique !
Ces types personnalisés peuvent être gérés de deux façons : soit via du code (en modifiant les modèles PHP des pages), soit à l’aide d’extensions. Rappelez-vous, l’idée est d’avoir une maintenance simple, j’opte donc pour les extensions. Plusieurs extensions existent, certaines gratuites, d’autres payantes. Après quelques tests, c’est l’extension « Pods » qui a retenu mon attention. Elle permet de créer simplement des formulaires dans l’interface d’administration pour saisir ses données personnalisées.
Créer un type de données
Une fois que l’extension est installée, vous avez une nouvelle entrée dans le menu de l’interface d’administration. Vous pouvez notamment « Ajouter un nouveau pod ».
Ici, on va donc « Créer un nouveau », pour initier notre nouveau formulaire de saisie. Quelques informations sont ensuite demandées.
Le type de contenu est à choisir avec prudence : il conditionne la manière dont vous pourrez utiliser ce formatage par la suite. Dans la logique d’une liste structurée, on opte donc pour « Type de contenu personnalisé (semblable aux articles) ». On renseigne ensuite un nom au singulier et pluriel, qui servira pour les différents affichages.
On arrive ensuite à la configuration des champs. C’est ici que l’on définit quelles informations on souhaite pouvoir rentrer pour constituer les données.
On peut donc créer un premier champ « Intitulé », qui contiendra du texte. Veillez bien à noter la valeur du champ « Nom », qui nous servira pour la page d’affichage de ces données.
Dans cette même logique, on peut donc créer autant de champs que l’on souhaite, de types variés (adresses web, numéro de téléphone, texte riche…). Une fois vos champs créés, pensez bien à cliquer sur « Enregistrer le pod » à gauche.
Créer des données
Maintenant que le formulaire est en place, on peut commencer à constituer son jeu de données. Votre type personnalisé apparaît désormais dans le menu de gauche de l’interface d’administration de WordPress. Vous pouvez commencer à créer une nouvelle entrée.
La saisie se fait sur le mode classique d’un formulaire, c’est l’étape la plus simple mais potentiellement la plus fastidieuse. Une fois les champs remplis, cliquez sur « Publier ».
Il ne reste plus qu’à afficher ces données sous forme de liste.
Créer la page d’affichage
Pour afficher notre liste d’éléments, il faut créer soi-même une nouvelle page classique. Celle-ci peut être construite comme vous le souhaitez. Vous devez juste placer dans celle-ci un bloc de type « Code court ». C’est celui-ci qui va contenir les données à afficher. Dans ce bloc, vous allez entrer un code HTML et des codes courts qui vont permettre de structurer vos données. Un exemple :
Quelques explications : le bloc pods va s’exécuter autant de fois que vous aurez d’objets saisis grâce à votre formulaire. Au sein de ce bloc, on peut utiliser les informations saisies dans le formulaire grâce à la syntaxe {@mavariable} (les noms que vous avez noté tout à l’heure). Le reste est du code HTML classique.
Le bloc pods doit être configuré en changeant principalement la valeur de « name », qui prendra le nom de votre pod. L’ensemble des configurations possibles est recensé sur la documentation officielle.
Il ne vous reste plus qu’à publier cette page, et voilà ! Vous avez une page qui est générée automatiquement à partir de vos saisies.
Conclusion
Vous avez découvert comment facilement créer des listes d’informations structurées sous WordPress. J’espère que ce tutoriel vous fera gagner du temps, et n’hésitez pas à me contacter si vous avez des questions.
Ce site web, qui présente mes activités professionnelles et mes projets personnels, s’est offert un coup de jeune ! Découvrez notamment la section cas d’usages, présentant quelques exemples de projets que j’ai mené, et la partie blog, qui va à l’avenir disposer d’articles de vulgarisation technique ou des retours d’expérience.
