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
