Bonsoir, Quelques reponses sur la demarche que je compte suivre.
Denis wrote: > J'ai eu un peu de mal à digérer l'ensemble du trafic sur le topic. "Bzz, > bzz font les abeilles autour du pot de miel". > En conséquence, je vais peut-être enfoncer des portes déjà ouvertes > entre-temps. > 1. Je suis parti directement du fichier "France" en shapefile disponible > directement sur le site ftp de l'Ifen > (ftp://195.6.33.4/clc/national/SHP/CLC06_FR_L2E_SHP.ZIP). Aucun souci > d'inversion des lat/lon !!! Toujours aller au + simple > Importer dans postgis avec la version WGS84 et appliquer la transformation que Sylvain a donne a pris environ 10mn. > 2. ogr2ogr -s-srs EPSG:27572 -t_srs EPSG:4326 CLC06_4326.shp > CLC06_FR_L2E.SHP pour passer en WGS84 > ogr2ogr dispo sous Windows (FWTools de F. Warderdam) et sous *Nuix (gdal) > Etape inutile du fait de l'import direct en WGS84. > 3. Il est préférable de faire les extractions à partir du shapefile > obtenu (distinction par région, thème) plutôt que d'utiliser osmosis > pour faire des extractions (toutefois pas de benchmark ;-) > Je suis en train de creer une table pour chaque categorie. La premiere sur laquelle je travaille est foret puisque c'est de loin le plus simple, et le layer qui interesse le plus de monde. Dans le cas present, l'extraction se fera a partir de postgis via une commande ST_Intersect en ayant la forme du departement, ce qui est tres rapide. La structure de la table incluera un element is_in afin de permettre une selection plus facile a partir de la base de donnee. Une fois que j'aurais ce que je veux, il suffit d'utiliser pgsql2shp pour generer le shapefile voulu. > 4. pour convertir un (bout de) shapefile, j'ai testé avec beaucoup de > bonheur polyshp2osm > (http://svn.openstreetmap.org/applications/utils/import/shp2osm/polyshp2osm.py) > > qui présente l'avantage de convertir les polygones à trous en relations > multipolygon et hautement configurable (tags permanents, correspondance > entre attributs du shape et tags). C'est du python (pour Émilie ;-) > Vi, j'ai vu le lien. Je comptais d'ailleurs utiliser l'outil. Et merci pour m'indiquer que c'est du python, je ne suis pas sure que j'aurais realise. > Bref tous les outils et données sont là, pertinents et efficaces. Le > gros du problème et du travail est ailleurs. > en vrac : > - Regrouper les 44 classes de CLC ? si oui, comment ? > - correspondance entre classe CLC et tag OSM (relation 1->1, 1->n, n->1 ?) > - intégration des données CLC dans OSM : brut, régionalisé, individualisé > - garder des traces de l'info originale (ref, classe originale ? pour > quoi faire ?) > - planning des imports (par couche, par région, mix ?) > > La page sur le wiki http://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover/Nomenclature donne quelques pistes pour regrouper quelques choses. Cela reste a mes yeux le meilleur moyen de coordonner le travail. Il y a eus aussi plutot dans le thread des suggestions pour garder des informations comme l'annee et le type de la base CLC. Dans un premier temps, je vais essayer de produire des fichiers OSM selon la demande de chacuns et chacunes en commencant par les forets car sur le wiki, ca reste de loin le plus defini. > Bref, je n'ai pas plus de réponses qu'aucun autre. En tous cas, merci à > tous ceux qui ont déjà investi sur le sens de cette réutilisation des > données publiques. > Corine La Coriace ne se laissera pas apprivoiser en quelques jours. > "Patience et longueur de temps font plus que force ni que rage" > mes tuppence. Emilie Laffray
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
