Il y a/avait une petite astuce, que Sylvain Letuffe (alias "sly" sur osm-talk-fr) m'a fait découvrir. Merci à lui. C'est essentiellement pour celà que je poste ce billet : l'astuce vaut d'être plus largement connue.
Ce tutoriel suppose quelques connaissances de la ligne de commande sous linux debian. Rien de bien méchant anyway.
Nous voici partis.
On commence par récupérer les données OSM sur la France. On ne va pas passer par l'API, pour deux raisons :
- la première est que ce ne sera pas permis en raison de la taille trop importante de la bounding box,
- la deuxième (qui est en fait la cause originale) est que ça chargerait trop les serveurs OSM,
- j'en dévoile une troisième au vol (qui est plutôt une conséquence de 2 puis de 1) : CloudMade offre déjà des extraits par pays, qui se téléchargent très bien (merci aws ;-)
$ cd /tmp
$ wget http://downloads.cloudmade.com/europe/france/france.osm.bz2
On va ensuite importer ces données (au format XML) dans une base de donnée géographique.
OSM fournit un outil très pratique pour ce faire : OSM2PgSQL
Il y a quelques dépendances, que vous pourrez installer facilement via :
$ sudo apt-get install build-essential libxml2-dev libgeos-dev libpq-dev libbz2-dev proj
Voici ensuite une manière d'installer osm2pgsql :
$ svn co http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/
$ cd osm2pgsql
Et là, on arrive au point ou il est nécessaire de mettre en oeuvre l'astuce sus-citée.
Par défaut, et à ce jour, OSM2PgSQL ne considère pas les objets de type boundary comme des géométries polygonales. Pour y remédier, éditer le fichier output-pgsql.c : il vous faudra remplacer make_polygon=0 par make_polygon=1 en ligne 818, de la rev. 14211
Edit: OSM2PgSQL a été patché depuis, et cette modification n'est plus nécessaire.
Puis, l'installation classique reprend son cours :
$ make
$ sudo make install
Nous arrivons au point au nous avons besoin du SGBD PostgreSQL ainsi que sa cartouche spatiale PostGIS...
$ sudo apt-get install postgresql-8.3 postgresql-8.3-postgis
Puis nous créons une base de donnée pour accueillir les tables résultant de l'export des données OSM :
$ sudo su postgres
$ createdb -E UTF8 osm
$ createlang plpgsql osm
$ psql -d osm -f /usr/share/postgresql-8.3-postgis/lwpostgis.sql
$ psql -d osm -f /usr/share/postgresql-8.3-postgis/spatial_ref_sys.sql
Ceci fait, nous lançons l'importation, avec :
$ osm2pgsql -d osm -H localhost -P 5432 /tmp/france.osm.bz2
Vous pouvez aller vous prendre un café ;-)
Enfin, vous voici prêt à lancer l'export en shape:
$ pgsql2shp -f /tmp/arrondissements.shp -g way -k osm "select * from planet_osm_polygon where admin_level=10"
$ pgsql2shp -f /tmp/communes.shp -g way -k osm "select * from planet_osm_polygon where admin_level=8"
$ pgsql2shp -f /tmp/departements.shp -g way -k osm "select * from planet_osm_polygon where admin_level=6"
$ pgsql2shp -f /tmp/regions.shp -g way -k osm "select * from planet_osm_polygon where admin_level=4"
HTH comme on dit.
Et voici le résultat :
Il nous reste du travail ;-)
En chiffres, voici l'état actuel de la métropole :
- 13% des communes
- 81 départements (sur 96)
- 14 régions (sur 22)
5 commentaires:
Vous pouvez suivre la progression des limites OSM sur ce site fait par Sylvain (sly)(les nouvelles limites sont ajoutées quasiment en temps réel):
http://beta.letuffe.org/?zoom=6&lat=46.43798&lon=1.84698&layers=B000000000FFTFFFF
NB: rendons à César .., le truc avec osm2pgsql est de Thomas Wood (grand.edgemaster at gmail.com). Mais ça n'enlève rien par ailleurs au formidabel travail fournit par Sylvain .
Merci pour la précision concernant osm2pgsql.
On peut imaginer que ce "bug" (à moins que ce ne soit une "feature" ;-) soit corrigé sous peu ...
Quant au site de Sylvain, oui, je connais bien (nous sommes quasiment voisins ;-).
Suite à une remarque sur la mailing liste [géomatique] du georezo, j'ai pu constater que les données insérées en base en suivant ce tutoriel présentaient un décalage sur les ordonnées d'une trentaine de km.
Alors je me suis amusé à faire varier les paramètres de projection en sortie de osm2pgsql.
osm2pgsql --help nous apprend ceci:
-l|--latlong: Store data in degrees of latitude & longitude.
-m|--merc: Store data in proper spherical mercator (default)
-M|--oldmerc: Store data in the legacy OSM mercator format
-E|--proj num: Use projection EPSG:num
Par défaut, osm2pgsql dit utiliser la véritable ("proper") projection mercator sphérique. Or, celle-ci ne semble pas conforme à la définition de epsg:3785 (alias l'inofficielle, mais plus répandue epsg:900913) ... cf le décalage observé.
En revanche, l'utilisation des switchs -l pour epsg:4326 ou -M pour epsg:900913 donne des résultats correctement superposables avec d'autres couches SIG.
Il y a donc là un mystère à éclaircir autour de ces "proper spherical mercator" et "legacy OSM mercator".
More very soon ...
Et en attendant, j'ai posté des shapefiles mis à jour à l'adresse http://dl.free.fr/pQWHdEcQG (epsg:4326)
A noter que depuis avril 2009, le patch de gestion des boundary a été intégré à osm2pgsql, la partie "patch" n'est plus nécessaire, la version sans modifications de osm2pgsql marche très bien
--
sly
Merci pour tes explications. Deux petites mises à jour:
psql -d osm -f /usr/share/postgresql-8.3-postgis/lwpostgis.sql a été renommé en postgis.sql depuis la version 8.4 de postgre. Il se trouve dans: /usr/share/postgresql/8.4/contrib/postgis-1.5/, pareil pour spatial_ref_sys.sql (ubuntu 10.10)
Salutations, Romain
Enregistrer un commentaire