Re: [OSM-talk-fr] Import CORINE Land Cover - Attributs bruts comme tags
Je ne conserve pas les infos CLC dans OSM suite aux mises à jour. Je découpe au fur et à mesure les polygones et les relations pour faire les mise à jours. Çà évite de faire des gros trous dans le fond. Je redécoupe en utilisant les voiries et le parcellaire donc la CLC et ses clés n'a gère de sens vu que l'échelle est beaucoup plus fine et la précision également. Si la CLC utilisait la couche vecteur cadastre et les couches routières et ferroviaires et pas seulement les images satellitaires, on arriverait surement au résultat suivant https://www.openstreetmap.org/#map=17/43.54825/3.74303 On garde l'information quand on peut faire une mise en correspondance. Une fois les redécoupages et la mise à jour du type d'occupation; les données résultantes n'ont plus aucun rapport avec la source. Donc les clés utilisés pour identifier l'occupation... Ce qu'il est plus intéressant c'est de se baser sur des codes EUNIS ou Corine Biotope mais j'ai pas vu qui que ce soit qualifier l'occupation avec ces clés. https://inpn.mnhn.fr/docs/ref_habitats/EUNIS_Correspondances.pdf C'est ce que font tous les BE en Environnement pour réaliser les cartes d'habitats naturels. Jérôme Le 20 mars 2018 à 12:24, marc marc a écrit : > Pour les attributs, je pense qu'il faut faire au + simple : > landuse est fatalement utile. > la ref peut-être utile si quelqu'un veux faire des stats d'évolution > du territoire, cela ne dérange pas trop de le garder. > Pour le reste, personne n'a jamais montré la moindre utilité > malgré des km de discussion et l'absence de maintenance rend chaque > année moins probable la moindre possibilité de réutiliser ces reliquats. > > Le 20. 03. 18 à 11:10, Rpnpif a écrit : > > Chez moi, Corine est souvent erroné > > Coupe à la hache ce qui doit l'être :) > Corine est un peu la caricature des problèmes d'imports :-( > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > -- Cordialement, Jérôme Seigneuret ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import CORINE Land Cover - Attributs bruts comme tags
Pour les attributs, je pense qu'il faut faire au + simple : landuse est fatalement utile. la ref peut-être utile si quelqu'un veux faire des stats d'évolution du territoire, cela ne dérange pas trop de le garder. Pour le reste, personne n'a jamais montré la moindre utilité malgré des km de discussion et l'absence de maintenance rend chaque année moins probable la moindre possibilité de réutiliser ces reliquats. Le 20. 03. 18 à 11:10, Rpnpif a écrit : > Chez moi, Corine est souvent erroné Coupe à la hache ce qui doit l'être :) Corine est un peu la caricature des problèmes d'imports :-( ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import CORINE Land Cover - Attributs bruts comme tags
Le 19 mars 2018, Philippe Verdy a écrit : > 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. Bonjour, Chez moi, Corine est souvent erroné en ce qui concerne l'occupation agricole (prairie et cultures). De très nombreuses prairies ont été malheureusement détruites depuis longtemps. Les PLU évoluant très vite, il n'est pas toujours pertinent sur l'urbain. Je trouve Corine plus gênant qu'utile sur une large partie de l'Ouest de la France. Ce n'est que mon avis. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import CORINE Land Cover - Attributs bruts comme tags
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 a écrit : > Merci pour cet historique complet et très intéressant de CLC dans OSM. > > > Le 19 mars 2018 à 19:25, Philippe Verdy 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 D
Re: [OSM-talk-fr] Import CORINE Land Cover - Attributs bruts comme tags
Merci pour cet historique complet et très intéressant de CLC dans OSM. Le 19 mars 2018 à 19:25, Philippe Verdy 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 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 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 a écrit : >>> Il me se
Re: [OSM-talk-fr] Import CORINE Land Cover - Attributs bruts comme tags
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 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 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 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ése
Re: [OSM-talk-fr] Import CORINE Land Cover - Attributs bruts comme tags
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 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 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 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é 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
Re: [OSM-talk-fr] Import CORINE Land Cover - Attributs bruts comme tags
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 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 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é 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
Re: [OSM-talk-fr] Import CORINE Land Cover - Attributs bruts comme tags
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 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é 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
Re: [OSM-talk-fr] Import CORINE Land Cover - Attributs bruts comme tags
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é 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
[OSM-talk-fr] Import CORINE Land Cover - Attributs bruts comme tags
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" Seulement, j'en comprends qu'il faudrait, peut-être, laisser le tag CODE_12 lorsqu'il n'y a pas de correspondance avec les tags OSM [4]. Je ne vois pas d'intérêt à conserver les identifiants CLC (id) (je présume que la correspondance OSM-CLC pourrait, en grande partie, se retrouver par traitement SIG) Enfin, c'est le rôle de l'outil de consultation que d'afficher l'aire d'une géométrie, comme on peut le voir avec QGIS [5]. L'information est redondante en base (intrinsèque à la géométrie), et rapidement obsolète. Comme on peut le constater au sein même du jeu de données original (voir capture QGIS). Ces tags sont-ils bien à corriger ? Y a-t'il des moyens de correction de masse qui pourraient être utilisés ? C.-à-d., en pseudo-code : Pour tous les polygones à tag CODE_12 de valeur 3210 : - s'il n'existe pas déjà, ajouter le tag natural=grassland - supprimer le tag CODE_12 D'avance merci ! Adrien [1] https://www.osm.org/way/410942307 [2] http://osmose.openstreetmap.fr/fr/map/#zoom=14&lat=5.41367&lon=-53.09804&item=9002%2C9008&level=1%2C2&tags=&fixable=&overlays=T [3] https://wiki.openstreetmap.org/wiki/FR:Corine_Land_Cover#Utilisation_dans_OSM [4] https://wiki.openstreetmap.org/wiki/FR:Corine_Land_Cover/Nomenclature [5] https://framapic.org/zeeo7Z2xCa0Q/NFxUrvnJW3zd.png ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import Corine Land Cover
Ah super, je ne connaissais pas ce moyen de faire. Ce soir, je m'occupe de modifier les autres imports ! Merci pour l'astuce. Arnaud 2012/3/6 didier2020 : > Le mardi 06 mars 2012 à 12:55 +0100, Arnaud Vandecasteele a écrit : >> Salut didier, >> >> Merci pour les infos. >> J'ai vu que tu avais ajouté le tag rock c'est super, merci :) >> Par contre je n'ai pas bien compris comment tu as procédé avec JOSM >> pour importer les ways. >> En PJ tu m'as envoyé la liste des ways mais comment fais-tu pour >> ajouter celle-ci à JOSM ? > Fichier -> telecharger un objet > tu selectionne chemin > dans la case identifiant tu mets tous les ways que tu désires > > cela telecharge tous les ways et noeuds. (relation si tu coche case a > cocher) > >> Pourrais-tu m'expliquer afin que je fasse la même opération pour le >> landuse forest. >> >> Merci > de rien ! > didier >> >> Arnaud >> >> 2012/3/6 didier2020 : >> > Le mardi 06 mars 2012 à 11:13 +0100, Arnaud Vandecasteele a écrit : >> >> Salut à tous, >> >> >> >> Ayant posté ma demande un WE et n'ayant pas eu de retours, je tente un >> >> petit coup de rappel : >> >> Lors de mon import de CLC sur la réunion, les attributs de la couche >> >> "forêt et végétation arbustive en mutation" (Code_06 324) et ceux >> >> "Roches nues" n'ont pas été correctement copiés. >> >> La géométrie a été correctement importée mais pas les attributs : >> >> >> >> landuse : forest >> >> natural: wood >> >> wood: yes >> >> species : Fôrets et végétations arbustives en mutation >> >> >> >> natural : rock >> >> >> >> Sauriez-vous comment ajouter ces informations à la base de manière >> >> automatique ? >> >> Sinon, serait-il possible de supprimer mes changesets (10796234, >> >> 10792524, 10793239). >> > >> > pour le groupe 10792524 il suffit de telecharger la liste des ways avec >> > josm et de faire tes modifications: >> > >> > dans le fichier joint >> > (j'ai fait du copier coller des way pour les pages 1 a 9) issu de >> > http://www.openstreetmap.org/browse/changeset/10792524 >> > >> > tu n'as plus qu'a faire cela pour l'autre changeset. >> > sauvegarder ses uploads permet de mieux gérer ce genre de désagrement >> > >> > bon courage >> > didier >> > >> >> J'ai essayé de le faire avec le plugin reverter mais sans succès. >> >> >> >> Merci pour votre aide. >> >> >> >> Arnaud >> >> >> >> ___ >> >> Talk-fr mailing list >> >> Talk-fr@openstreetmap.org >> >> http://lists.openstreetmap.org/listinfo/talk-fr >> > >> >> >> > > -- Arnaud Van De Casteele Mines Paris Tech - CRC Sophia-Antipolis 0698 24 25 29 SIG - WebMapping - SOLAP - BI - GeoCollaboration Web Site http://geotribu.net/ http://www.i2c.eu/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import Corine Land Cover
Le mardi 06 mars 2012 à 12:59 +0100, didier2020 a écrit : > Le mardi 06 mars 2012 à 12:41 +0100, Pieren a écrit : > > 2012/3/6 didier2020 : > > > > > Pourquoi supprimer? > > > > > > Groupe de modifications : 10796234 => tag natural=rock ajouté > > > > Tu es sûr que ça s'applique aux 20 polygones du "groupe de modifications" ? > j'ai téléchargé tous les ways, et oui pour ce groupe de modification le > code clc est le meme. reponse incompléte: sauf pour les inner de la relation qui n'avaient pas de tag clc:code > > didier > > > > Pieren > > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-fr > > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import Corine Land Cover
Le mardi 06 mars 2012 à 12:41 +0100, Pieren a écrit : > 2012/3/6 didier2020 : > > > Pourquoi supprimer? > > > > Groupe de modifications : 10796234 => tag natural=rock ajouté > > Tu es sûr que ça s'applique aux 20 polygones du "groupe de modifications" ? j'ai téléchargé tous les ways, et oui pour ce groupe de modification le code clc est le meme. didier > > Pieren > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import Corine Land Cover
Salut didier, Merci pour les infos. J'ai vu que tu avais ajouté le tag rock c'est super, merci :) Par contre je n'ai pas bien compris comment tu as procédé avec JOSM pour importer les ways. En PJ tu m'as envoyé la liste des ways mais comment fais-tu pour ajouter celle-ci à JOSM ? Pourrais-tu m'expliquer afin que je fasse la même opération pour le landuse forest. Merci Arnaud 2012/3/6 didier2020 : > Le mardi 06 mars 2012 à 11:13 +0100, Arnaud Vandecasteele a écrit : >> Salut à tous, >> >> Ayant posté ma demande un WE et n'ayant pas eu de retours, je tente un >> petit coup de rappel : >> Lors de mon import de CLC sur la réunion, les attributs de la couche >> "forêt et végétation arbustive en mutation" (Code_06 324) et ceux >> "Roches nues" n'ont pas été correctement copiés. >> La géométrie a été correctement importée mais pas les attributs : >> >> landuse : forest >> natural: wood >> wood: yes >> species : Fôrets et végétations arbustives en mutation >> >> natural : rock >> >> Sauriez-vous comment ajouter ces informations à la base de manière >> automatique ? >> Sinon, serait-il possible de supprimer mes changesets (10796234, >> 10792524, 10793239). > > pour le groupe 10792524 il suffit de telecharger la liste des ways avec > josm et de faire tes modifications: > > dans le fichier joint > (j'ai fait du copier coller des way pour les pages 1 a 9) issu de > http://www.openstreetmap.org/browse/changeset/10792524 > > tu n'as plus qu'a faire cela pour l'autre changeset. > sauvegarder ses uploads permet de mieux gérer ce genre de désagrement > > bon courage > didier > >> J'ai essayé de le faire avec le plugin reverter mais sans succès. >> >> Merci pour votre aide. >> >> Arnaud >> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-fr > -- Arnaud Van De Casteele Mines Paris Tech - CRC Sophia-Antipolis 0698 24 25 29 SIG - WebMapping - SOLAP - BI - GeoCollaboration Web Site http://geotribu.net/ http://www.i2c.eu/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import Corine Land Cover
2012/3/6 Pieren : > aux 20 polygones du "groupe de modifications" ? euh, aux 2600 polygones plutôt Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import Corine Land Cover
2012/3/6 didier2020 : > Pourquoi supprimer? > > Groupe de modifications : 10796234 => tag natural=rock ajouté Tu es sûr que ça s'applique aux 20 polygones du "groupe de modifications" ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import Corine Land Cover
Le mardi 06 mars 2012 à 11:13 +0100, Arnaud Vandecasteele a écrit : > Salut à tous, > > Ayant posté ma demande un WE et n'ayant pas eu de retours, je tente un > petit coup de rappel : > Lors de mon import de CLC sur la réunion, les attributs de la couche > "forêt et végétation arbustive en mutation" (Code_06 324) et ceux > "Roches nues" n'ont pas été correctement copiés. > La géométrie a été correctement importée mais pas les attributs : > > landuse : forest > natural: wood > wood: yes > species : Fôrets et végétations arbustives en mutation > > natural : rock > > Sauriez-vous comment ajouter ces informations à la base de manière > automatique ? > Sinon, serait-il possible de supprimer mes changesets (10796234, > 10792524, 10793239). Pourquoi supprimer? Groupe de modifications : 10796234 => tag natural=rock ajouté > Merci pour votre aide. > > Arnaud > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Import Corine Land Cover
Salut à tous, Ayant posté ma demande un WE et n'ayant pas eu de retours, je tente un petit coup de rappel : Lors de mon import de CLC sur la réunion, les attributs de la couche "forêt et végétation arbustive en mutation" (Code_06 324) et ceux "Roches nues" n'ont pas été correctement copiés. La géométrie a été correctement importée mais pas les attributs : landuse : forest natural: wood wood: yes species : Fôrets et végétations arbustives en mutation natural : rock Sauriez-vous comment ajouter ces informations à la base de manière automatique ? Sinon, serait-il possible de supprimer mes changesets (10796234, 10792524, 10793239). J'ai essayé de le faire avec le plugin reverter mais sans succès. Merci pour votre aide. Arnaud ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Import Corine Land Cover - Ile de la Réunion
Bonjour à tous, Lors de mon import de CLC sur la réunion, les attributs de la couche "forêt et végétation arbustive en mutation" (Code_06 324) et ceux "Roches nues" n'ont pas été correctement copié. La géométrie a été importée mais pas les attributs : landuse : forest natural: wood wood: yes species : Fôrets et végétations arbustives en mutation natural : rock Sauriez-vous comment ajouter ces informations à la base de manière automatique ? Sinon serait-il possible de supprimer mes changesets (10796234, 10792524, 10793239). J'ai essayé de le faire avec le plugin reverter mais sans succès. Merci pour votre aide. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import Corine Land Cover
Le 25/02/2012 20:49, Jocelyn Jaubert a écrit : Le 25 février 2012, Emilie Laffray a écrit : Demander à sly un rendu mapnik. On a un rendu sur clc.openstreetmap.fr, mais je ne crois pas que ce soit sly qui l'ait fait. Les tiles sont sur une machine nommée http://sd1878-2.sivit.org, et je ne sais pas si c'est simple d'y rajouter les tiles pour la Réunion. Je crois que le layer prend les tuiles directement sur le serveur CLC d'origine. Et on n'y a pas vraiment accès ;-) -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import Corine Land Cover
Le 25 février 2012, Emilie Laffray a écrit : > Demander à sly un rendu mapnik. On a un rendu sur clc.openstreetmap.fr, mais je ne crois pas que ce soit sly qui l'ait fait. Les tiles sont sur une machine nommée http://sd1878-2.sivit.org, et je ne sais pas si c'est simple d'y rajouter les tiles pour la Réunion. Par contre, je dois pouvoir faire quelque chose pour mettre des marqueurs notant les polygones à importer, et faciliter leur import manuel - du moins après qu'un éventuel import automatique soit fait. Arnaud, est-ce que ça t'intéresse ? -- Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import Corine Land Cover
J'avais oublié de vous donner un exemple de l'import : http://www.openstreetmap.org/browse/changeset/10786012 Pour le moment, je n'ai importé que cette zone afin que vous validiez la démarche. Merci Arnaud 2012/2/25 Arnaud Vandecasteele : > Bonjour à tous, > > J'ai téléchargé sur le site du club géomatique de la réunion les > données Corine Land Cover pour la zone de l'Ile de la Réunion [1]. > Elles ont ensuite été transformées en fichier OSM en fonction de leur > typologie grâce au script Ogr2OSM [2]. > Je sais que beaucoup d'entre vous ont travaillé à l'import de ces > données sur la métropole. > Avant de commencer à travailler dessus auriez-vous des conseils à me donner ? > > Merci > > Arnaud > > [1] > http://clubgeomatique.agorah.com/clubgeomatique/index.php/les-projets-reunionnais-lies-aux-sig-et-a-la-geomatique/401-corine-land-cover-reunion-2000-a-2006.html > [2] http://wiki.openstreetmap.org/wiki/Ogr2osm -- Arnaud Van De Casteele Mines Paris Tech - CRC Sophia-Antipolis 0698 24 25 29 SIG - WebMapping - SOLAP - BI - GeoCollaboration Web Site http://geotribu.net/ http://www.i2c.eu/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import Corine Land Cover
Salut, Regarder le wiki. Demander à sly un rendu mapnik. Détecter les polygones déjà existants. Le wiki a la première version de la requête. Je peux te donner la dernière. Avant d'utiliser ogr2osm, il Faut filtrer ce dont tu ne veux pas dans postgis. On Feb 25, 2012 9:28 AM, "Arnaud Vandecasteele" wrote: > Bonjour à tous, > > J'ai téléchargé sur le site du club géomatique de la réunion les > données Corine Land Cover pour la zone de l'Ile de la Réunion [1]. > Elles ont ensuite été transformées en fichier OSM en fonction de leur > typologie grâce au script Ogr2OSM [2]. > Je sais que beaucoup d'entre vous ont travaillé à l'import de ces > données sur la métropole. > Avant de commencer à travailler dessus auriez-vous des conseils à me > donner ? > > Merci > > Arnaud > > [1] > http://clubgeomatique.agorah.com/clubgeomatique/index.php/les-projets-reunionnais-lies-aux-sig-et-a-la-geomatique/401-corine-land-cover-reunion-2000-a-2006.html > [2] http://wiki.openstreetmap.org/wiki/Ogr2osm > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Import Corine Land Cover
Bonjour à tous, J'ai téléchargé sur le site du club géomatique de la réunion les données Corine Land Cover pour la zone de l'Ile de la Réunion [1]. Elles ont ensuite été transformées en fichier OSM en fonction de leur typologie grâce au script Ogr2OSM [2]. Je sais que beaucoup d'entre vous ont travaillé à l'import de ces données sur la métropole. Avant de commencer à travailler dessus auriez-vous des conseils à me donner ? Merci Arnaud [1] http://clubgeomatique.agorah.com/clubgeomatique/index.php/les-projets-reunionnais-lies-aux-sig-et-a-la-geomatique/401-corine-land-cover-reunion-2000-a-2006.html [2] http://wiki.openstreetmap.org/wiki/Ogr2osm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
