Le cadastre n'a rien preque qui correspond à nos landuses (hormis les surfaces d'eau de précision appromimative mais un peu plus précise que Corine, le bati, les limites de parcelles, la tononymie et des adresses). Nos landuses sont basés beaucoup plus sur l'imagerie aérienne de meilleure précision que celle utilisée par Corine. Corine est davantage un élément de comparaison pour identifier le type de végétation et de sol si on ne voit pas bien. ou pour détecter de grosses incohérences. Corine a été utilisé pour fournir une couverture minimale du sol partout en France avant même qu'on finisse le tracé des communes et l'essentiel du réseau routier, puis des tas de petits chemins et le détail des rues et adresses. Depuis on a pas repris les imports car partout on a largement amélioré les choses, en tenant justement compte des routes, du bati, des tracés plus précis des cours d'eau. Les surfaces forestières et agricoles de Corine sont vraiment trop floues, même chose pour les surfaces des agglomérations (résidentielles, commerciales, industrielles, ferroviaires) et l'aménagement public des parcs et jardins.
Il y a encore de nombreux éléments de Corine dans la base quand le plus gros de leur surface n'a pas eu besoin d'être redécoupé, ou seulement affiné localement sur les bords. Mais on ne se gêne plus pour les découper, et aussi réunir des fragments de gros polygones Corine dont le découpage était sur des lignes de coupe arbitraires: quand on fait ce nettoyage, et que les nouveaux polygones ne correspondent plus à rien d'identifiable sur Corine, on vire ces références anciennes: nos objets sont bien plus petits et plus précis, ce qui était un gros polygone contigu est devenu des séries de polygones séparés avec d'autres éléments plus petits intercalaires qui ne correspondent pas du tout à la classification Corine: on n'a plus rien de commun, ni les tags de classification, ni la géométrie, donc pas besoin de garder les anciens identifiants d'imports. D'ailleurs d'une édition à l'autre de Corine il n'y a aucune stabilité des identifiants, et parfois des changements dans les codes de classification (et pas liés non plus à des évolutions du terrain physique), donc on a pas moyen de revenir dessus: ces identifiants Corine dans OSM sont des outils temporaires destinés juste à vérifier la qualité des imports réalisés, on n'a aucun système de retour qualité d'OSM vers Corine, et pas moyen de comparer réellement par des moyens automatiques de veille qualité. La source Corine devient donc de moins en moins pertinente. Attention cependant à ne pas les supprimer en masse : cette suppression se fait de façon graduelle au fil des améliorations et travaux de nettoyage. La suppression en masse serait un abus des droits d'auteur de Corine (même si globalement, OSM indique que Corine a été utilisé comme une source sans indiquer précisément où, on indique juste la trace des années de références utilisées, et ça peut servir à détecter des zones qui auraient besoin d'être révisées quand de nouvelles sources deviennent disponibles et commencent à être utilisées). Aujourd'hui nos landuses en France sont passés à des précisions inférieures au mètre parfois même décimétrique pour améliorer le tracé des courbes alors que Corine était dessiné avec une précision décamétrique voire hectométrique par endroit, en omettant moultes détails (surtout dans les zones forestières et de montagne, mais même concernant les périphéries urbaines qui demandent partout à être revues car Corine fait des découpes trop arbitraires au travers des zones résidentielles et industrielles). Corine n'est également pas assez précis le long des côtes et surfaces lacustres. Le 19 mars 2018 à 18:59, Magalie Dartus <mag.dar...@gmail.com> a écrit : > Ok. > > Est-ce que les unités plus précises correspondent au cadastre? Ou bien > est-ce que c'est des polygones autres? > > Le 19 mars 2018 à 18:54, Philippe Verdy <verd...@wanadoo.fr> a écrit : > >> Il me semblait que le tag utilisé dans OSM c'était plutôt CLC:year=2006, >> et sinon CLC:id=* >> Et pas la peine de garder les anciennes versions de CLC si un nouvel >> import a eu lieu, d'autant plus qu'on n'en fait plus parce que la précision >> de CLC est largement inférieure à ce qu'on a maintenant dans OSM et qu'on >> met maintenant plutôt nos propres landuse=* entièremetn redéfinis sans >> référence à CLC qui n'est qu'une estimation statistique moyenne ne >> répondant plus à nos besoins. Dans tous les endroits où on a redéfini les >> données plus précises, on ne fait plus référence à CLC du tout et on vire >> les anciens polygones s'ils sont trop grossiers et qu'on doit les >> redécouper en plus petites unités plus précises. >> >> Le 19 mars 2018 à 18:05, Magalie Dartus <mag.dar...@gmail.com> a écrit : >> >>> Il me semble que CODE_12 est le champ qui défini l'occupation du sol >>> (selon la nomenclature de CLC). >>> En ce qui concerne le _12 cela correspond à l'année d'édition de CLC. >>> Pour CLC 2006 nous avons un champ CODE_06. >>> >>> Du coup c'est CLC 2012 qui est présent dans OSM... le détail est >>> important non? >>> >>> Le 19 mars 2018 à 17:19, Philippe Verdy <verd...@wanadoo.fr> a écrit : >>> >>>> A minima, "ne pas perdre l'info" OK à condition de cloisonner les tags >>>> de repli utilisés. Pour CLC, ces tags étaient identifiables par un préfixe >>>> commun "CODE_12" ne signifie rien du tout en tant que tel, rien n'indique >>>> que cela vient de CLC. >>>> Bref la bonne pratique si on veut ne rien perdre (car on droit faire un >>>> travail ultérieur de reclassification/normalisation ou bien les tags >>>> candidats sont encore incertains ou ambigus et à résoudre manuellement, ou >>>> bien les plus appropriés ont été précédemment dépréciés contre d'autres qui >>>> ne conviennent plus du tout) c'est de préfixer chaque tag (la présence >>>> d'autres tags CLC par exemple ne signifie pas que tous les tags viennent de >>>> CLC, de même les tags de source dans le changeset sont difficiles à >>>> suivre). >>>> Ceci dit il est bon de se demander si tous les tags d'une sources sont >>>> utiles: hormi l'identifiant unique de la source ou sa propre date de >>>> référence, pas la peine de tout mettre, surtout si la source est facilement >>>> consultable hors d'OSM). Pour que l'import soit utile et approprié il faut >>>> tout de même trouver des correspondances suffisantes permettant d'utiliser >>>> les objets dans l'écosystème OSM. Si le seul tag qu'on trouve c'est un >>>> "name", l'import n'est pas à faire du tout, il faudra discuter et détailler >>>> un plan d'intégration et des attributs proposés sur une page dédiée à cet >>>> import ou cette source (où on citera les URLs des descriptions source, les >>>> infos relatives aux licences ou accords de publicationn les points de >>>> contact éventuels pour les remontées d'informations, et d'autres >>>> indications comme la fréquence estimée des mises à jour et leur couverture, >>>> ainsi que si la couverture est totale ou fractionnée en plusieurs sous-jeux >>>> de données qu'on peut traiter séparément pour ne pas tout faire en masse >>>> mais régler déjà sur un premier jeu de teste et l'évaluer avant d'importer >>>> le reste). >>>> Evidememnt il faut ouvrir un espace de discussion à ce sujet (et il >>>> doit rester ouvert même après pour permettre de revoir ce qu'on fera des >>>> données si leur mise à jour tarde trop et leur précision n'est plus >>>> suffisante). >>>> >>>> Le 16 mars 2018 à 17:31, Adrien André <adr.an...@laposte.net> a écrit : >>>> >>>>> Bonjour, >>>>> >>>>> on trouve des polygones importés de CORINE Land Cover avec les tags >>>>> AREA_HA, id et CODE_12 [1]. >>>>> Osmose les relève en tant qu’erreurs [2]. >>>>> >>>>> Dans le Wiki [3], on lit, à propos de l'import, >>>>> "Ne pas perdre d'informations, même si CLC a des types plus riches que >>>>> OSM" >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Talk-fr mailing list >>>> Talk-fr@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>> >>>> >>> >> >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
