samedi 31 décembre 2016

Comment accéder en masse aux informations vectorielles d'Open Street Map ?

Open Street Map (OSM) est une carte ouverte à couverture mondiale. Chacun peut puiser dans ses rendus cartographiques, ses outils pour développeurs (API) et/ou la base de données sous-jacente. C’est une source de données localisées de mieux en mieux alimentée, précise et « gratuite ». En France en particulier, soutenu par l’association OSM France et un secteur public très actif sur le développement de cette carte, le contenu est très régulièrement enrichi notamment par les données cadastrales de la DG FIP.
La structure de la base de données sous-jacente est cependant un peu complexe et nécessite un investissement chronophage pour réussir ses extractions. Il faut quelques connaissances en géomatique pour plonger dans le bain de données OSM. Le format du fichier .osm, xml tout en un, est déroutant pour les utilisateurs de SIG et les statisticiens. Le fichier .osm est un format texte balisé (xml) facile à manipuler par les développeurs. Mais il l’est beaucoup moins par les analystes. Les informations ne sont pas tabulées en colonne et les objets géographiques sont, le plus souvent, mal lus par les SIG classiques. QGIS réussit à lire nativement les fichers .osm. Mais il est impossible d’espérer lire et requêter sur un fichier France.osm directement : les structure et volumétrie de données (80 GO pour la France) ne passent pas…   

Ce post détaille une méthode d’extraction des données vectorielles d’OSM et de conversion sous formes de tables couches vectorielles « classiques » facilement interprétables avec un système d’information géographique. On se concentre ici sur les extractions à forte volumétrie.
Il existe de nombreux moyens d’accès aux informations d’OSM.  Les plus faciles et populaires sont :
Mais après quelques manipulations de ces outils, nous touchons leurs limites.
Les capacités de l’Api overpass sont vite dépassées lorsque l’on souhaite extraire sur un large territoire. Les transactions qui passent par le web limitent la volumétrie d’extraction. Il est par ailleurs très fastidieux de monter des extractions multi-thématiques et/ou sur plusieurs tag osm avec cette API.
Les shapes de Géofabrik ou Mapzen sont très utiles mais trop généralistes, parfois incomplets (manque d’objets ou d’attributs) et on ne contrôle pas leur contenu. Par ailleurs, les limites de volumétrie des shapes entraînent un découpage régional pour la France et il faut construire des requêtes complémentaires pour obtenir une couche propre pour tout le pays.  


Bref, nous souhaitons passer au stade supérieur ; être autonome dans l’accès à la source, pouvoir gérer de grosses volumétries et mieux comprendre ce que l’on extrait.


1/ Pré-requis :

Je mentionnais plus haut que l’accès à OSM est entre guillemet « gratuit ». La carte est libre mais l’accès à la base de données n’est pas vraiment « grand public ». Il y a quelques pré-requis techniques, le plus souvent documentés en anglais. Il est souhaitable d’avoir une expérience de la géomatique et des SIG pour s’attaquer à ces extractions. On travaille sous windows sans interface logiciel, le langage de commandes MSDOS[1] ne doit pas vous rebuter et la liste des pré-requis est donc un peu longue :

1.1 Il faut d’abord lire et comprendre l’organisation des objets cartographiques de la base de données OSM : le wiki de référence en anglais sur les OSM Map features détaille la nomenclature par catégories (Amenity, Shop, Building, Boundary…)  et sous-catégories des objets de la carte ainsi que les propriétés complémentaires qui peuvent être associées à ces objets (Name, addresses, annotation…)

1.2 Installer le logiciel OSMosis en suivant la procédure décrite dans ce wiki : http://wiki.openstreetmap.org/wiki/Osmosis/Quick_Install_(Windows).
Osmosis utilise java, il faut avoir installé ce logiciel et vérifié que son chemin d’accès est bien reconnu par Osmosis.  
Pour cela, avec votre explorateur Windows, chercher « java.exe » et modifier le fichier de lancement
C:\Program Files (x86)\osmosis\bin\osmosis.bat en conséquence
Sur mon PC, la définition de variable d’accès à java s’écrit :
set JAVACMD=C:\Program Files (x86)\Java\jre1.8.0_111\bin\java
Attention il y a une petite erreur dans le wiki car il ne faut pas de guillemets “ “  pour la définition de la variable javacmd.
N’oubliez pas aussi d’ajouter dans votre variable d’environnement[2] PATH, le chemin d’accès à Osmosis, sur mon PC : "C:\Program Files (x86)\osmosis\bin"

Pour vérifier le bon fonctionnement d’Osmosis , la commande : "C:\Program Files (x86)\osmosis\bin\osmosis.bat" doit renvoyer :




1.3 Installer GDAL pour l’accès à ogr2ogr :
GDAL (Geospatial Data Abstraction Library) est le "couteau Suisse" du géomaticien. Ce  logiciel est open source et se substitue très bien aux équivalents payants (FME, ArcGISS....) pour ceux qui manipulent l’invite de commande DOS. L’installation est expliquée sur le site OSGeo4W. On peut aussi se référer à ce mode d'emploi ; attention à bien installer des versions de GDAL et de python cohérentes.

1.4 Télécharger les données brutes d’OSM en format hyper compressé .pbf sur le site de téléchargement de géofabrik. Il faut une bonne fibre Internet et un peu d’espace sur vos disques pour télécharger ces sources (Europe =18.2GB, FR 3.3GB, Germany 2.9 GB, Italie 1.2GB, GB 0.9…). Ces fichiers organisés par continent et pays comprennent l’exhaustivité de la base OSM. Elles sont actualisées tous les jours par Géofabrik.

1.5 Lire aussi l’excellent article en français sur l’extraction de données .osm à l’aide du seul logiciel org2ogr : vraiment utile et très clair. Je suis parti de cette méthode que j’ai adaptée pour l’extraction de gros volumes en ajoutant une étape osmosis en amont de l’étape ogr2ogr.

1.6 Lors de la mise au point et de la validation de mes extractions, je vais toujours sur la carte en ligne OSM dans des zones que je connais bien. Avec l’outil ? j’interroge la carte à un endroit donné et j’ai ainsi accès  à tous les objets avoisinants et tous leurs attributs. En cliquant sur un objet, on voit tous les tags associés. C’est un très bon moyen pour comprendre la structure de cette base.

La description d'un objet polygone OSM
ZAC de Kerfontaine (Pluneret 56) : tags base OSM



2/ Conversion des données osm en couches vectorielles :

Le format texte en clair (xml) .osm est très consommateur d’espace disque. 
La méthode que je préconise part des fichiers ultra compressés .pbf France.pbf =3.3 GB versus 80 GB pour la version décompressée .osm). Osmosis lit directement le fichier compressé et permet de faire des filtres pour sortir un fichier .osm manipulable qui pourra facilement être lu par les SIG ou mieux converti en format géo-tabulaire pour SIG (Shp ou MapInfo files par exemple).
Les objets géographiques OSM sont de types point, ligne polygone ou relation. On oublie les relations, car nous n’en avons a priori pas d’usage avec un SIG.

2.1/ Extraire des points : création d’un fichier France de tous les points d’intérêt de catégorie Shops (magasins) et Amenities (infrastructures)

Avec la commande CD, placez-vous d’abord dans le répertoire  de vos sources .pbf.  L’extraction est réalisée en deux étapes.

2.1.1 Création d’un fichier .osm

osmosis --read-pbf France.pbf --tf accept-nodes shop=* amenity=* --tf reject-relations --used-way --write-xml  FR-ShopsAmenities.osm
Temps de traitement sur mon PC portable 30 mn

Explication des options
--read-pbf option osmosis de lecture d’un fichier osm en format hyper compressé pbf
--tf accept-nodes shop=* amenity=* : tf est l’abréviation de tag Filter, filter tous les nœuds (ie points) des catégorie shop et amenity. Le jocker * signifie que l’on prend toutes les sous-catégories des deux catégories.  
--tf reject-relations: on exclut les relations, à préciser dans toutes nos extractions osmosis sinon on se retrouve avec tous les objets spécifiés par ces relations.
--used-way : Ne sélectionner que les points de polygones identifiés idem à préciser dans toutes les extractions points sinon on extrait des points en pagaille qui ne correspondent pas à notre filtre.
--write-xml  FR-ShopsAmenities.osm : on écrit la sortie dans le répertoire courant un fichier xml .osm
La liste des données (variables tags) extraite par osmosis est définie dans un fichier osmconf.ini. Faites une recherche de ce fichier sur votre PC (chez moi sur C:\Program Files (x86)\GDAL\gdal-data)  éditez-le par exemple avec Notepad+[3]. Pour chaque type d’objet, le fichier liste les attributs extraits par défaut par osmosis. Ajoutez et supprimez des attributs à votre guise en fonction de vos souhaits d’extractions.

Voici ma configuration d’extraction d’attributs pour des objets du type point :


2.1.2 Transformation en fichier SIG

ogr2ogr -f "ESRI Shapefile" FR_shopAmenities_Points.shp -skipfailures -overwrite -gt 65536 -dialect SQLITE  -sql "SELECT  GEOMETRY,osm_id,name, coalesce(shop, amenity) as type, address,brand, operator,other_tags from points" FR-ShopsAmenities.osm -lco ENCODING=UTF-8 FR-ShopsAmenities.osm

-f "ESRI Shapefile" FR_shopAmenities_Points.shp : création d’un fichier shape. Je privilégie le format Shp car ogr2ogr ne gère bien l’encodage des caractères UTF8 via l’option -lco ENCODING=UTF-8 FR-ShopsAmenities.osm
-overwrite : écrasement du précédent fichier de même nom s’il existe
-gt 65536 : option à utiliser pour meilleure gestion de la puissance machine, ne semble pas indispensable cependant
-dialect SQLITE : précise que l’on va utiliser du sql avancé dans la requête qui suit
-sql "SELECT  GEOMETRY,osm_id,name, coalesce(shop, amenity) as type, address,brand, operator,other_tags from points" FR-ShopsAmenities.osm : on passe une requête sql sur la base .osm préalablement constituée via osmosis. La requête figure entre guillemets et précise  la liste des champs à extraire. Ces champs doivent avoir été préextraits en amont via osmosis et doivent donc être listés dans le fichier de configuration osmconf.ini. Notez que tous les tags non spécifiés dans le fichier de configuration sont accessibles en désordre dans un champs other_tags. coalesce(shop, amenity) as type utilise une fonction sql avancée coalesce et indique que l’on inscrit dans le champ type la valeur de la sous-catégorie shop si celle-ci est renseignée et la valeur de la sous-catégorie amenity sinon.
On peut alors charger et manipuler le résultat avec son SIG préféré.
  

2.2 Extraction d’un fichier des contours des zones industrielles et commerciales :
La démarche est très similaire à celle des points sauf que l’on filtre ici des polygones

2.2.1 Création des polygons .osm
osmosis --read-pbf france.pbf --tf accept-ways landuse=retail,commercial,industrial,port shop=department_store,mall,supermarket building=retail,industrial,commercial,warehouse --tf reject-relations --used-node  --write-xml  FR-LanduseWays3.osm

On filtre ici les polygones des sous-categories retail,commercial,industrial,port du tag landuse + les trois sous-catégories department_store,mall,supermarket de la categorie shop + quelques tags de la catégorie building
--used-node  bizarrement il faut préciser que l’on ne sélectionne que les nœuds des polygones de la sélection.  

2.2.2 Définition d’un shape des polygons
ogr2ogr -skipfailures -overwrite -gt 65536 FR_Retail_Poly.shp -sql "SELECT osm_way_id, name, landuse,building,shop,brand,operator from multipolygons" FR-LanduseWays3.osm -lco ENCODING=UTF-8 FR-LanduseWays3.osm

A titre indicatif, voici la trace msdos de ce traitement avec le temps d’extraction :

Et les fichiers résultats :


2.3 Extraire tout le bâti français :


Attention c’est « du lourd », pour la France métropolitaine, le tag « building » (bâti) couvre près des 2/3 de la base soit 55GO sur les 80GO du fichier .osm de référence. Avec cette extraction je souhaite donc « stress tester » la méthode.
osmosis --read-pbf France.pbf --tf accept-ways building=* --tf reject-relations --used-node  --write-xml FR-building.osm  
Log MSDOS (un peu plus de 3h de traitement)

Taille du fichier de sortie :

Puis :
ogr2ogr -f "SQlite" FR_Building_Poly.SQLite -skipfailures -overwrite -gt 65536 -dialect SQLITE  -sql "SELECT GEOMETRY,osm_way_id,name,building from multipolygons " FR-building.osm

Note : cette requête crée un shape énorme (8GO) difficilement exploitable. Il est préférable de se concentrer sur la création de couches de bâti thématiques, ici le bâti qualifié :
ogr2ogr -f "ESRI Shapefile" FR_BuildingQualif_Poly.shp -skipfailures -overwrite -gt 65536 -dialect SQLITE  -sql "SELECT GEOMETRY,osm_way_id,name,buiding,address from multipolygons  where building is not null" FR-building.osm -lco ENCODING=UTF-8 FR-building.osm


2.4 Tous les Parkings (points et polygones)

On extrait séparément la couche de points et la couche de polygones

osmosis --read-pbf France.pbf --tf accept-nodes amenity=parking,motorcycle_parking,parking_entrance,bicycle_parking,bicycle_rental,car_sharing,garages,parking_space tourism=caravan_site  site=parking building=garages,garages landuse=garages --tf reject-relations  --used-way --write-xml  FR_Parking_nodes.osm

osmosis --read-pbf France.pbf --tf accept-ways amenity=parking,motorcycle_parking,parking_entrance,bicycle_parking,bicycle_rental,car_sharing,garages,parking_space tourism=caravan_site  site=parking building=garages,garages landuse=garages --tf reject-relations --used-node  --write-xml  FR_Parking_ways.osm

ogr2ogr -f "ESRI Shapefile" FR_Parking_nodes.shp -skipfailures -overwrite -gt 65536 -dialect SQLITE  -sql "SELECT  GEOMETRY,osm_id,name, coalesce(amenity, tourism, site, building) as type, address,brand, operator,other_tags from points" FR_Parking_nodes.osm -lco ENCODING=UTF-8 FR- FR_Parking_nodes.osm

ogr2ogr -f "ESRI Shapefile" FR_Parking_ways.shp -skipfailures -overwrite -gt 65536 -dialect SQLITE  -sql "SELECT  GEOMETRY,osm_way_id,name, coalesce(amenity, tourism, site, building) as type, address,brand, operator,other_tags from multipolygons" FR_Parking_ways.osm -lco ENCODING=UTF-8 FR- FR_Parking_ways.osm


2.5 Toutes les piscines et terrains de sport :

Attention, les commandes OSMosis et Ogr2Ogr sont parfois un peu capricieuses. Je note une bizarrerie sur certaines requêtes ogr2ogr avec requête option -sql utilisant des fonctions avancées accessibles via l’option -dialect SQLITE. Ceci ne fonctionne pas pour toutes les extractions osmosis (l’ordre SQL  ne reconnait plus la table multipolygons). Dans ce cas il faut simplifier la requête sql en supprimant l’option -dialect SQLIT. Supprimez aussi la mention de l’extraction de l’objet qui est implicite en dehors de SQLite et les appels de la fonction coalesce.

osmosis --read-pbf France.pbf --tf accept-nodes leisure=swimming_area,swimming_pool,water_park,pitch,beach_resort natural=beach  sport=swimming,tennis --tf reject-relations  --used-way --write-xml  FR_Leisure_nodes.osm

osmosis --read-pbf France.pbf --tf accept-ways leisure=swimming_area,swimming_pool,water_park,pitch,beach_resort natural=beach  sport=swimming,tennis --tf reject-relations --write-xml  FR_Leisure_ways.osm

ogr2ogr -f "ESRI Shapefile" FR_leisure_nodes.shp -skipfailures -overwrite -gt 65536 -dialect SQLITE  -sql "SELECT GEOMETRY,osm_id,name,coalesce(leisure,natural,sport) as type,address,access,brand,operator,other_tags from points" FR_leisure_nodes.osm -lco ENCODING=UTF-8 FR_leisure_nodes.osm

ogr2ogr -f "ESRI Shapefile" FR_leisure_ways.shp -overwrite -sql "SELECT osm_way_id,name,leisure,natural,sport,address,access,brand,operator,other_tags FROM multipolygons" FR_Leisure_ways.osm -lco ENCODING=UTF-8 FR_Leisure_ways.osm

En filtrant les sorties sur access= « private », on obtient un fichier de localisation des piscines et cours de tennis privés. La source de ce type de bâti est la DGI n’est cependant pas totalement exhaustive sur ces signes extérieurs de richesse : cf le premier post historique de ce blog piscines à la carte.


Les extractions sur le linéaire routier fonctionnent sur le même principe. L’usage des linaires routiers dans les graphes de calculs de distanciers/itinéraires méritent néanmoins un développement spécifique que j’espère pouvoir poster dans un prochain épisode.  
Si vous êtes arrivé jusqu’ici, je vous tire mon chapeau en guise de conclusion. Vous êtes désormais mûrs pour puiser ce que vous cherchez dans OSM et nous faire vos retours de trucs et astuces d’usage.




[1] Accessible par l’invite de commande de windows
[2] Accessible sur Panneau de configuration\Tous les Panneaux de configuration\Système puis propriétés système+variables d’environnement + variable système + modifier la variable PATH et y ajouter le chemin d’accès à votre Osmosis.bat
[3] Si vous avez plusieurs installations Gdal (intégrées avec Qgis par exemple), il y a plusieurs fichiers osmconf.ini il n’est pas évident de savoir quelle version vous utilisez (voir votre variable d’environnement PATH). Dans ce cas, vous pouvez modifier l’un de vos fichiers osmconf.ini et recopier le en annule et remplace de tous les autres. 



10 commentaires:

  1. Jean-Martial NDOUTOUME NFENGONE11 janvier 2017 à 14:40

    Bonjour,

    Très intéressant, merci!

    Disons OK pour l'extraction (pour ma part, en théorie seulement, car je me suis contenté de parcourir votre article rapidement).

    Maintenant, imaginons le cas d'usage suivant:
    1. J'extrais les objets localisés qui m'intéressent (avec votre méthode).
    2. J'importe cette extraction dans mon ERP (genre Odoo + un module geospatial ).
    3. Je fais mes mises à jour de mon côté (mon métier c'est d'arpenter les rues et de corriger certaines informations, comme le nom des enseignes par exemple).
    3 bis. La communauté OSM fait ses mises à jour de son côté.

    Question: Comment pourrait-on faire pour:
    4. Verser mes mises à jour dans OSM de façon cohérente et (c'est le but) collaborative?

    (Sans doute ne suis-je pas très clair et je m'en excuse par avance car je défriche mon sujet.)
    À vous lire.

    Jean-Martial

    RépondreSupprimer
    Réponses
    1. Bonjour, vous êtes très clair et parfaitement dans le cœur d'activité d'Open Street Map.Le positionnement des enseignes a été objet de bonnes améliorations dans les grandes agglomérations. Il s'agit cependant d'un travail continue d'entretien car la rotation des enseignes est forte et leur qualification améliorable.

      La contribution "à la main" directement sur OSM est facile sur la carte de base OSM http://www.openstreetmap.org/ après création d'un compte.
      Je ne connais en revanche pas la procédure pour contribuer en batch. J'imagine que vous devez produire un fichier .osm à partir de votre erp et le soumettre pour intégration via un processus de contrôle. Contactez l'association Open Street Map France, ils sont réactifs.

      Bien à vous

      Supprimer
  2. Bonjour,
    Merci pour cet article très intéressant. Il me semble que ogr2ogr sait lire du pbf en entrée et est taillé pour lire des gros volumes de données. Osmosis vous a permis d'extraire à partir du pbf, des OSM par thématique. Pourquoi avez-vous choisi d'utiliser cette étape ? Est ce qu'elle permet de gagner en rapidité ? Est-ce par ce que c'est à cause de problèmes avec ogr2ogr ?

    cordialement
    x.lhomme

    RépondreSupprimer
  3. Bonjour,
    Le passage par Osmosis permet effectivement de préfiltrer un gros fichier compressé .PBF et d'en sortir un .OSM que l'on peut interroger facilement avec OGR2OGR. J'ai essayé de faire l’équivalent directement avec OGR2OGR sur unn fichier .PBF mais sans succès. A ma connaissance, OGR2OGR ne permet pas de filtrer sur les couches de type points, lignes, multipolygones sur un .PBF. Il faut un .OSM, d'où le passage par OSMosis. Si vous trouvez une solution plus directe, n'hésitez pas à la partager.

    Bien à vous

    RépondreSupprimer
  4. Bonjour,

    La commande suivante marche (sans passer par osmosis)
    ogr2ogr -f "ESRI Shapefile" roads.shp -skipfailures -overwrite -gt 65536 -lco ENCODING=UTF-8 -dialect SQLITE -sql "SELECT GEOMETRY, osm_id, name, highway as type,waterway,aerialway,barrier,man_made from lines where highway is not null" france-latest.osm.pbf

    cordialement
    x. lhomme

    RépondreSupprimer
    Réponses
    1. Bonjour, Oui Merci cela marche pour des lignes. En revanche je n'arrive pas à faire l’équivalent pour extraire des objets de type multipolygons.

      La requête :
      ogr2ogr -f "ESRI Shapefile" Corse_LandUse.shp -skipfailures -overwrite -gt 65536 -lco ENCODING=UTF-8 -dialect SQLITE -sql "SELECT GEOMETRY,osm_way_id,name,landuse,building,shop,brand,operator from multipolygons" Corse.pbf
      plante : "no such table : multipolygons", il semble que l’interpréteur sqlite ait un souci pour ce type d'objets.

      Vous avez une idée ?
      Bien à vous

      Supprimer
  5. bonjour,

    voici un exemple pour les buildings :


    ogr2ogr -f "FileGDB" france.gdb -nln buildings --config OSM_CONFIG_FILE myosmconf.ini -skipfailures -overwrite -gt 65536 -dialect SQLITE -sql "SELECT GEOMETRY, osm_id, name, type, building as fclass from multipolygons where building is not null" france-latest.osm.pbf


    j'utilise un export en FGBD car le shapefile est limité par sa taille.
    Pour installé GDAL+driver FGDB , je suis passer par http://www.gisinternals.com/release.html.

    note que j'utilise mon propre myosmconf.ini.
    j'y ai complété les lignes suivantes en ajoutant les thémaitques ou attributs que je souhaitais extraire :
    closed_ways_are_polygons=aeroway,amenity,boundary,building,craft,geological,historic,landuse,leisure,military,natural,office,place,shop,sport,tourism,waterway,bay


    attributes=name,type,aeroway,amenity,admin_level,barrier,boundary,building,craft,geological,historic,land_area,landuse,leisure,man_made,military,natural,office,place,shop,sport,tourism,waterway,bay

    xl


    RépondreSupprimer
    Réponses
    1. Bonjour, je suis un peu manchot... je ne sais pas comment installer le driver "FileGDB" pour GDal. J'ai été sur http://www.gisinternals.com/query.html?content=filelist&file=release-1800-x64-gdal-2-1-3-mapserver-7-0-4.zip et j'ai installé gdal-201-1800-x64-filegdb.msi pour mon GDAL (V2.1.1). Mais GDAL ne trouve toujours pas le driver FGBD.
      J'ai aussi été sur le site de download d'esri ou j'ai téléchargé l'APIV4 FGBD mais je ne sais pas qu'en faire... Bref, pas simple, merci pour vos lumières si vous en avez ?
      PA

      Supprimer
  6. La librairie ogr_FileGDB.dll est à installer dans le répertoire plugin C:\Program Files\GDAL\gdalplugins (dépend de ton installation). Mon objectif étant de faire un cache arcgis, j'ai ArcGIS Desktop sur mon poste, donc je peux me permettre de faire un export Fgdb. Si ce n'est pas ton cas et que tu souhaites rester Opensource utilise plutôt un export vers PostGIS au niveau de la ligne de commande GDAL.

    RépondreSupprimer
  7. Merci+ Effectivement avec une installation dans le bon répertoire (en win32 pour moi) c'est mieux, OGR2OGR retrouve le driver et est capable de créé un GDB. Ma commande OGR2OGR -f "FileGDB" ... plante cependant GDAL en cours d'execution et le fichier de sortie n'est pas complet. N'etant pas très à l'aise avec les formats d'ESRI, je vais me contenter des drivers SQLite ou PostGIS. Merci à toi

    RépondreSupprimer