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