Talk:WikiProject France/Parcs nationaux et régionaux, réserves naturelles/Import des données INPN

From OpenStreetMap Wiki
Jump to: navigation, search

Tests sur les données

Je suis actuellement (sletuffe 09:34, 3 June 2010 (UTC)) en train de faire des tests sur les données disponibles gràce à l'INPN, (voir mes fichiers regroupés indiqués sur la "phase alpha" ) Je m'oriente vers la solution suivante :

  • 1 Import de tout dans une base postrgres/gis dans une seule table
  • 2 export en shapefile des données à importer (c'est à dire celles qui ne rentrent pas en conflit avec des données déjà existantes de osm)
  • 3 conversion des shapefile en donnée OSM gràce à ogr2osm
  • 4 import dans osm avec bulkupload.py

Commentaires et problèmes : La phase 1 montre que l'ensemble des fichiers n'est pas si homogène que ça. Certains champs contiennent la même donnée mais portent un nom différent (exemple de date et date_) la projection est annoncée comme étant lambert93, sauf que certains (peut-être les territoires d'outre mer) ne semblent pas utiliser cette projection. (cf carte)

Il est probable qu'il faille faire ça fichier par fichier et étape par étape.

Avis et recherche de consensus

Propositions

Bon, voici ce que je propose :

  1. on rassemble tous les (multi-)polygones "Espaces Protégés" de l'INPN sous la forme de polygones (ou relations pour les multi) taggués boundary=protected_area. Sauf les terrains du Conservatoire du Littoral, et ceux qui se trouvent déjà dans OSM (mais rien n'empêche de les fournir au format .osm pour import ultérieur comme pour Corine).
  2. on rentre le nom des objets dans name=
  3. on rentre la source INPN (source=Inventaire National du Patrimoine Naturel 2010)
  4. on rentre la date de création (décret...) dans une balise valid_from=AAAA-MM-JJ
  5. on rentre l'identifiant international ID_SPN dans une balise id_spn=
  6. on rentre le genre d'espace protégé en français dans protection_title= (par ex. protection_title=Arrêté de protection de biotope)
  7. on rentre la classification IUCN de l'espace protégé dans protect_id= (de 1 à 6 ou 98 pour l'international)
  8. pour les réserves biologiques, on ajoute la valeur de l'attribut ID_ORG dans la balise id_org=
  9. on laisse tomber l'ID_DIREN, la SUPERFICIE (rarement bien renseignée) et les autres attributs.
  10. on les envoie dans la base OSM


Questions ouvertes

J'espère qu'une phase de concertation publique sera ouverte avant l'import. Il y a certainement des points à discuter, en particulier les tags. --Pieren 13:44, 8 June 2010 (UTC)

Oui, comment faire cette phase de concertation publique ? Est-ce une procédure de vote ? Et est-ce que tu penses à des points en particulier qui te semblent à discuter ? Pour l'instant j'ai défriché mais on n'est pas nombreux. Damouns 14:43, 8 June 2010 (UTC)

Je déclare officiellement ouverte la phase de concertation publique ! Damouns 11:54, 25 June 2010 (UTC)


Choix de tags

Les questions :

  • est-ce qu'on utilise la proposition de balise boundary=protected_area y compris pour les Parcs Nationaux (coeurs et aire d'adhésion) et les réserves (volontaires, nationales, de chasse et faune sauvage, biologiques, de biosphère ?) même s'il existe déjà des tags boundary=national_park et leisure=nature_reserve ? Damouns 11:54, 25 June 2010 (UTC)
Je ne suis pas connaisseur de ces questions. Mais si les parcs nationnaux ont une zone de cœur et une zone périphérique, une des zones correspondrait-elle plus au boundary=protected_area et l'autre plus au boundary=national_park. Si non, comment prendre en compte les deux réalités ?
Les réserves me semblent être plus à mettre en leisure=nature_reserve, avec des tags complémentaires (operator,
  • _level ou autre...) ou alors mon anglais est nul.
Pour le reste, la procédure et les choix me semblent correct. Nihil obstat --FrViPofm 13:02, 25 June 2010 (UTC)
On pourrait tagguer les cœurs de PN en boundary=national_park, puisque c'est à mon avis ce à quoi on pense quand on parle de parc national (zone la plus protégée). Pour les réserves, on peut tagguer à la fois leisure=nature_reserve et boundary=protected_area, ce n'est pas incompatible. Damouns 11:36, 28 June 2010 (UTC)
Ce n'est que mon avis, pour la question 1, je dirais que ça ne mange pas de pain de mettre le boundary=protected_area et le leisure=nature_reserve (quand il s'agit d'une réserve) et boundary=national_park pour un parc nationnal, ça permettrait aux systèmes de rendu actuel de marcher. (Bien que je m'empresserais moi de faire le rendu des boundary=protected_area sur mon rendu rando) sletuffe 14:19, 29 June 2010 (UTC)

Questions rendu

  • est ce que quelqu'un peut faire une demande/proposition au niveau des moteurs de rendu pour que ces objets soient visibles (dans Mapnik en particulier) ? Je pencherais pour un contour mais pas de remplissage.Damouns 11:54, 25 June 2010 (UTC)
Au niveau rendu, comme d'hab, chacun fait sa cuisine dans son coin, mais moi j'ai fais ça [1] et je trouve ça mieux que la rendu actuel sur mapnik. Encore une fois, le rendu vient après l'utilisation : y'a qu'a faire, les rendus suivront ensuite sletuffe 14:19, 29 June 2010 (UTC)

Conversion technique (ogr2osm ?)

  • Comment faire la conversion shp vers osm ? Sly, tu maîtrises bien ogr2osm ?Damouns 11:54, 25 June 2010 (UTC)
j'ai un peu touché à ogr2osm, mais il me semble que tu as plus d'avance que moi ! D'ailleurs je n'ai pas réussi à le faire marcher avec ton fichier de traduction. A noter que la version du SVN ne gère pas les chemins de plus de 2000 points et l'import ne marchera pas pour certain gros polygones j'ai codé un patch de correction pour ogr2osm ici : [2] sletuffe 14:13, 29 June 2010 (UTC)
J'ai fait un test de conversion avec reu_pn2010.shp qui a l'avantage d'être petit et l'intérêt d'avoir 2 gros multipolygones jointifs et imbriqués (le coeur et l'aire d'adhésion du PN des Hauts de La Réunion). D'abord, effectivement je n'arrive pas à utiliser le fichier de traduction, que j'ai pourtant écrit comme dans les exemples (il me semble). Ensuite, le résultat (sans le fichier de traduction) est très moche avec un découpage en plein de petits bouts de lignes de 5 points environ : par exemple à la frontière des 2 zones j'ai : 1 bout qui est dans les 2 multipoygons, puis 2 bouts superposés qui sont chacun dans un multipolygon, puis 1 bout qui est dans les 2 multipoygons, etc. Que ce soit avec ton script ou l'autre. Je me demande s'il ne vaudrait mieux pas utiliser la méthode de Corine. Damouns 15:00, 30 June 2010 (UTC)
L'import corine a utilisé polyshp2osm.py, et pour moi, celui là ou un autre, je m'en fiche ;-) Mais il m'a semblé que polyshp2osm.py n'était pas non plus vide de bug et que Émilie avait pas mal hacké le truc pour arriver à un résultat "spécial corine". Bref, faut prendre un peu de temps et comparer les résultats. M'enfin, avec ogr2osm, si on arrive déjà pas à mettre les tags qu'on veut, c'est plutôt mal barré... sletuffe 15:45, 30 June 2010 (UTC)
Je note toutefois que si je prends cette fois les parcs nationaux de métropole, le problème ne se présente pas et le résultat semble satisfaisant. Un problème possible dans la donnée source ? sletuffe 16:24, 30 June 2010 (UTC)
J'ai un peu trifouiller le ogr2osm pour arriver à un résultat qui commence à avoir de la gueule, ici les parcs nationaux et réserves naturelles "presque prêt(e)s" : [3] sletuffe 17:49, 30 June 2010 (UTC)

Formatage des noms

  • le nom : est-ce qu'on garde le nom original ? Pour les noms en toutes capitales, qu'est-ce qu'on fait ? Comment détecter les fautes d'orthogrpahes (accents...)Damouns 11:54, 25 June 2010 (UTC)
Pour l'orthographe, si on peut appliquer les règles de toponymies déjà bien répandues (majuscules...). je crois que de bons outils existent qui ont été utilisés pour les repères géodésiques par exemple. Je pense qu'il ne doit pas y avoir un tel volume de données qu'il faille passer trop de temps à élaborer un outil spécifique. Peut-être une extraction des chaînes dans un .csv pour une correction en liste puis on ré-injecte l'ensemble, si c'est faisable. Sinon, pour la suite, osmose pointera ce qui doit être corrigé à la main.FrViPofm 13:02, 25 June 2010 (UTC)

Calage sur le cadastre

  • J'avais entré la réserve de la Massane [4] (dans les Pyrénées-Orientales) en parc naturel d'après les informations cadastrales de l'arrêté. Je viens de reporter les informations de l'import des réserves dans la relation que j'avais créé à l'époque, quelqu'un peut vérifier si j'ai fait ça correctement ? - Petrovsk 09:26, 5 July 2010 (UTC)
ça m'a l'air nickel sauf que tu devrais mettre comme source que c'est plutôt cadastre + arrêté, ce qui serait bien c'est aussi un lien vers l'arrêté sur Legifrance etc. On pourrait mettre source1 = cadastre-dgi-fr... + source2 = Décret n°XXX du tant créant la réserve... + source2_ref = http://www.legifrance.gouv.fr/lien_vers_le_decret + source3 = Inventaire National du Patrimoine Naturel 2010 ? Damouns 12:07, 5 July 2010 (UTC)
+1, en copiant la source automatique "Inventaire National du Patrimoine Naturel 2010" on perd l'information qui est que tu as saisie les fontières avec le cadastre+arrêté (potentiellement plus précis), et un import futur pourrait mettre à jour cette réserve avec quelque chose de moins bon. Si tu as par contre repris quelques morceaux (genre un mixe) de l'import, alors ce que tu peux faire c'est créer une relation avec les différents ways, et indiquer la source sur chacun des ways pour différencier la provenance. sletuffe 12:23, 5 July 2010 (UTC)
J'ai conservé les limites que j'avais tracées d'après le cadastre, j'ai juste placé les infos de l'import sur la relation. Les ways membres conservent leur source cadastre (sauf la frontière France-Espagne qui est un mixte cadastre-import espagnol et se retrouve sans source depuis lors). Je suis partisan de signaler toutes les sources (cadastre+arrêté, inpn), le tout est de savoir comment faire apparaître tout ça sur la relation (source=x puis source2=y... ?).
Lien de l'arrêté de création. - Petrovsk 19:48, 5 July 2010 (UTC)

Nouvelle version de ogr2osm.py

Les problèmes que j'avais rencontrés pour le Parc National de La Réunion étaient dûs à des points qui n'étaient pas exactement aux mêmes coordonnées (ça ne se voyait pas dans le résultat .osm car il y avait eu un arrondi après). Pour corriger ce problème il faut ajouter dans ogr2osm.py les deux lignes suivantes :

	x = round(x, 8)
	y = round(y, 8)

dans la définition de la fonction addNode, tout au début (cela permet d'arrondir les coordonnées à 1E-8 degrés soit pas plus de 11,11 mm. Damouns 09:54, 8 July 2010 (UTC)

J'ai re-modifié le programme ogr2osm.py (version Sly) pour qu'on n'ait qu'une seule relation par objet "feature" dans le shapefile initial. Par contre du coup il ne prend plus que les (multi-)polygones en entrée. J'ai ainsi regénéré l'ensemble des couches de l'INPN au format OSM. Mais il y a encore des erreurs dûes à des polygones non conformes (par exemple le Parc Naturel Marin d'Iroise a une boucle interne, il se recoupe, donc l'algo d'ogr2osm mouline et fait des ways superposés à cet endroit) : je vais passer en revue tous les fichiers générés avec le Validator de JOSM avant de les uploader. Damouns 08:33, 9 July 2010 (UTC)