Un peu de prospective avec et sur OpenStreetMap🔗

Je l'ai déjà affirmé maintes fois, OpenStreetMap, c'est bien… Maintenant, c'est encore mieux de savoir ce qu'on peut faire avec. Pour l'instant, la partie visible de l'iceberg, celle qui est mise en avant par l'outil, consiste en un outil de réalisation de carte sur internet à la "Google Maps". Cette fonctionnalité est certes très intéressante mais en fait, on peut aller beaucoup plus loin !

C'est parce que les données sont libres, qu'on peut en faire ce que l'on veut. Puisqu'OSM contient plus que des informations sur les routes et chemins, on peut en extraire davantage d'informations et les recouper pour former une argumentation, pour vérifier ce que le terrain révèle plutôt que du pifométrique. Quelques exemples de questions qui peuvent trouver réponses avec OSM:

• Est-ce-que ma ville est bien équipée en transports en communs ?
• Combien y-a-t il de kilomètres de pistes cyclables dans mon département ?
• Quel est le niveau d'exhaustivité d'OSM sur un thème particulier ?

Cet article a pour objet d'illustrer le potentiel d'OSM sur la prospective au niveau d'un territoire. La limite d'étude, car il faut bien en fixer une, sera l'emprise de la région des Pays-de-la-Loire. D'abord parce que c'est une région que je connais, ce qui me permettra d'éviter les erreurs d'appréciation (genre si une commune disparaît du lot de données, je devrais bien pouvoir l'identifier). Ensuite parce qu'il y a suffisamment de données au niveau régional pour permettre une analyse comparative entre départements par exemple.

Avant de nous lancer, il ne faut pas oublier qu'OSM est loin d'être exhaustif en termes de données. Explorer les données va nous permettre également de nous en rendre compte mais surtout de voir "là où le bât blesse" et où il faudrait apporter de l'effort.

Pour les besoins de l'expérience, vous avez besoin d'un SGBD spatial et d'un visualisateur de couches géographiques. Dans mon cas, j'utilise PostGIS comme SGBD spatial et QGIS pour visualiser les données. Si vous ne disposez pas de ces outils, allez sur Google et renseignez-vous sur la manière de les installer. Je pars du principe que ces outils sont bien installés et configurés. L'objet de cet article n'est pas de passer en revue ce point important certes mais qui prendrait des plombes à expliquer.

Avant de commencer, il convient de récupérer les données. En effet, si OSM permet de downloader en temps réel les informations dont vous avez besoin, nous n'allons pas utiliser ce moyen direct mais bien télécharger des données snapshots récentes. Si on procède ainsi, c'est avant tout pour des raisons d'efficacité: des serveurs proposent des snapshots de données, prêts à être intégrés dans une base de données spatiale. Ensuite, il y a les problèmes de trafic réseau: notre limite d'étude (Région Pays-de-la-Loire) représente déjà 25Mo de données brutes.

Pour plus d'informations, sur les modes de récupération, je vous laisse lire l'URL suivante: http://wiki.openstreetmap.org/wiki/FR:Planet.osm . Pour ma part, j'utilise les extraits de géofabrik qui ont l'avantage d'être mis à jour tous les jours. Les données sont disponibles ici: http://download.geofabrik.de/osm/europe/france/ . Pour récupérer les données de notre région d'étude, un simple wget http://download.geofabrik.de/osm/europe/france/pays-de-la-loire.osm.bz2 suffit.

Ces données sont au format .osm qui est du XML à la sauce OSM. Pour information, c'est le format utilisé par JOSM. La référence du XML est présentée dans le Wiki officiel: http://wiki.openstreetmap.org/wiki/.osm . Maintenant, il reste à passer du format .osm à du SQL à injecter dans PostGIS. Pour cela, il existe un script nommé osm2pgsql, qui se charge d'effectuer la transformation et le chargement en base de données directement. Sous Debian, ce script est présent dans le paquet osm2pgsql (d'où un simple # aptitude install osm2pgsql.

L'utilisation du script est triviale:

osm2pgsql -c -d GEOBASE_LOCALE -E 2154 -u -U sid_admin -H localhost -W pays-de-la-loire.osm.bz2`

• -c: permet de créer les tables dans la base de données.
• -d GEOBASE\_LOCALE: permet d'indiquer le nom de la base de données spatiale qui va servir à stocker les données.
• -E 2154: permet de préciser que nous voulons des données en RGF93.
• -u: permet de gérer les problèmes d'encodage UTF-8.
• -U sid\_admin: permet d'indiquer le login de l'utilisateur sous PostgreSQL.
• -H localhost: le serveur est sur localhost.
• -W: demande un mot de passe pour le login PostgreSQL.

Le lancement du script prend généralement du temps: compter environ 1 à 5 minutes de chargement pour une région. Le script génère 4 tables dans la base de données spatiale:

• planet\_osm\_point: qui contient les données ponctuelles.
• planet\_osm\_line: qui contient les données linéaires.
• planet\_osm\_polygon: données sous forme de polygones.
• planet\_osm\_roads: table contenant les données linéaires des routes.

Les tables générées par le chargement des données d'OSM sont directement utilisables dans QGIS. Il suffit de lancer ce dernier, de se connecter à la base de données spatiale, de sélectionner les 4 couches et d'afficher le résultat.

Bon, c'est beau, mais on peut mieux faire: sélectionner ce qu'on veut voir en utilisant une requête SQL depuis QGIS. Un exemple est souvent parlant par rapport à un discours. Si vous voulez afficher uniquement les polygones des communes, la marche à suivre est la suivante:

• Se connecter à la base de données spatiale.
• Sélectionner la couche planet\_osm\_polygon (ne pas double-cliquer).
• Cliquer sur le bouton "Construire une requête":

• Dans la liste des champs, vous pouvez voir tous les Tags d'OpenStreetMap qui existent. Dans notre cas, nous allons sélectionner uniquement les polygones ayant un tag de limite administrative (boundary).
• Sélectionner le champ boundary comme sur l'image précédente.
• Cliquer sur le bouton = pour indiquer qu'on cherche une valeur.
• Cliquer sur le bouton "échantillon" afin de voir quelles sont les valeurs qui existent pour ce champ.
• Dans notre cas, il n'y a que deux valeurs: null ou "administrative".
• Choisir la valeur "administrative".
• La requête sous QGIS est en fait une simple clause WHERE, ce qui dans notre cas est parfaitement ce que nous voulons: WHERE "boundary" = 'administrative'
• En cas de problème, il est possible de revenir en arrière en affichant les propriétés de la couche et, à partir de l'onglet "Général", de cliquer sur le bouton "Constructeur de requête".

Pour connaître la signification des Tags, vous pouvez consulter la page du Wiki dédiée: http://wiki.openstreetmap.org/wiki/FR:Map\_Features .

• Couche: planet_osm_polygon
• Clause WHERE: "admin_level" = 8
• Tag OSM: http://wiki.openstreetmap.org/wiki/Key:admin\_level\#admin\_level

En suivant la méthode présentée plus haut, on obtient le résultat suivant:

Comme on peut le voir, la couverture du territoire de la région Pays-de-la-Loire est loin d'être complète en ce qui concerne les limites communales. Le département de la Mayenne est complètement dépourvu. A ce niveau, j'ai l'impression que les polygones de limites communales n'ont pas été rattachés à la bonne région administrative. Ensuite, le Maine-et-Loire est également loin d'être couvert en totalité. En revanche, en Loire-Atlantique, il ne manque qu'une seule commune et la Sarthe comme la Vendée semblent complètes.

Ce premier niveau d'information est très important: en disposant d'un fond de limites communales, on peut réaliser des cartes statistiques simples. C'est pourquoi, une couverture complète des départements est un impératif. Avec cette couche, on peut élaborer des modèles géométriques simplifiés à l'image de ce que l'IGN fait avec les contours GéoFLA(r).

• Couche: planet_osm_point
• Clause WHERE: "highway" = 'bus_stop'
• Tag OSM: http://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus\_stop

À première vue, on constate une nette différence avec les villes de Nantes et du Mans comparativement à Angers. Dans le Maine-et-Loire, assez peu d'arrêts de bus sont représentés.

• Couche: planet_osm_point
• Clause WHERE: "railway" = 'crossing'

On dispose de vraiment peu d'informations sur ce sujet. Peut-être que la donnée sera disponible uniquement quand le réseau routier et de chemin de fer aura été davantage représenté dans OSM. C'est un tag que j'ai pris au pif !

• Couche: planet_osm_line
• Clause WHERE: "bicycle" IN ('yes','private') OR "highway" = 'cycleway'

• Couche: planet_osm_point
• Clause WHERE: "highway" = 'speed\_camera'

Encore une fois, l'information est loin d'être exhaustive alors qu'il est peut-être possible de récupérer légalement et librement les emplacements (si l'information est considérée comme publique).

Maintenant que nous avons vu quelques exemples, il est important de disposer d'un récapitulatif complet des données présentes dans notre export par Tag d'OSM et par département.

SELECT DISTINCT count(access) As access,
  count("addr:flats"),
  count("addr:housenumber"),
  count("addr:interpolation"),
  count(admin_level) As admin_level,
  count(aerialway),
  count(aeroway),
  count(amenity),
  count(area),
  count(barrier) As barrier,
  count(bicycle) As bicycle,
  count(bridge) As bridge,
  count(boundary) As boundary,
  count(building) As building,
  count(capital) As capital,
  count(construction),
  count(cutting),
  count(disused),
  count(ele),
  count(embankment),
  count(foot),
  count(highway),
  count(historic),
  count(horse),
  count(junction),
  count(landuse),
  count(layer),
  count(learning),
  count(leisure),
  count("lock"),
  count(man_made),
  count(military),
  count(motorcar),
  count("name"),
  count("natural"),
  count(oneway),
  count(poi),
  count(power),
  count(power_source),
  count(place),
  count(railway),
  count(ref),
  count(religion),
  count(residence),
  count(route),
  count(service),
  count(sport),
  count(tourism),
  count(tunnel),
  count(waterway),
  count(width),
  count(wood)
from planet_osm_point;

Après ce petit tour dans les données d'OSM, on voit qu'on peut faire pas mal de choses avec. On voit également que le niveau d'exhaustivité est à améliorer avec, par exemple, les limites communales qui ne sont pas toujours complètes d'un département à l'autre. OSM dispose d'un vrai potentiel que notre petit exercice vient illustrer. Il donne au citoyen, l'occasion de se rendre compte avec des éléments simples de la réalité du terrain. Cela lui permet de devenir un peu plus acteur de son environnement grâce à l'apport d'une meilleure connaissance du territoire où il vit.

On le voit bien, la crédibilité d'OSM ne se fera que lorsqu'il sera plus complet car pour l'instant, le volume d'information est assez faible et on voit que des disparités grandes sont présentes selon le lieu où l'on se trouve (grandes métropoles urbaines souvent bien fournies au contraire des zones rurales). Maintenant, on comprend mieux pourquoi OSM est surtout orienté sur le "remplissage": tous les outils de base sont faits pour créer de la donnée alors qu'on compte assez peu d'outils qui s'appuient sur cette donnée. En attendant, concrètement, l'accent doit être mis sur les limites communales: c'est le premier effort à porter, car il permet de disposer d'éléments de comparaison avec d'autres sources de données.