Préambule

Pour ceux qui veulent aller vite, il suffit d'aller lire dans la partie Base de connaissance. Pour ceux qui veulent comprendre, la suite est ci-dessous...

Pour mes vacances, j'ai choisi d'explorer la côte sud de l'Irlande. Pour me diriger dans le pays, je me suis demandé si les données OSM étaient d'un niveau suffisant pour se repérer efficacement sur place. J'ai donc mené une petite expérimentation consistant à utiliser QGis sur un ordinateur portable ainsi que des fonds de plans issus d'OSM, le tout directement sur le terrain.

Pour répondre rapidement à la question des résultats de cette expérience, sachez que l'état des données OSM sur l'Irelande est vraiment d'un bon niveau. Elles sont suffisament précises, même sous la forme d'un simple fond raster pour se repérer sur la route, pour faire du shopping, pour retirer de l'argent liquide, pour se repérer dans la ville (même de petite taille), pour faire de la randonnée, pour trouver un pub ou un restaurant, etc.

Reste la question du comment ? Exploiter des données OSM sur un pays entier demande de télécharger les données pour les afficher. Vu la complexité du modèle OSM qui est plutôt un meta-modèle (un modèle de modèle), pas facile de le représenter directement à partir des informations vectorielles (stockées dans une DB PostGIS). Je n'ai pas essayé mais je pense que le rendu de ces données vectorielles est lourd sur une machine limitée en performances (un ordinateur portable de 2014). De plus, il faut passer beaucoup de temps pour styler les objets. Je me suis donc simplement fixé l'objectif de générer des dalles raster qui correspondent à celles qui sont récupérées depuis les serveurs de tuile de la fondation (qui permettent l'affichage sur la carte dynamique du site openstreetmap.org).

Introduction

Pour ceux qui ne savent pas, les tuiles sont des dalles raster de petit format (256x256 pixels souvent) qui sont stockées sous forme de fichiers (un par dalle). Ces fichiers sont organisés dans une arborescence du type /zoom/longitude/latitude, comme par exemple: /6/234/456.png. L'intérêt de cette méthode c'est qu'une simple requête HTTP permet d'accéder à ce fichier si celui-ci est servi par un serveur Web. Pour calculer la longitude et la latitude en fonction du zoom, un algorithme assez simple a été mis en oeuvre. Ce que je viens de décrire (algorithme+règle de stockage+serveur web) est un protocole nommé TMS Son application est plutôt simple. Par exemple, QGis est capable d'accéder à ces rasters directement. Un autre exemple plus concret est celui de la carte dynamique OpenStreetMap: votre navigateur web contient une bibliothèque Javascript (Leaflet) qui se charge d'aller récupérer les tuiles en fonction de l'endroit où vous êtes situé. Leaflet sait accéder à des rasters servis par le protocole TMS.

Génerer ces dalles ou ces tuiles n'est pas si complexe que ça pour peu qu'on dispose d'un peu de puissance de calcul et qu'on ne souhaite pas zoomer trop loin tout en travaillant sur un pays à taille raisonnable. Cet article se propose de présenter une méthode pour générer des tuiles ou des dalles rasters telles qu'elles sont représentées sur le site d'OpenStreetMap. Il n'a pas la prétention de faire le tour du sujet mais l'objectif est bien de faire comprendre ce qu'on fait. Pour des raisons de facilité de déploiement, le système d'exploitation utilisé est GNU/Linux Debian Jessie. On doit pouvoir faire la même chose sous MS-Windows mais le processus sera plus compliqué, notamment parce qu'il y aura beaucoup plus d'éléments à installer et que certaines versions en ligne de commande des outils employés ne sont pas disponibles sous forme de binaires. De plus, la chaîne de traitement est complètement réalisable en ligne de commande ce qui permet de lancer et d'automatiser le travail sur un (ou plusieurs) serveur(s), sans besoin d'une interface graphique.

Au delà des données OSM, cet article permettra de vous montrer que la génération de tuiles avec des outils libres est à portée de main de tout chef de projet technique géomatique ou même à l'amateur éclairé. Si vous avez du contenu propre (qui vous appartient), vous pouvez donc monter un service TMS à moindre frais tout en maîtrisant complètement ce que vous faîtes.

La méthode

Le principe est assez simple. On souhaite fabriquer de la donnée raster à partir de données vectorielles publiquement disponibles. La communauté OSM a développé un grand nombres d'outils pour réaliser ce travail. Ces outils sont utilisés sur la chaîne de production d'OSM pour afficher la carte dynamique du même nom. Ils sont donc largement éprouvés. Je me suis d'ailleurs cantonné à rester au plus proche de ce que la fondation fait histoire d'être sûr d'avoir des résultats.

Voici une petite synthèse du déroulement de la génération des tuiles:

  • Le premier acte, c'est de télécharger les données publiques d'OSM.
  • Une fois ces données récupérées, il faut les charger dans un stockage adapté. Ce sera une base PostGIS.
  • Après le stockage, il nous faut un outil pour générer des tuiles. L'outil de l'état de l'art se nomme MapNik.
  • Ce dernier est en fait une bibliothèque qui dispose de nombreux bindings (en Python notamment).
  • Il nous faudra donc un outil de génération qui s'appuie sur MapNik. Celui que j'ai utilisé se nomme generate_tiles_multiprocess.py. J'ai également employé Nik4 pour générer des dalles rasters en plus des tuiles.
  • Un détail d'importance: pour passer du vectoriel au raster, il faut indiquer quel est le style du rendu. MapNik utilise un fichier de définition de rendu sous la forme d'un fichier XML.
  • Le fichier de style de rendu officiel d'OSM est lui-même généré par un outil: carto-css.
  • Carto-css est une tentative de définition de styles via des règles CSS. C'est une sorte de GéoCSS. Il a donc besoin de fichiers CSS. Ces derniers sont disponibles sur le compte github d'OSM.
  • On a donc les outils, les données, les styles, on peut générer les tuiles et les dalles.
  • Ensuite, il faudra configurer QGis pour accéder aux dalles et aux tuiles.

Un petit schéma s'impose pour mieux visualiser le processus:

TODO: Ascii Art schema

Recette à suivre pour la génération de tuiles

Preparation d'une base PostGIS

Je vais aller très vite sur ce point. L'article n'a pas vocation à présenter PostGIS, ni à indiquer comment on configure l'ensemble. Pour éviter d'être sec, je présente une méthode simpliste, qui privilégie la faible durée de mise en place, mais qui fonctionne. La sécurité est bien sûr complètement à revoir.

On commence par installer postgresql et PostGIS:

# aptitude install postgresql-9.3-postgis-2.1

Ensuite, on peut créer une base de données spatiale (nommée geobase) et on y ajoute les bonnes extensions. D'abord postgis qui permet d'installer les fonctions PostGIS et ensuite hstore dont MapNik a besoin pour requêter efficacement la base.

# su postgres
$ createdb geobase
$ psql -d geobase -c "CREATE EXTENSION postgis;"
$ psql -d geobase -c "CREATE EXTENSION hstore;"

Pour des questions de rapidité, j'ai donné un accès total à toutes les bases à l'utilisateur postgres en localhost. C'est juste pour faire l'économie de création d'un utilisateur et de la gestion des droits qui va avec (je ne fais pas un cours PostgreSQL). Modifiez votre fichier /etc/postgresql/9.4/main/pg_hba.conf et vérifier que vous avez au moins les lignes suivantes:

local   all             postgres                                trust
host    all         postgres         127.0.0.1/32       trust
host    all         postgres         ::1/128            trust

Installation des outils indispensables présents sous Debian

Debian met déjà à disposition des outils dont nous avons besoin. Pas besoin d'aller les chercher sur Internet, il suffit de mobiliser les serveurs de dépôt de la distribution.

Ici, on a besoin de GDAL pour mapnik. Il nous faut également MapNik, carto-css (qui a pour nom node-carto dans Debian) ainsi que l'utilitaire de chargement de données OSM dans PostGIS, osm2pgsql:

# aptitude install gdal-bin mapnik-utils osm2pgsql node-carto phyton-shapely

Téléchargement des données de base et des outils externes

Nous allons d'abord préparer un répertoire qui va contenir les données sources ainsi que les outils externes de la distribution Debian. Ce répertoire sera nommé osm_tiles. Il contiendra des outils présents dans le répertoire tools:

$ mkdir -p ~/osm_tiles/tools
$ cd ~/osm_tiles

Il nous faut maintenant les styles officiels qui sont utilisés par OpenStreetMap pour la génération de tuiles. Ils sont disponibles en ligne sur GitHub. Il suffit donc de les rapatrier pour pouvoir s'en servir:

$ git clone https://github.com/gravitystorm/openstreetmap-carto
$ cd openstreetmap-carto

Maintenant, nous pouvons télécharger l'outil generate_tiles_multiprocess.py. Ce script Python se charge de générer les tuiles tout en parralélisant le travail sur plusieurs files simultanées. Si vous avez un processeur avec plusieurs coeurs, cela permet de les faire fonctionner et d'augmenter un peu plus les performances. Donc même si le script est en Python, il reste néanmoins assez performant et tire parti du multi-coeur (ce qui, en 2014 est souvent un constat sur la majorité des machines modernes, y compris ARM):

$ wget http://svn.openstreetmap.org/applications/rendering/mapnik/generate_tiles_multiprocess.py
$ chmod 755 generate_tiles_multiprocess.py

En plus des styles, il faudra télécharger des données de base. Ces dernières vous permettront d'afficher les zooms à partir de 0. En effet, lorsque vous générez des tuiles, vous utilisez les données que vous avez incorporées dans votre base PostGIS. Néanmoins, si on se contente de ces données, il sera impossible d'afficher les premiers niveau de zoom. Il faut donc des données (dites de base parce qu'elle ne concerne que les premiers niveaux de zoom) soient présentes pour pouvoir générer l'image du globe terrestre qui correspond au niveau de zoom 0. De plus, les fichiers de style d'OSM ont recours à ces fichiers de base donc si l'on souhaite les utiliser tels quels, il faudra récupérer ces fichiers. Les fichiers qu'on a récupéré depuis GitHub contiennent un script qui va se charger de télécharger ces données de base, les décompresser et effectuer une préparation minimale (quelques modifications pour les rendre compatibles avec les styles d'OSM).

$ ./get-shapefiles.sh

Une fois les styles, l'outil et les données de base téléchargés, il reste à télécharger les données d'OSM. Vous pouvez aller sur le site geofabrik.de qui rencense les jeux de données librement accessibles. Pour ma part, c'est celui de l'Irlande:

$ wget http://download.geofabrik.de/europe/ireland-and-northern-ireland-latest.osm.pbf

Maintenant, il reste à importer ces données dans notre base PostGIS.

Import des données d'OSM dans une base PostGIS

Nous allons injecter les données dans la base de données geobase que nous avions créée auparavant. OSM propose un outil pour ça: osm2pgsql(installé par le paquet debian du même nom). Son utilisation est assez simple:

$ osm2pgsql -k -c -S openstreetmap-carto.style -d geobase -U postgres ireland-and-northern-ireland-latest.osm.pbf

On utilise un fichier de style de base fourni par ce qu'on a récupéré depuis GitHub. Ce fichier permet d'affecter un style par défaut aux objets OSM qui seront stockés dans la base PostGIS. Les autres options sont connues:

  • -d: indique quelle base de données utiliser (geobase dans notre exemple)
  • -U: indique quel utilisateur ser employé pour la connexion à la base (postgres dans notre exemple)
  • -c: indique qu'on va créer de nouvelles tables et qu'il ne s'agit pas d'un ajout

Enfin, le dernier paramètre est le nom du fichier .pbf qui contient les données brutes compressées d'OSM.

Compiler les fichiers carto-css en style MapNik

Comme je l'avais déjà évoqué plus haut, MapNik utilise un fichier de style dans son format propre. Il ne sait pas lire les styles carto-css. Il faut donc compiler ces derniers pour obtenir un fichier de style mapnik. Le fichier de style au format carto-css qui nous intéresse se nomme project.mml.

Les fichiers carto-css sont assez complets, notamment, il contiennent de quoi accéder à la donnée. Par exemple, on doit indiquer dans ces fichiers que telle couche est contenu dans telle table PostgreSQL (en général, c'est même carrément une requête SQL). Il nous faut donc changer le mode d'accès par défaut et renseigner les bons éléments de connexion pour indiquer que le serveur est accessible via localhost, que notre base de données s'appelle geobase et qu'on va y accéder par l'utilisateur postgres (pas bien) sans mot de passe (encore plus pas bien).

Une simple manipulation par sed permet de s'en sortir sans devoir éditer le fichier à la main, ce qui se révèle assez fastidieux vu le nombre de couches à changer:

$ sed -i '/"dbname": "gis"/c \\t"dbname": "geobase"' project.mml
$ sed -i '/"dbname": "geobase"/ i \\t"user": "postgres", \n\t"host": "localhost",' project.mml

Une fois ces corrections réalisées, on peut générer le fichier de style MapNik avec le compilateur carto-css qui se nomme simplement carto:

$ carto project.mml > mapnik.xml

Il reste enfin un dernier nettoyage à faire dans le fichier mapnik.xml: celui des polices. En effet, le fichier généré indique un grand nombre de polices de caractères requises pour générer les tuiles. C'est notamment utile lorsqu'on souhaite gérer des alphabets différents (mandarin, japonais, etc.). Je vous conseille de supprimer toutes les polices indiquées sauf la police DejaVu car, en règle générale elle est installée par défaut sur les systèmes d'exploitation GNU/Linux, ce qui n'est pas le cas des autres.

Déterminer l'emprise géographique à générer et les seuils de zoom

Lorsque vous allez générer des tuiles ou des dalles raster, il faudra indiquer dans quelles limites de carte vous souhaiter opérer. C'est un pré-requis car l'outil generate_tiles_multiprocess ne peut fonctionner sans. Dans notre cas, il faudra récupérer les coordonnées de la zone qu'on souhaite exporter, c'est à dire l'emprise de l'Irlande (ou d'un peu moins si vous explorez juste le sud ou le nord).

De même, il vous faudra déterminer de quels niveau de zoom vous avez besoin. Plus le zoom est important, plus le niveau de détails sera fin, plus il y aura de tuiles à générer. Pour ma part, je suis descendu au niveau 17.

Pour déterminer l'emprise, le plus simple est de se rendre sur la carte dynamique d'OpenStreetMap et d'utiliser l'outil Exporter. Vous pouvez choisir la zone à exporter manuellement. Ensuite, pour récupérer l'emprise dans le bon ordre, le plus simple est de récupérer l'URL de l'API overpass (en rouge):

overpass URL

Voici un exemple de cette URL pour l'Irlande: http://overpass-api.de/api/map?bbox=-10.673,51.406,-5.938,54.304 . Ce qui nous intéresse est à droite de la variable bbox.

Pour les niveaux de zoom, utilisez encore la carte d'OSM et zoomez au maximum de ce que vous voulez voir. Il suffit ensuite de relever l'URL dans la fenêtre de titre. Par exemple: http://www.openstreetmap.org/#map=18/52.44848/-9.05243. Le zoom vaut ici 18.

Génération des tuiles

Avant de lancer generate_tiles_multiprocess.py, il faut modifier la dernière partie de son code. En effet, on doit lui indiquer le fichier de style MapNik à utiliser, le répertoire qui va contenir les tuiles ainsi que l'emprise de calcul et les seuils de zoom qu'on désire obtenir. Il suffit d'avoir des lignes qui ressemblent à ce qui suit:

...
if __name__ == "__main__":

    home = os.environ['HOME']
    try:
        mapfile = os.environ['MAPNIK_MAP_FILE']
    except KeyError:
           # emplacement du fichier de style MapNik
           mapfile = '/home/medspx/osm_tiles/openstreetmap-carto/mapnik.xml'
    try:
        tile_dir = os.environ['MAPNIK_TILE_DIR']
    except KeyError:
    # répertoire de stockage des tuiles
        tile_dir = '/home/medspx/osm_tiles/wtms/'

    if not tile_dir.endswith('/'):
        tile_dir = tile_dir + '/'

    #-------------------------------------------------------------------------
    # Change the following for different bounding boxes and zoom levels
    #
    # Emprise de l'irlande:
    bbox = (-10.673, 51.406, -5.938, 54.304)
    # 18 correspond à notre seuil de zoom maximal
    render_tiles(bbox, mapfile, tile_dir, 0, 18, "World")

Une fois les modifications réalisées, il n'y a plus qu'à lancer le script.

$ ./generate_tiles_multiprocess.py

Toutes les tuiles seront stockées dans le répertoire osm_tiles/wtms.

Attention, le processus de génération est très gourmand en ressources CPU et il est très long. Pour l'étendue indiquée précédemment et pour aller jusqu'au seuil de zoom, il m'a fallu plus de 48h sur un core i7 avec 8G de RAM !

Voir les tuiles avec QGis

Pour voir les tuiles avec QGis, on va émuler un serveur de tuiles qui parle TMS. La seule différence c'est qu'on va se passer du serveur Web. En effet, tout est stocké dans un répertoire. Donc il suffit de faire une "requête" sur une URL locale (celles qui commencent par file:// au lieu de http://).

Pour accéder à un service TMS, QGis utilise un fichier de définition. Ce dernier est un fichier XML avec quelques balises adaptées. Sans entrer dans les détails du service TMS, sachez que celui-ci utilise souvent une projection spécifique: EPSG:3857, destinée à servir au mieux les services de tuiles dont l'emprise est mondiale. DAns notre cas, nous avons utilisé les outils de génération de tuile d'OSM qui a une emprise mondiale. Donc, même si je ne l'ai pas indiqué auparavant, sachez que la projection par défaut de nos tuiles est l'EPSG:3857.

Voici le contenu d'un fichier de définition de service TMS pour QGis:

<GDAL_WMS>
    <Service name="TMS">
        <ServerUrl>file:///home/medspx/osm_tiles/wtms/${z}/${x}/${y}.png</ServerUrl>
    </Service>
    <DataWindow>
        <UpperLeftX>-20037508.34</UpperLeftX>
        <UpperLeftY>20037508.34</UpperLeftY>
        <LowerRightX>20037508.34</LowerRightX>
        <LowerRightY>-20037508.34</LowerRightY>
        <TileLevel>18</TileLevel>
        <TileCountX>1</TileCountX>
        <TileCountY>1</TileCountY>
        <YOrigin>top</YOrigin>
    </DataWindow>
    <Projection>EPSG:3857</Projection>
    <BlockSizeX>256</BlockSizeX>
    <BlockSizeY>256</BlockSizeY>
    <BandsCount>3</BandsCount>
    <Cache />
</GDAL_WMS>

Il suffit d'en enregistrer le contenu dans un fichier et de l'ouvrir en tant que raster dans QGis. On voit que l'URL de la balise est spécialement modifiée pour accéder à des tuiles par fichiers plutôt que par une requête HTTP. Cela permet de charger la couche directement dans QGis, simplement en indiquant le répertoire où vous avez stocké les tuiles (~/osm_tiles/wtms normalement).

Attention, ce mode de consultation a quelques lacunes. En effet, nous n'avons pas généré toutes les tuiles de toute la planète (et pour cause, il faudrait quelques semaines ou mois entiers). Seules sont disponibles celles qui concernent notre "zone", c'est à dire l'emprise de l'Irlande. Si vous tentez de zommer en dehors de cette emprise, QGis va chercher les fichiers qui correspondent mais comme ces derniers n'existent pas, il va déclencher l'affichage d'un raster vide. Par effet de bord, cet affichage va corrompre les données affichées et généralement, un grand cadre noir va s'afficher. Parfois, on tombe sur un mélange plus complexe de couleurs mais qui n'ont toujours rien à voir avec ce qui devrait s'afficher (du blanc pour ce qui est vide et le reste des tuiles existantes si on est dans l'emprise).

Vous devez donc toujours prendre soin de vous trouver à un endroit où il y a des tuiles sinon vous aurez un bug d'affichage...

Autre point négatif: le chargement de la couche est un poil long. Il faut quelques secondes pour que l'affichage se charge correctement ce qui rend la navigation un peu fastidieuse pour cause de rafraîchissement intempestif.

Pour régler ce problème, on peut s'employer à générer des dalles raster plutôt que des tuiles...

Je veux des dalles raster !

Cette opération est un peu plus technique car elle a recours à une chaîne d'utilitaires un peu plus complexe et moins automatisée (même si un bon administrateur système doit savoir gérer ça sous forme d'un bon script shell des bois).

Pour générer des dalles raster plutôt que des tuiles, on va utiliser un autre utilitaire que j'ai légèrement hacké pour le rendre plus docile. Il se nomme Nik4 et il est disponible sur GitHub également. Vous trouverez la version modifiée ici

Le hack permet de faire en sorte que Nik4 génère des dalles de gros volume en effectuant son travail par découpage de la plus grande zone qui peut tenir en mémoire. Il génère alors des fichiers Tiff qu'on peut ensuite assembler dans un fichier vrt (raster virtuel). Attention, Nik4 ne travaille qu'avec un niveau de zoom. Il faudra donc lancer la commande autant de fois qu'il faut pour chaque niveau de zoom. Pour disposer de la même couverture qu'avec les tuiles, il faudra recommencer l'opération 18 fois (18 niveaux de zoom).

Voici le principe de fonctionnement de la génération de dalles:

  • On demande à Nik4 de générer une dalle sur une emprise donnée à un seuil de zoom donné avec un fichier de style mapnik.
  • Nik4 génère un ensemble de dalles raster au format Tiff nommée en fonction d'un paramètre de lancement.
  • Pour chacune des dalles raster, Nik4 génère un fichier worldfile qui permet d'indiquer les coordonnées d'emprise du raster individuel.
  • Une fois le travail de Nik4 terminé, on va générer un fichier de raster virtuel.

Je vous montre à quoi ça ressemble:

$ ../Nik4/nik4.py -b -10.673 51.406 -5.938 54.304 -z 14 mapnik.xml ireland.tiff --wld ireland.wld --tiles 4

Avec cette commande, on demande à Nik4 de:

  • Travailler sur l'emprise -10.673 51.406 -5.938 54.304
  • à un zoom de 14
  • d'utiliser le fichier de style nommé mapnik.xmk
  • de générer des fichiers dont le nom sera basé sur ireland.tiff (ça donnera ireland_0x0.tiff par exemple)
  • de générer des fichiers worldfile basé sur le nom ireland.wld (un par dalle découpée)
  • d'essayer d'utiliser 4 dalles pour faire le travail complet.

Sur le dernier argument, Nik4 rend la main s'il n'y a pas assez de dalles. Pour le niveau 17 par exemple, j'ai du monter cette valeur à 28 pour que tout tienne en RAM. Globalement Nik4 est un peu plus rapide que generate_tiles_multiprocess.py mais l'ordre de grandeur sera identique (compter deux jours).

Une fois un ensemble de dalles obtenu, il faut les mettre dans un répertoire. Dans mon cas, j'ai créé un répertoire par niveau de zoom. Ensuite, il suffit de demander à gdalbuildvrt de faire le travail de fabrication du raster virtuel:

$ gdalbuildvrt -a_srs EPSG:3857 Ireland_13.vrt *.tiff

Ici, on demande à gdalbuildvrt de fabriquer un raster virtuel nommé Ireland_13.vrt avec tous les tiff du répertoire courant. La projection sera ESPG:3857.

Ensuite, vous avez juste à ouvrir le fichier Ireland_13.vrt dans QGis pour profiter du niveau de zoom 13 de vos dalles OSM. L'opération est à renouveler pour chaque niveau de zoom. Plus le niveau de zoom est élevé plus la génération de dalles sera lente.

Dans la pratique, les dalles s'ouvrent nettement plus rapidement que les tuiles locales. Pour obtenir un comportement identique aux tuiles TMS qui changent en fonction du niveau de zoom, vous pouvez indiquer des échelles d'affichage mini et maxi pour chacune de vos dalles raster. De cette manière, un zoom fera disparaître une dalle et en affichera une plus détaillée (passage du zoom 13 au zoom 14 par exemple). Cette manipulation ne devrait pas venir à bout d'un utilisateur QGis de niveau intermédiaire.

Conclusion

Cet article démontre qu'il est assez facile de générer des tuiles raster à partir des données OSM. Le tout est facilement industrialisable car les outils s'exécutent tous en ligne de commande. On peut donc imaginer un système de génération automatisé de ces tuiles qui se lance tous les jours pour calculer différents jeux de tuiles. En effet, dans notre example, nous n'avons utilisé qu'un seul jeu de style: celui d'OSM. On aurait très bien pu imaginer une dizaine de jeux de styles différents, chacun se rapportant à une thématique ou à un objectif. Par exemple, vous voulez peut-être faire apparaître uniquement les contours administratifs, ou encore uniquement les zones urbaines, ou encore uniquement tout ce qui se rapporte à la préservation de l'environnement naturel, etc.

Pour réaliser des jeux de style, vous pouvez vous aider d'un outil assez sérieux sur le sujet: TileMill. Il est développé sous une licence libre par la société MapBox. Ce logiciel se veut un moyen simple et visuel de créer des styles cartographiques à partir de différentes sources (requêtes postGIS/shapefiles/etc.) et d'en générer les fichiers carto-css qui en découlent.

Pour terminer et en guise de prospective, on pourrait imaginer que QGis prenne en charge ce format carto-css. L'élaboration de ces fichiers et des tuiles qui s'y rapportent serait alors très accessible: l'utilisateur utiliserait les propriétés de style très fournies de QGis ainsi que la possibilité de ce dernier de lire un très grand nombre de formats de fichiers géographiques pour fabriquer visuellement un ensemble de cartes. Avec la chaîne de traitement (et quelques améliorations sans doute) présentée ci-dessus, une organisation pourrait alors facilement mettre en oeuvre une gamme élargie de services cartographiques Web via le protocole TMS avec peu d'efforts.

Posted ven. 22 août 2014 18:46:35 Tags:

Voilà, c'est fait ! Suite à mon dernier article sur l'import du bâti du cadastre du Maine-et-Loire, j'avais eu pas mal de réactions qui m'enjoignaient de faire des corrections. En effet, mon import engendrait un certain nombre de problèmes dont le plus important était la remonté de nombreuses erreurs de croisement entre des voies de circulation et des bâtiments, ce qui, en temps normal, ne devrait pas se produire.

Cette erreur est essentiellement due au fait que le cadastre est généralement plus précis que le référentiel utilisé pour créer les routes dans OpenStreetMap. Pire, j'ai souvent vu des erreurs liées à une création de voie à partir des orthophotos de Bing. Très clairement dans certains coins, Bing a un vrai décalage par rapport au cadastre, non pas en précision mais en position pure: Bing est clairement à côté de la plaque dans ces lieux. Je pense sincèrement que le référentiel du cadastre est plus précis que Bing car il constitue un référentiel précis (au 1/5000).

Ces corrections ont clairement pris du temps mais pas autant que la réalisation de l'import pur, c'est déjà une bonne chose. La méthode que j'ai employée est assez simple. J'ai utilisé l'outil d'assurance qualité mis à disposition par la communauté OSM France et consultable sur http://osmose.openstreetmap.fr. Avec la requête suivante: il est possible d'avoir la liste des erreurs pour un utilisateur précis, selon le type d'erreur. Ensuite, j'ai utilisé la carte dynamique d'Osmose pour visualiser les problèmes à l'affichage. Dans un autre onglet, j'ouvrais une fenêtre OSM en mode modification avec l'éditeur iD.

L'intérêt d'avoir les deux fenêtres proches l'une de l'autre permet d'avoir en permanence la localisation géographique des problèmes à corriger tout en ayant la fenêtre de modifications sous la main. Je me suis donc appuyé uniquement sur le web pour réaliser toutes les corrections et j'ai trouvé ce mode de travail assez pratique. JOSM est plus complexe, l'import de données est beaucoup plus lent et ne m'a pas semblé pertinent pour réaliser un ensemble de corrections à la volée, réparties sur tout un département. J'ai donc pu constater à quel point l'éditeur iD est maintenant mûr et très fonctionnel. Grâce à lui, des modifications simples peuvent être réalisées, y compris si elles sont nombreuses, pour peu qu'on puisse s'astreindre à avoir un travail continu.

Je réserverai donc JOSM aux travaux d'import ou aux corrections massives sur un territoire raisonnable (une commune au maximum). De plus, je vous conseille également de faire attention au comportement de JOSM. Car ce qui m'a semblé étrange c'est que JOSM ne m'ait pas indiqué les erreurs de chevauchement. J'avais bien les erreurs liées à la géométrie (papillons ou bâtiments se chevauchant par exemple) mais pas les problèmes d'intersection avec les voies. Pourtant JOSM sait gérer ce genre de problèmes. Si vous réalisez des imports de bâti, je vous conseille sincèrement de trouver le moyen de contrôler ces erreurs sous peine de devoir faire comme moi et de retravailler à posteriori.

J'ai été assez surpris par le fait qu'il y avait beaucoup de monde pour me faire remarquer que mon import posait problème mais finalement assez peu de personnes pour faire les corrections ou pour me proposer leur aide. En effet, le petit millier d'erreurs est resté assez volumineux jusqu'à ce que je m'y attelle. Je dois toutefois remercier ceux qui ont contribué et que je n'ai peut-être pas remarqué. Dans tous les cas, mon travail d'import est terminé et c'est une bonne chose...

Posted mar. 17 juin 2014 20:12:00 Tags:

Il y a quelques temps déjà, j'ai effectué l'import du bâti du cadastre du département du Maine-et-Loire dans OpenStreetMap. Pour s'en rendre compte, il suffit de consulter OpenStreetMap au bon endroit, au hasard dans la campagne et de voir que les bâtiments sont tous là !

Mon objectif principal était d'ajouter l'ensemble des habitations du département du Maine-et-Loire et ce, pour toutes les communes, qu'elles soient rurales et peu étendues ou très développées. Lorsqu'on ajoute de telles données précises à la base OSM, de nombreuses autres informations peuvent venir se surajouter comme par exemple ce qui concerne l'adressage ou la définition de l'utilisation d'un bâtiment. Cela permet également d'améliorer la représentation graphique d'OSM en offrant plus de détails sur la carte affichée. Enfin, le cadastre met à disposition cette donnée, il serait bête de ne pas s'en servir !

Pourquoi le Maine-et-Loire ? Simplement, parce que j'y habite et que l'ampleur de la tâche était mesurée: quelques imports ponctuels avaient déjà été réalisés et il restait environ 200 communes sur les quelques 300 du département. Par la suite ce travail m'a permis de me familiariser avec les procédures d'import qui, sans être complexes, doivent êtres suivies avec un minimum de rigueur. Enfin, pendant ce petit travail que j'ai réalisé depuis Toulouse, j'avais l'impression de revenir au pays, notamment en important des communes dans lesquelles j'avais fait des randonnées.

Pour réaliser ce travail, j'ai utilisé les outils standards qui sont proposés par la communauté OSM pour réaliser ce travail, à savoir:

  • L'outil cadastre2osm qui permet de récupérer l'emprise vectorielle des bâtiments depuis le site cadastre.gouv.fr. Cet outil réalise un export PDF d'une commune à partir du site web et converti le fichier résultant en fichier de données qu'on peut traiter dans OSM. Il permet également d'ajouter une grande partie des métadonnées indispensables pour tout import du cadastre.
  • JOSM pour effectuer le contrôle des données ainsi que l'import dans OSM.

J'ai suivi une méthodologie assez simple. J'ai commencé par récupérer dans un fichier Calc la liste des communes depuis le source du HTML de cadastre.openstreetmap.fr. Muni de cette précieuse liste, j'ai vérifié dans la carte OSM quelles communes étaient couvertes en bâtiment et j'ai reporté le tout dans le fichier Calc pour déterminer sur quelles communes travailler. J'ai eu quelques surprises, notamment deux ou trois communes qui avaient des bâtiments directement importés depuis une orthophoto et qui n'étaient manifestement pas très précis et surtout pas exhaustifs.

Ensuite, j'ai appliqué la même recette pour chaque commune:

  • Aller sur http://cadastre.openstreetmap.fr/
  • Choisir la commune à rapatrier
  • Lancer l'import
  • Récupérer les fichiers au format OSM
  • Ouvrir JOSM et y ouvrir le fichier OSM
  • Lancer l'outil de vérification des objets
  • Cet outil permet de lister les problèmes les plus courants (papillons, batiments qui se chevauchent, lignes sans métadonnées, etc...)
  • Grâce à l'outil, on peut se focaliser sur l'emplacement à corriger.
  • Gérer toutes les corrections à la main. En règle générale, il y en a moins d'une centaine par commune. Il faut compter entre 5 minutes et 30 minutes de correction pour les communes les plus complexes (en fait, celles qui présentent le plus de problèmes).
  • Une fois la liste des objets à corriger vide, on peut lancer l'import via JOSM.
  • L'import en lui même prend beaucoup de temps car le nombre d'objets à intégrer est souvent important. Durant cette étape, il est possible que la connexion echoue et il faudra recommencer au début.
  • Une fois l'import terminé, attendre entre 5 et 10 minutes et aller sur la carte OSM à l'emplacement des modifications et zoomer pour faire afficher les bâtiments.
  • Maintenant que les données sont intégrées, on peut mettre à jour la liste des communes à terminer (le fichier Calc).

Comme vous pouvez le constater, c'est très fastidieux et rébarbatif. Mais seule compte la volonté d'intégrer pour mieux partager !

J'ai commencé à réaliser ces travaux d'import sous mon compte classique OSM. Néanmoins, l'équipe en charge des imports m'a vite contrôlé et bloqué. J'ai essayé de négocier en utilisant les arguments présentés par la page wiki consacrée à l'import du cadastre mais l'équipe en charge des imports n'a rien voulu savoir. J'ai donc dû me créer un autre compte pour l'occasion. C'est vraiment dommage car après cet import du cadastre, je n'ai rien réalisé de plus massif.

L'ensemble des travaux m'a occupé environ une vingtaine d'heures ce qui n'est pas négligeable. En général, je générais environ une dizaine de fichiers .OSM que j'importais et corrigeais dans JOSM dans la foulée, lors de ma pause déjeuner. Le soir venu, je faisais les imports à la chaîne tout en faisant autre chose en même temps car ils sont très longs. Même si c'était fastidieux, j'ai maintenant le plaisir de vous annoncer que le département est complètement couvert (en fait depuis le 08/10/2013): peu importe où vous promènerez votre zoom, vous y trouverez les bâtiments du cadastre !

Maintenant que ce contenu est intégré dans la base de données, il reste à le prendre en compte. En effet, il rajoute plus de précision à l'ensemble des informations d'OSM, et ce, à une échelle plutôt grande. Ainsi, il n'est pas rare que des routes qui ont été importées avec d'autres référentiels moins précis coupent les habitations ce qui remonte des erreurs dans les outils de contrôle. Mais OSM est avant tout collaboratif: vous êtes libre de corriger les imperfections (qui sont nombreuses, je dois le reconnaître)... A vous de jouer !

Posted ven. 02 mai 2014 19:06:00 Tags:

Introduction

La Direction Générale des Finances Publique fait vraiment un travail formidable sur le domaine de l'Opendata et de l'information géographique. En effet, elle produit, dans un silence relatif si l'on compare à ce qui se passe sur les différentes plateformes Opendata des collectivités locales, un outil essentiel à la connaissance de notre territoire. Cet outil, c'est le Plan Cadastral. Avec la modernité, ce Plan Cadastral est maintenant numérique. Pour aller plus loin, il est même complètement disponible et gratuitement sur le site http://www.cadastre.gouv.fr que je vous recommande de consulter. Depuis quelques années maintenant, le projet OpenStreetMap a obtenu l'autorisation écrite d'utiliser les ressources de cadastre.gouv.fr pour générer du contenu dans OpenStreetMap.

Car il faut bien reconnaître que le cadastre est très intéressant pour cet usage. En effet, c'est un document qui est globalement assez complet, assez précis. Il permet notamment d'importer l'intégralité des bâtiments cadastrés, les emplacements des rues ainsi que les noms des lieux-dits et, pour finir, l'ensemble des surfaces en eaux. C'est également un document dont la couverture est quasi-totale et égale sur le territoire (à de rares exceptions près). Il permet donc de régler un des problèmes majeurs d'OpenStreetMap, à savoir, la faible couverture dans les communes rurales ou isolées qui ne bénéficient pas d'un grand nombre de "mappeurs" OpenStreetMap. Grâce au cadastre, nul besoin de se déplacer pour importer bâti et routes, voire adresses postales.

Si je devais vous montrer l'intérêt du cadastre dans OpenStreetMap, je prendrais un seul exemple sous forme d'images:

A gauche, le coeur d'une ville bien connue: San Francisco. A droite, un petit village perdu du Maine-et-Loire. La différence est saissisante: d'un côté on a bien les rues, de l'autre côté, il y a tout: les maisons, les rues, les lieux-dits, les cours d'eau, les étangs, le tout avec le nommage qui va bien. Il suffit d'un peu de motivation et surtout des bons outils pour réaliser ce travail d'import.

Sur ce point technique, certes il existe l'interrogation du site www.cadastre.gouv.fr qui présente un outil Web pour afficher le cadastre à un niveau de détail avancé. Cette application Web repose sur l'interrogation d'un serveur WMS accessible après connexion (cookie nécéssaire). Néanmoins il existe également un plugin dédié dans JOSM, nomme cadastre-fr. Ce dernier agit en téléchargeant des dalles rasters depuis le serveur WMS du cadastre.

Néanmoins, la solution offerte par JOSM pour télécharger le cadastre comporte quelques inconvénients:

  • d'abord, c'est complexe à configurer: il faut se mettre dans la bonne projection, écrire le nom de la commune tel qu'il sera compris par le serveur du cadastre.
  • ensuite, c'est long à télécharger: quand on importe des données, on a besoin de disposer rapidement de la vision des lieux.
  • enfin, ça consomme de la mémoire à outrance. Télécharger le cadastre entier d'une commune avec ce plugin consomme facilement plus de 2Go de RAM !

Toutes ces raisons m'ont amené à me pencher sur une solution permettant de récupérer une dalle raster du cadastre indépendamment de JOSM pour permettre une visualisation instantanée (ou rapide du moins) dans cet outil pour pouvoir facilement importer des éléments du cadastre. J'ai donc essayé de mettre au point un outil permettant de récupérer ces données directement depuis le site cadastre.gouv.fr.

Utilité et couverture du besoin

L'objectif principal est de créer une dalle raster depuis le serveur WMS de cadastre. Cela permet de disposer d'un document unique manipulable par n'importe quel logiciel de SIG, après récupération.

Voici un bref cahier des charges pour notre outil:

  • Former une dalle raster du cadastre d'une commune.
  • Être facilement installable.
  • S'appuyer sur des outils simples déjà existants.
  • Être simple d'emploi.

Méthode

Après avoir passé en revue nos besoins, voici une petite implémentation de cet outil. J'ai commencé à le réaliser en Python3 avant de m'apercevoir que je pouvais tout faire bien plus rapidement avec un simple script Shell (sous Bash). En effet, une requête WMS n'est rien d'autre qu'une requête HTTP GET bien construite qui retourne un fichier image. Des outils comme wget ou curl savent justement bien faire ce genre de travail.

La complexité vient du fait que le serveur WMS du cadastre requiert un cookie pour donner une réponse correcte. Il est donc indispensable de suivre un minimum la procédure de connexion au site cadastre.gouv.fr et son formulaire de recherche. Requêter ce dernier permet de récupérer le cookie qui nous intéresse ainsi que de vérifier que la commune demandée existe. Une fois munis du cookie et de l'existence de la commune, il faut au préalable récupérer la page HTML de navigation WMS car cette dernière contient les coordonnées de l'étendue de la commune (la bounding box). Une fois qu'on dispose de cette étendue, on peut commencer le téléchargement WMS.

Mais au préalable, il faut requêter intelligemment le serveur WMS. En effet, si on souhaite utiliser le cadastre, c'est pour avoir un niveau de détails assez fin. En conséquence, l'étendue de chaque requete WMS sera donc faible. Ainsi, il nous faudra découper notre étendue globale en autant de dalles WMS que nécéssaires. Pour avoir un bon niveau de détails, j'ai utilisé le même pas que celui du plugin cadastre-fr de JOSM, à savoir un carré de 100m de côté. La tâche suivante consiste donc à faire une boucle qui permet de requêter toutes ces dalles WMS qui donnent pour chacune d'entre elles une image PNG. J'utilise le format PNG car l'agorithme de compression est non destructif ce qui permet d'avoir des images plus nettes, sans artéfacts de compression (comme le Jpeg). Pour une commune, le nombre de fichiers PNG peut atteindre les 8000 ! Cela donnera donc 8000 requêtes WMS ! Pour chaque fichier PNG, on va également générer un fichier pngw, un "worldfile" qui permet de préciser les coordonnées de l'emprise de chaque fichier PNG. C'est indispensable pour pouvoir effectuer un assemblage de ces nombreuses dalles rasters.

Une fois tous les fichiers récupérés, on peut utiliser les outils courants de GDAL pour assembler les fichiers en une seule dalle en deux étapes:

  • Constituer un fichier raster virtuel (VRT) avec la commande gdalbuildvrt.
  • Former un seul fichier au format GeoTiff de ce raster virtuel grâce à la commande gdal_translate.

A la fin, on peut ajouter des pyramides (images précalculées avec une définition moindre directement insérées dans le fichier de dalle) pour accélérer la visualisation avec les outils courants de SIG.

Une fois terminé, il faut bien entendu faire du ménage pour ne garder que l'unique dalle finale.

Pour fonctionner le script s'appuiera sur les outils suivants:

  • curl pour le téléchargement. Je le préferre à wget car il gère beaucoup mieux les serveurs mandataires (proxies).
  • sed pour faire un peu de manipulation de données.
  • gdalbuildvrt pour construire le raster virtuel de manière simple
  • gdal_translate pour générer la dalle finale
  • gdaladdo pour générer les pyramides dans la dalle finale.

sous debian, vous aurez donc besoin d'installer le paquet gdal-bin ainsi que curl.

Le Code

Après les concepts, voici le code. Je le place en lecture directe pour faciliter sa compréhension. Un simple copier coller et il est à vous !

    #!/bin/bash

    # Script de téléchargement de dalles raster de communes depuis cadastre.gouv.fr

    # This program is free software: you can redistribute it and/or modify
    # it under the terms of the GNU General Public License as published by
    # the Free Software Foundation, either version 3 of the License, or
    # any later version.
    #
    # This program is distributed in the hope that it will be useful,
    # but WITHOUT ANY WARRANTY; without even the implied warranty of
    # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    # GNU General Public License for more details.
    #
    # You should have received a copy of the GNU General Public License
    # along with this program.  If not, see <http://www.gnu.org/licenses/>.

    # TODO:
    # Gestion de la projection

    # Vérification de la présence des outils indispensables: sed, gdalbuildvrt, gdal_translate, curl
    CMDS="curl sed gdalbuildvrt gdal_translate gdaladdo"
    for i in $CMDS
    do
    command -v $i >/dev/null && continue || { echo "Vous devez installer $i pour que ce script fonctionne..."; exit 1; }
    done

    if [ ! -n "$1" ]
    then
      echo "Usage: $(basename $0) DEP COMMUNE"
      exit 1
    else
      if [ "${#1}" -ne "3" ]
      then
    echo "Le département doit être écrit sur 3 caractères."
    echo "Ex: 049 pour le Maine-et-Loire."
    exit 1
      fi
      DEP=$1
      COM=$(echo $2 | tr a-z A-Z)
    fi

    echo "Téléchargement de la commune $COM du département $departement..."
    cook=$(mktemp cookie.XXXXXX)
    curl_options="-s -c $cook"
    rm $cook

    # Gestion du proxy
    if [ -n "$http_proxy" ]
    then
      echo "Utilisation du proxy: $http_proxy"
      curl_options="$curl_options --proxy-anyauth -x $http_proxy"
    fi

    # Etape 1: Connexion et récupération du cookie de session
    curl $curl_options "http://www.cadastre.gouv.fr/scpc/rechercherPlan.do" >> /dev/null
    curl_options="-b $cook $curl_options"

    # Etape 2: Vérifier que la commune existe dans le département
    data="numeroVoie=&indiceRepetition=&nomVoie=&lieuDit=&ville=${COM}&codePostal=&codeDepartement=${DEP}&nbResultatParPage=10&x=45&y=11"
    code_com=$(curl --data "$data" $curl_options http://www.cadastre.gouv.fr/scpc/rechercherPlan.do | grep -m 1 -o "afficherCarteCommune.do?c=*" | head -n 1 | cut -d "=" -f 2)


    # Récupération du code de la commune
    echo "Code commune: $code_com"
    #if not alf:
    #    print("Desolé mais la commune {0} est introuvable dans le département {1}".format(args.COMMUNE, args.DEP))
    #    exit(1)

    #print("{0} a pour code commune: {1}".format(args.COMMUNE, code_commune))

    # Etape 3: Connexion à la carte en ligne
    # et récupération de la boundingbox
    url="http://www.cadastre.gouv.fr/scpc/afficherCarteCommune.do?c=${code_com}&dontSaveLastForward&keepVolatileSession="
    coords=$(curl $curl_options "$url" | grep -A 4 "new GeoBox(" | tail -n 4 | sed -e 's/,//g' -e 's/)//g' -e 's/\t//g' | tr '\n' ' ')
    echo $coords | read -d " " -a bbox
    OLDFS=$FS
    FS=
    read -a bbox <<EOF
      $coords
    EOF
    FS=$OLDFS

    # Calcul des coordonnées de bounding box à prendre en compte
    xmin=$(expr ${bbox[0]%.*} / 100)
    xmin=$(expr $xmin \* 100);
    xmax=$(expr ${bbox[2]%.*} / 100)
    xmax=$(expr $xmax + 1)
    xmax=$(expr $xmax \* 100)
    ymin=$(expr ${bbox[1]%.*} / 100)
    ymin=$(expr $ymin \* 100);
    ymax=$(expr ${bbox[3]%.*} / 100)
    ymax=$(expr $ymax + 1)
    ymax=$(expr $ymax \* 100)

    stat_x=$(expr $xmax - $xmin)
    stat_x=$(expr $stat_x / 100)
    stat_y=$(expr $ymax - $ymin)
    stat_y=$(expr $stat_y / 100)
    nb_dalles=$(expr $stat_x \* $stat_y)

    echo "Téléchargement de $nb_dalles fichiers de dalles..."
    # Etape 4: Boucle de récupération des fichiers au format PNG
    x="$xmin"
    i=0
    while [ "$x" -lt "$xmax" ]
    do
      y="$ymin"
      # Définition de la bbox à télécharger:
      a="${x}.0"
      c=$(expr $x + 100)
      c="$c.0"
      while [ "$y" -lt "$ymax" ]
      do
    b="$y.0"
    d=$(expr $y + 100)
    d="$d.0"
    this_bbox="${a},${b},${c},${d}"
    # récupération du fichier PNG
    url="http://www.cadastre.gouv.fr/scpc/wms?version=1.1&request=GetMap&layers=CDIF:LS3,CDIF:LS2,CDIF:LS1,CDIF:PARCELLE,CDIF:NUMERO,CDIF:PT3,CDIF:PT2,CDIF:PT1,CDIF:LIEUDIT,CDIF:SUBSECTION,CDIF:SECTION,CDIF:COMMUNE&format=image/png&bbox=${this_bbox}&width=1000&height=800&exception=application/vnd.ogc.se_inimage&styles=LS3_90,LS2_90,LS1_90,PARCELLE_90,NUMERO_90,PT3_90,PT2_90,PT1_90,LIEUDIT_90,SUBSECTION_90,SECTION_90,COMMUNE_90"
    filename="$i.png"
    echo "Ecriture de $filename ..."
    curl -o $filename $curl_options "$url"

    # Gestion du world file:
    pngw="${filename}w"
    echo -e "0.10\n" > $pngw
    echo -e "0\n" >> $pngw 
    echo -e "0\n" >> $pngw
    echo -e "-0.125\n" >> $pngw
    echo -e "$a\n" >> $pngw
    echo -e "$d\n" >> $pngw

    y=$(expr $y + 100)
    i=$(expr $i + 1)
      done
      x=$(expr $x + 100)
    done

    # Fabrication du fichier VRT
    gdalbuildvrt ${COM}.vrt *.png

    # Génération au format GeoTiff
    gdal_translate -of GTiff -co TILED=YES -co COMPRESS=DEFLATE -co BIGTIFF=IF_NEEDED -co ZLEVEL=9 ${COM}.vrt ${COM}.tiff

    # Ajout des pyramides au GéoTiff
    gdaladdo -r average ${COM}.tiff 2 4 8 16

    # Nettoyage:
    rm $cook *.png *.pngw

    exit 0

Utilisation et limites

L'utilisation de l'outil est très simple, la commande suivante:

$ ./wms_cadastre.sh 049 ANGRIE

permet de télécharger un raster cadastre dans le répertoire courant de la commune ANGRIE située dans le département 049.

Le téléchargement va prendre pas mal de temps puisqu'il faudra réaliser de nombreuses requêtes WMS. L'assemblage est, en comparaison, assez rapide avec les options de création. Il faudra toutefois un peu plus de temps pour générer les pyramides.

Cet outil est loin d'être parfait (mais vous pouvez l'améliorer). Déjà, il est intolérant aux pannes serveurs ou de connexion réseau: si votre requête plante au milieu d'un téléchargement, il vous manquera vraisemblablement un fichier ce qui occasionnera un trou dans la dalle. Mais dans la pratique, il est tout à fait possible de télécharger 8000 dalles sans incidents.

Un deuxième inconvénient majeur, se situe au niveau de la transparence. Lorsqu'on télécharge une commune donnée, on télécharge tout ce qui se trouve dans une emprise qui est rectangulaire. Les espaces situés en dehors des limites communales retournent du blanc. Ainsi, on télécharge une grosse dalle par commune et il est impossible de l'assembler avec celle d'une autre commune qui serait limitrophe. Il est donc difficile (mais pas impossible si l'on joue avec les options de transparence de GDAL) d'obtenir une dalle raster d'un groupe de communes ou d'un département.

Enfin, le script ne gère pas la projection. Pour ma part, comme je compte travailler sur un secteur limité, la projection sera toujours identique (RGF CC47 soit le code EPSG:3947). Vous pouvez toujours modifier le code EPSG dans la commande gdal_translate si vous souhaitez travailler sur une autre zone.

Intégration dans JOSM

Nous disposons maintenant d'une dalle raster du cadastre d'une commune. Il faut pouvoir la visualiser dans JOSM. J'ai testé plusieurs méthodes pour y parvenir. La première consistait à utiliser un plugin nommé ImportImagePlugin. Son but est simplement de charger une dalle raster géoréférencée dans JOSM. Mais ce plugin est complètement buggé et je n'ai jamais réussi à le faire fonctionner.

Une autre technique consiste à fabriquer un ensemble de tuiles incorporables dans JOSM grâce à sa gestion des couches TMS. Gdal fournit un utilitaire nommé gdal2tiles.py pour faire ce travail de découpage. Mais encore une fois, je n'ai pas réussi à faire correspondre les tuiles à celles requêtées par JOSM. Il y avait toujours un décalage sur les coordonnées y. Impossible de corriger ça, même à la main. De plus, gdal2tiles n'est pas très performant il lui faut quelques heures pour générer un tas de tuiles proposant un bon niveau de détails.

J'ai finalement mis la main sur la bonne méthode qui consiste à utiliser le protocole WMS. Le principe est assez simple: on installe un serveur WMS sur sa machine (en localhost) et on lui demande de servir la couche raster du cadastre téléchargée. Bien entendu, il faut un serveur WMS. Le plus simple que j'ai trouvé est celui qui est installé avec Qgis. Dans Debian, il suffit d'installer le paquet qgis-mapserver. Ce dernier installe un programme accessible en CGI (vous aurez besoin d'un serveur HTTP. Apache2 sera votre ami). Si vous avez une configuration par défaut d'Apache, le serveur WMS est simplement accessible via l'url http://localhost/cgi-bin/qgis_mapserv.fcgi.

Le serveur WMS de Qgis est finalement très simple à configurer. Vous aurez besoin de créer un fichier de projet (.qgs) contenant votre couche raster, de renommer cette couche en CADASTRE dans QGis et d'enregistrer le fichier de projet en ayant soin d'indiquer la bonne projection qui sera celle que vous utiliserez dans JOSM. Je vous invite à utiliser le RGF CC de la commune que vous comptez importer. Bien entendu, le fichier de projet doit être situé dans un répertoire accessible en lecture à l'utilisateur Apache (www-data sous Debian).

Pour configurer la couche WMS dans JOSM, vous aurez besoin de faire un tour dans les Préférences (Menu Modifier -> Préférences) et d'ouvrir l'onglet "WMS/TMS". Ajoutez l'URL vers la bonne couche WMS. En voici un exemple:

wms:http://localhost/cgi-bin/qgis_mapserv.fcgi?MAP=/opt/OSM/WMS.qgs&FORMAT=PNG&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=CADASTRE&STYLES=&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}

Décomposons le contenu de cette URL pour mieux la comprendre:

  • wms: indique qu'on utilise le protocole WMS et non TMS.
  • http://localhost/cgi-bin/qgis_mapserv.fcgi est l'emplacement du binaire CGI du serveur WMS de QGis (sous Debian).
  • Le premier argument de la requête: MAP=/opt/OSM/WMS.qgs est l'emplacement de votre fichier de projet QGis, celui que vous avez fabriqué avec la dalle raster du cadastre.
  • On trouve ensuite des éléments classiques d'une requête WMS: le Format, la version du protocole, le service
  • Un point important se trouve au niveau du paramètre LAYERS. Celui contient le nom de la couche telle qu'elle est présentée dans le fichier de projet QGis. Voilà pourquoi nous l'avions nommée CADASTRE à cette occasion.
  • Les paramètres SRS,WIDTH,HEIGHT et BBOX sont laissés à JOSM qui se charge de les remplir avec ses variables proj,width,height et bbox.

Une fois la couche WMS configurée, vous pouvez l'activer dans JOSM et commencer à importer votre cadastre.

En termes de format, j'ai remarqué que les données les plus rapides sont celles qui sont issues d'une source en GéoTiff avec pyramides internes. A l'utilisation, sur une machine moyenne, l'affichage de la couche WMS est assez rapide et dans tous les cas, bien plus qu'en passant par le plugin cadastre-fr.

Il vous faudra modifier votre fichier de projet Qgis (.qgs) lorsque vous souhaiterez travailler sur une autre commune.

Conclusion

Avec le script exposé dans cet article, il est tout à fait possible de récupérer un fichier raster de cadastre et de l'afficher dans JOSM. Le temps de capture de la dalle raster peut sembler un peu long mais il faut le relativiser par rapport au travail d'import manuel du contenu du cadastre dans OpenStreetMap. En effet, il faut compter à peu près 1 heure de travail pour intégrer les routes, les rues et les lieux-dits d'une petite commune. Pendant ce temps, rien n'empêche de télécharger une autre commune en tâche de fond !

Posted dim. 13 oct. 2013 20:05:35 Tags:

OSM Propaganda

I use my old bike for OpenStreetMap work: it is a very useful way to map a lot of things without going too fast. This time, I've decided to make a little bit more advertisement for OSM project.

a bike with an OSM logo in the middle of the frame

This is the best way I've found to make people ask me: "What is OpenStreetMap.org ?"...

Posted sam. 03 mars 2012 20:47:39 Tags:

How to disjoint polygons sharing a common way in JOSM ?

Here is a small tip for JOSM to disjoint polygons that share a (or more than one) way(s). In JOSM you sometimes have to modify the borders of some polygons to improve vectorisation quality. Sometimes those areas share a way (jointed polygons). When you want to move a node or a group of node, you are actually changing the geometry of both areas. It is just a problem of joint nodes. In order to cut

Here is a case: two polygons with a shared way.

Two polygons sharing a way

If you move one shared node, the two polygons are affected.

Two polygons sharing a way

What needs to be done: duplicate the node. One node on the first polygon, one node on the other. Use the JOSM tool "Unglue ways" (Séparer les chemins in french): select the shared node and push G on your keyboard or use the tools in Select mode.

Two polygons sharing a way

There are now two nodes that you can move independently.

Two polygons sharing a way

Posted ven. 27 janv. 2012 09:57:20 Tags:

Un peu de prospective avec et sur OpenStreetMap

Introduction

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 suffisamment de données au niveau régional pour permettre une anayse comparative entre départements par exemple.

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

Etape 0: Pré-requis

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 diposez 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.

Etape 1: Récupérer les données

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.

Etape 2: Afficher les données avec QGIS

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.

OSM brut

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":

    Requête QGis

  • 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 "echantillon" 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 .

Etape 3: Un peu de recherche

Limites communales:

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:

Limites communales

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 en totalité couvert. 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).

Arrêts de bus

Couche ~ planet_osm_point

Clause WHERE ~ "highway" = 'bus_stop'

Tag OSM ~ http://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop

Bus stop

A 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.

Passage à niveau:

Couche ~ planet_osm_point

Clause WHERE ~ "railway" = 'crossing'

:Tag OSM:

Passages à niveau

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 !

Pistes cyclables

Couche ~ planet_osm_line

Clause WHERE ~ "bicycle" IN ('yes','private') OR "highway" = 'cycleway'

:Tag OSM:

Pistes cyclables Bon, il y a un peu plus de matière mais on est loin du compte. Par exemple, seule une partie de la "Loire à Vélo" est vectorisée. En revanche, on peut remarquer la présence du chemin de halage de la Mayenne.

Radars automatiques

Couche ~ planet_osm_point

Clause WHERE ~ "highway" = 'speed_camera'

:Tag OSM:

Radars automatiques

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

Etape 4: Soyons exhaustifs

Maintenant que nous avons vu quelques exemples, il est important de disposer d'un récaptitulatif 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;

Conclusion:

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.

Posted ven. 27 nov. 2009 10:22:00 Tags:

La montagne n'est pas infranchissable

Aujourd'hui, le 20/10/2009, je suis de retour dans la ville de mon enfance. C'est un bon jour pour commencer à "OSMiser" cette commune car jusqu'à présent, il n'y a pas d'informations disponibles sur OSM.

Ce travail à cet endroit est l'occasion de formaliser davantage la manière dont je réalise l'acquisition de données sous OSM. Après environ 5H de terrain depuis que je me suis mis à OSM et au moins autant de temps à saisir les données, je peux faire le point sur comment je me débrouille pour faire.

C'est le sujet de ce qui va suivre. Cette méthode est sans doute loin d'être parfaite mais, pour l'instant et avec les moyens dont je dispose, elle reste la plus efficace.

Enfin, cet article est également le moment d'évaluer la charge de travail pour "OSMiser" une commune entière et voir si c'est si titanesque que ça !

Un peu de méthode

Avant de commencer l'acquisition des données, j'ai utilisé le plugin cadastre pour vérifier si ce dernier était disponible et bien calé. Et comme la réponse a été positive, je peux me concentrer sur l'acquisition...

Pour moi, l'objectif est de récupérer le plus d'informations dans un minimum de temps (rester efficace car mon séjour sur place est limité).

En détails, voici ce que je prévois de faire:

  • Tracé de toutes les routes et chemins principaux.
  • Intégrer tous les noms de routes.
  • Inclure les écoles.
  • Les lieux de recyclage
  • Les supermarchés
  • Les bâtiments publics (mairie)
  • Les parkings publics
  • Les pistes cyclables.
  • Les chemins pratiquables en vélo.
  • Les arrêts de bus

En ce qui concerne le mode d'acquisition des données, je pense qu'il n'y a pas de meilleur moyen que d'utiliser la bicyclette. D'abord, c'est pratique: on se faufile partout, on évite plus facilement les bouchons dûs au traffic des voitures. Ensuite, vu les nombreux arrêts impératifs pour prendre des notes, je ne me vois pas devoir chercher une place pour me garer. Enfin, si OSM rime avec bilan carbone négatif, mieux vaut ne pas faire d'OSM !

Mon matériel d'acquisition est un Nokia N95 sur lequel j'ai installé Nokia Sports Tracker. Ce logiciel n'est pas libre mais il permet de faire des relevés GPS et de les exporter (au format GPX). C'est tout ce que je lui demande. Pour vérifier le processus d'acquisition, il est plus simple de voir en direct ce qui est tracé. Pour ça, j'utilise une sacoche avant qui me permet de placer le N95 de manière à voir l'écran. C'est particulièrement utile pour vérifier si la qualité du signal GPS est suffisante. Quand le signal est trop faible, cela se ressent sur l'acquisition et dans ce cas, il vaut mieux faire une pause sur place avant de récupérer un meilleur signal et poursuivre la route.

Ensuite, il me faut de quoi noter les noms des rues. Un simple carnet petit format qui peut se mettre dans la poche ou dans la sacoche de devant fait l'affaire. Attention, en cas de longue route, le fait de placer le carnet dans la poche amène de l'humidité due à la transpiration ou à la pluie et tout ce qui va avec (effacement des lettres).

En fait, ce carnet me permet de noter tous mes arrêts dans l'ordre et c'est ça la clef de la méthode. Sur Nokia Sports Tracker, je ne peux pas insérer de "way points". Il m'est donc impossible de marquer mes arrêts sur cette application. En revanche, comme le GPS continue à faire de l'acquisition, les arrêts sont repérables aux nombres de points sur un même lieu. Et c'est comme cela qu'on peut voir où on s'arrête. C'est assez fastidieux car il faut noter tous les arrêts et ne pas se tromper d'ordre au moment de la saisie des données mais c'est ce qui est de plus efficace pour écourter la phase de terrain.

Une fois équipé, il n'y a plu qu'à se lancer. Pour faciliter le travail de saisie, je prends le nom des rues après juste après m'y être engagé. Cela permet de ne pas se tromper.

Évaluation du temps passé

J'ai estimé le temps d'acquisition à environ 3 heures. Voyons quels sont les résultats...

Tout d'abord, la vectorisation des voies m'a occupé pendant 2H50 (mes prévisions étaient assez bonnes). J'ai effectué un voyage de 45km en tout ! De plus, le GPS a tenu tout ce temps d'acquisition. Un nokia N95 chargé à fond peut donc être utilisé en mode GPS constamment pendant 3H environ. Cette limite est très bien: au delà de 3H à vélo, sans entraînement, c'est un peu difficile.

La prise de notes pour le nom des rues et les emplacements de recyclage m'a occasionné 69 arrêts ! Je ne pensais pas en avoir autant à faire.

En comptant environ 15 secondes par arrêt, j'estime à 18 minutes le temps consacré à cette prise de notes, ce qui, relativement à la durée totale du travail est peu important. Toutefois, en ce qui concerne le rythme, ces arrêts sont difficiles à gérer: ça fait moins de 3 minutes de course entre les arrêts !

A ce niveau, l'audiomapping ne fait pas gagner du temps mais du confort. Et ce confort n'est pa à négliger: après tout, OSM, c'est du bénévolat, pas du sacrifice.

Sur le long de mon parcours, j'ai croisé 4 autres vélos dont 3 avec des mineurs dessus: le vélo n'a pas la côte là-bas. Rappelons que mon timing de vectorisation a eu lieu sur la tranche 15H00-18H00 qui inclus l'heure de pointe des transports de 17H30. D'ailleurs, cette commune n'a qu'une seule piste cyclable.

En ce qui concerne les travaux post-terrain, j'ai passé environ 3H à dessiner, nommer, vérifier avec le cadastre le tout sous JOSM. D'où mon adage pifométrique qui me conduit à affirmer qu'on passe autant de temps sur le terrain qu'au bureau lorsqu'on travaille pour JOSM.

Pour conclure sur ce temps de travail, on voit qu'il suffit de fournir un effort d'environ 8H (soit le temps de travail d'une journée moyenne en France) pour mettre les données d'une commune d'environ 4000 habitants avec un territoire d'une surface de (TODO: trouver la surface de Wizernes). Ce qui est finalement peu comparé à toute ce que la connaissance de ce territoire peut nous apporter.

Les résultats:

Résultat de ma numérisation dans OSM
Résultat de mon
passage dans OSM

En dynamique ici.

Il y a encore un peu de travail (les chemins dans les champs), quelques routes-limites à éclaircir (que se passe-t-il quand une route sert de limite communale ?), etc...

Posted mer. 21 oct. 2009 13:48:00 Tags:

OpenstreetMap, à vous de jouer...

Que faire avec un téléphone-GPS et un vélo ? Réponse: travailler pour la communauté et en l'occurence OpenstreetMaps.

OpenStreetMap: le wikipedia de l'information géographique:

C'est un peu comme ça qu'on peut qualifier OpenStreetMap (OSM). Attention, on dit OpenStreetMap et pas OpenStreetMaps !

Le principe d'OSM est de fournir une base de données géographiques libre. N'importe qui peut utiliser les données de cette base comme bon lui semble. Les données de cette database sont fournies par la communauté OSM qui fournit des outils facilitant la création, la mise à jour des données. N'importe qui peut ajouter,modifier ou supprimer l'information contenue dans cette base de données. Ainsi, si vous regardez dans le coin où vous habitez et que le nom de la rue est incorrect, vous pouvez corriger l'erreur. La consultation des données est libre et la modification demande à ce que vous vous enregistriez. Ca n'est pas aussi "open" que Wikipédia mais ça ne va pas non plus vous couter tant que ça (je parle au niveau anonymat).

Le projet OSM a été lancé en 2004 par une poignée de citoyens britanniques. Actuellement, on compte environ 165000 comptes ouverts et environ 120000 millions de points de données ( Cf `la page de stats`_) ! Les données sont disponibles sous la licence `Creative Commons Attribution-ShareAlike 2.0`_. qui, comme son nom l'indique, permet tous les usages à conditions de citer la source et de livrer les données dérivées sous la même licence. Actuellement, un groupe de travail interne à la communauté OSM essaye de vérifier s'il ne serait pas plus intéressant de passer les données sous `licence open database`_.

En plus des outils de création d'information, il existe pléthore d'autres outils qui utilisent et traitent les données d'OSM. On trouve des applications permettant de générer des cartes de villes en format PDF pour pouvoir les imprimer (du même type que celles qu'on trouve dans les plans-guide). On trouve également des applications qui permettent de calculer des chemins ou des itinéraires par exemple.

Un peu de polémique:

N'importe qui peut y insérer des données géographiques, corriger celles qui sont présentes, insérer de l'information alphanumérique, etc... Du coup, on a les même travers que dans Wikipedia: n'importe qui peut détourner la réalité. Effectivement, je peux très bien choisir de supprimer tout un quartier, de modifier un linéaire, etc...Toutefois, les personnes qui ont travaillé sur les données d'OSM ont sans doute passé beaucoup de temps sur à les mettre en ligne. Entre les séances d'acquisition au GPS, la correction des linéaires dans JOSM, la création des champs pour contenir les noms des rues et la qualification des voies, on a vite fait de consacrer une demi-journée complète à ce travail pour couvrir un quartier. Un tel niveau d'investissement implique que l'on n'est vraiment pas prêt de voir massacrer son travail par d'autres !

De plus l'aspect "polémique" du contenu de Wikipédia est vraiment très éloigné de celui d'OSM. J'imagine assez facilement que Jean Sarkozy n'a pas à remettre à jour `les données carto de l'EPAD dans OSM`_ pour pouvoir sauver la face. Alors que sur `la page Wikipedia de l'EPAD`_, c'est une autre histoire... Disons pour résumer que la carte est moins sujette à discussion que la prose. Même si parfois, une bonne carte véhicule un message fort. Mais c'est une autre histoire que je ne tiens pas à aborder maintenant.

On peut également se poser la question: "à quoi ça sert car il existe Google maps ou le Géoportail ?" Ces deux outils sont très bien pour consulter quelques informations, souvent celles qui intéressent le grand public à savoir, des orthophotographies ou des plans de routes. Toutefois, les données ne sont pas libres: on ne peut pas les télécharger pour réaliser des études avec. Ou bien il faut demander l'autorisation, ce qui est pénible parce que bien souvent, un traitement de données digne de ce nom, implique de multiples sources de données et donc autant de demandes !

Google Maps n'est pas libre: je vous laisse lire `les conditions d'utilisation`_. Pour résumer (attention, je ne suis pas juriste), le contenu de Google Maps est accessible en lecture seule uniquement via les outils Google (maps ou l'API) pour un utilisateur donné. Bon, vous me direz que pour l'instant, le contenu de Google Maps est plus fourni que celui d'OSM... Je vous répondrais seulement: "pour l'instant !". Si OSM devient un phénomène de masse, enfin, si un un pool de contributeurs d'une certaine taille prend la cartographie du monde en main, sachant que les données cartographiques ne sont pas nécéssairement sujette à des modifications intenses, il arrivera un jour où OSM dépassera GoogleMaps. Concrètement, dans mon quartier, il existe des rues qui ne sont pas représentées sur Google Maps et pourtant elles ont été construites il y a au moins 2 ans. En revanche, elles le sont dans OSM vue que je les ai incluses. Pour terminer, GoogleMaps ne gère pas bien la description des bâtiments, des zones, des arrêts de bus, etc... bref, de tout ce qui peut faire la plus-value d'OSM. Car grâce au modèle de données d'OSM, on peut quasiment tout cartographier, même ce qui n'est pas intrinsèquement prévu.

Par rapport au sujet du GéoPortail de nos amis de la DGME, il s'agit juste d'un espace de visualisation de couches produites par les différents services des entités publiques (services de l'Etat, Etablissements publics, collectivités). On ne peut donc que visualiser les couches et non les récupérer pour en faire ce que bon nous semble (les réutiliser, faire une analyse de terrain, l'uploader dans le GPS, etc...). L'accès à l'information est donc soumise à une demande auprès de chaque adhérent du géoportail. Je note également que pour faire un lien vers le site Géoportail-Services, il faut faire une demande d'autorisation ce qui va complètement à l'encontre de ce qui constitue l'essence même d'Internet. Bref, pas grand chose à ajouter... Ah si, sur le Géoportail, on peut consulter Corine Land Cover (une base de données d'occupation du sol à la précision de 25m) ! Depuis la mi-octobre, on peut faire `la même chose dans OSM`_. Ca n'a été possible que parce que ces données sont réutilisables (quasi-libres). Cela prouve bien la capacité étendue de gestion d'OSM ainsi que le potentiel de la communauté.

Quelques réalisations:

J'ai vectorisé le quartier où je réside. `C'est visible ici`_ et comme c'est dynamique, le contenu sera sans cesse en évolution. Dans la ville où j'habite (Angers, FR), le `centre-ville`_ est à peu près bien représenté. En revanche, près de chez moi... rien, le néant, juste de quoi délimiter le secteur entre les routes principales. C'est là que m'est venu l'idée de faire par moi même. Et c'est comme ça que tout à commencé.

Après avoir parcouru rapidement l'excellent Wiki de OSM qui est d'ailleurs partiellement traduit en français pour les plus anglophobes d'entre-nous, j'ai opté pour la méthode pure et dure d'acquisition GPS. J'ai la chance d'avoir un téléphone portable qui dispose d'un GPS incorporé: un nokia N95. Comme je n'ai plus d'abonnement de téléphone portable, celui-ci devenais complètement inutile mise à part sa possible utilisation en tant qu'appareil photo. Du coup, j'y ai installé une application qui permet de récupérer les enregistrements GPS. il s'agit de Nokia Sports Tracker qui n'est pas libre mais qui fonctionne out-of-the-box. Je sais, ce n'est pas bien et je suis en train de travailler à trouver quelquechose de libre et de plus efficace.

Une fois l'application installée et configurée, se pose le problème de la circulation. On peut cartographier à pied, en vélo, en voiture, en train, en bus, etc... Toutefois, je voulais apporter des éléments solides à OSM: un quartier complet. Cela implique d'aller dans toutes les rues, de faire le tour complet des rond-points. Faire ça en voiture, bonjour le bilan carbone d'OSM. En plus de ça, comme circuler sur le terrain a un côté fastidieux surtout dans les lotissements labyrinthiques, il est souhaitable de ne pas avoir à revenir plus d'une fois à un endroit. Du coup, l'étape de prise en charge du nom des voies n'est pas à négliger. Circuler c'est facile, s'arrêter pour noter le nom d'une rue, ça l'est moins. vous l'aurez compris, OSM implique une majorité de circulation en 2 roues. ET c'est comme ça que j'ai fait !

Le téléphone sur la sacoche avant du vélo et c'est parti... Avant d'avoir essayé, on ne peut pas se rendre compte à quel point on peut être efficace avec ce genre d'engin. En vélo, on passe partout, sur les chemins et pistes piétonnes, sur les routes, les pistes cyclables. On peut faire le tour des bâtiments, s'arrêter facilement pour noter le nom des rues, prendre des photos, noter le numéro des maisons, le tout autrement plus rapidement qu'à pied. Le meilleur compromis entre efficacité et bilan carbone pour le projet OSM est donc le vélo. Pour vous donner un ordre de grandeur la cartographie de mon quartier a nécéssité environ 4H de balade en vélo. Ca peut paraître long mais, dans des petites communes, ça signifie qu'on peut couvrir l'intégralité du territoire en une demi-journée de terrain ce qui est franchement pas beaucoup. Pour ma part, je m'attendais à mettre beaucoup plus de temps que ça. D'ailleurs, les balades en vélo sont des prétextes à vous faire découvrir les alentours, explorer des lieux inconnus, voir où les gens habitent, visualiser en direct les travaux parfois moyens, parfois excellents des urbanistes de tout poil, observer les particularités. On y prend beaucoup de plaisir; d'autant plus lorsqu'on sait que c'est pour la bonne cause !

Une fois rentré à la maison, un deuxième travail commence: celui de la correction des données et de l'envoi dans OSM. C'est un travail dont la durée varie selon votre niveau d'exigence. Si vous désirez tout cartographier en passant par les points recyclages, les écoles, les bâtiments publics, les parkings, les parcs, les arrêts de bus, les pistes, les chemins piétons, les espaces verts, les fontaines, les supermarchés, les forêts, les rivières, les numéros des voies il y a de quoi passer des nuits blanches. Si au contraire, vous désirez uniquement vous occuper des routes (on commence tous par ça, c'est le plus visible), il faut compter une heure de traitement pour une heure de terrain.

Pour effectuer ce travail, il existe des outils dont le fameux JOSM (Java OpenStreetMap). Il permet d'insérer des informations dans la base de données OSM de manière simple. C'est un outil assez intuitif mais assez précis et efficace. Sa bonne maîtrise permet de traiter rapidement vos données de terrain. On peut également utiliser certains plugins pour faciliter ce travail. Je ne parlerai que d'un seul d'entre eux qui mérite son pesant de cacahuètes.

Il s'agit du plugin cadastre-wms qui permet d'afficher une image du cadastre à l'endroit où vous êtes en train de travailler. Les membres de la communauté OSM ont obtenu de la DGFIP l'autorisation d'utiliser le cadastre disponible sur cadastre.gouv.fr pour faciliter le travail de cartographie dans OSM (cf `la page du wiki OSM sur ce plugin`_). Dans la pratique, le plugin lance une requête WMS sur un serveur du cadaste et on récupère une image (bitmap). Concrètement, cela permet de vérifier que vos données sont bien projetées tivité tend vers la réalisation d'une cartographie complète du monde. Mais demain, une fois ces données consolidées, nous ne sommes pas encore en mesure de connaître les différentes utilisations possibles d'OSM. A nous d'inventer la suite !

Pour terminer, ces données libres servent les citoyens et permettent d'établir un véritable contre pouvoir. Aujourd'hui, seules certaines sociétés privées ou publiques disposent de ces informations, elles ne sont pas publiquement accessibles (ou pas suffisamment) et nous ne pouvons pas les utiliser pour vérifier, par exemple, les dires de nos politiques ou le bien fondé de telle ou telle opération d'aménagement du territoire. Gageons qu'OSM puisse rendre tout ça possible !

Tout cela ne dépend que de vous tous... Alors, à vos vélos, à vos GPS, et à vos cartes, pour le meilleur...

La prochaine fois, nous rentrerons dans le concret de l'utilisation des données OSM pour réaliser une petite étude de terrain. Avant que cet article soit disponible, il va me falloir terminer de numériser une commune entière avec un bon niveau de détails.

Posted sam. 17 oct. 2009 14:00:00 Tags: