Note: un outils comme Corine serait maintenant plus intéressant dans des pays en développement où presque tout est à faire, notamment en Afrique centrale ou dans les immenses territoires ruraux de Russie, de Chine ou d'Australie (bien que là il doit exister des sources locales comparables: Corine en Europe c'est un peu comme TIGER aux USA): ça va bien pendant un temps et c'est très utile pour avancer et mieux que rien du tout car ça permet de localiser plein d'objets relativement et dresser un état du terrain pour ensuite se concentrer sur des zones plus petites et améliorer la précision; mais ensuite on doit gérer cet historique de façon plus incrémentale et on ne réimporte pas à nouveau ce type de source. Au Canada il y a eu certains imports dans l'Est mais c'est visiblement difficile de continuer, la progression est devenue très lente, malgré la relativement bonne qualité des données topographiques.
Le 19 mars 2018 à 20:22, Magalie Dartus <mag.dar...@gmail.com> a écrit : > Merci pour cet historique complet et très intéressant de CLC dans OSM. > > > Le 19 mars 2018 à 19:25, Philippe Verdy <verd...@wanadoo.fr> a écrit : > >> 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
