Je pense malgré tout qu'un tel regroupement de deux bois (ayant des caractéristiques wood=* différentes) dans un même multipolygone est malvenu. Mêm si ces bois portent le même nom, isl sont cartographiés comme des objets distincts.
Ce n'est pas parce qu'un moteur de rendu ne fait pas la différence entre les type wood=* et ne considère que le fait que ces objets sont visualisés de façon identique comme étant une seule et même forêt que ce moteur (qui a choisi d'ignorer wood=*) doit s'empêcher alors de les fusionner dans un seul objet. S'il fait cette fusion alors, il va détecter des tags communs et devrait appliquer le nom une seule fois à cet ensemble. Dès lors ce nom sera affiché une seule fois à la position du centroïde de l'ensemble ainsi créé. Comme on ne tague pas pour le rendu, on doit alors taguer pour ce qui est le plus précis. Ce n'est pas à OSM de faire cette fusion à cause de certains tags ignorés ou non différenciés par un moteur de rendu spécifique. L'ennui c'est que les "landuse=*" sont souvent instables et imprécis, au regard des noms effectivement portés localement : un même landuse=forest comprend souvent des zones différentes sans s'appuyer sur le tracé des parcelles, parce que la plupart ont été créés par un import de la base Corine, qui ne s'est jamais appuyée sur le cadastre, mais seulement sur une photo apparente à un instant T (en fait un jeu de photos récoltées à des moments différents, avec une résolution faible, et analysées sommairement sans tenir compte des limites réelles de terrains, parcelles, et des limites administratives ; les landuse=* ont aussi été découpés en sous-polygones adjascents de façon totalement arbitraire, uniquement pour en réduire la surface ; surtout d'ailleurs les forêts et particulièrement dans les zones montagneuses, et les terres agrocoles qui changent fréquemment de type de culture : l'analyse Corine ne sait pas clairement distinguer la simple jachère d'une prairie d'élevage, souvent les divisions sont arbitraires et globalement cela donne juste une idée du taux approximatif d'utilisation des terres, dans des zones larges de la taille d'une commune entière, et pas au niveau local ; cela fait juste "joli" aussi sur les cartes, mais c'est en fait assez éloigné de la topographie réelle dès qu'on zoome un peu au point qu'on voit se distinguer certaines limites de parcelles, comme aussi l'hydrographie terrestre et maritime...). J'espère que l'import Corine, qui n'a été fait qu'une fois pour la base 2006, ne sera jamais refait une autre fois car partout on est amené à corriger ces données très imprécises. On peut essayer de garder certains tags contenant les identifiants Corine d'origine, mais dès qu'on a fait des modifications pour préciser les choses, il n'y a plus unicité des zones Corine dans OSM : cela signale juste que la zone Corine a été importée et ne doit plus l'être. Peut importe alors la date de cet import, mais au moins cela devrait garantir qu'on ne le refera pas pour le même objet Corine, même si depuis Corine a été mis à jour. On peut faire, et on fait, mieux que Corine dans OSM, même si pour l'instant on n'a pas des données plus précises avec le même taux de couverture du territoire (Corine est là dans la base OSM faute de mieux... en attendant qu'on corrige) Le 22 août 2012 09:57, Pieren <pier...@gmail.com> a écrit : > 2012/8/22 Philippe Verdy <verd...@wanadoo.fr>: >> C'est pour tant ce qu'il faut faire. Le nom commun pour l'ensemble des >> polygone va dans la relation multipolygone. > > Le tag 'name' n'est qu'une partie du problème. Les deux polygones ont > des tags communs (name, landuse) et différents (wood). Alors qu'un des > caractères de l'objet est décrit par un tag composé (landuse+wood). Si > on met uniquement "name" dans la relation", on perd le lien direct > entre le nom et les typages "landuse". Si on met aussi le tag commun > "landuse" dans la relation, on perd le lien direct entre "landuse" et > "wood". On ne peut pas mettre "wood" dans la relation puisqu'il est > différent pour chaque polygone. > > Perso, je dirais que la relation de type multipolygon est bien adapté > pour grouper des polygones de même nature (tous les tags identiques) > mais pas dans les autres cas, surtout pour les tags composés. > Logiquement, on pourrait dire que les tags communs sont mis dans la > relation et que les parties plus spécifiques se mettent dans les > polygones eux-même. Aux logiciels ensuite de reconstruire l'ensemble > du typage en additionnant les tags de la relation avec ceux de chaque > polygone. Mais je ne crois pas que ce soit formalisé quelque part et > je doute qu'aucun logiciel procède de cette façon. Je pense que ce > problème mériterait une réflexion au niveau international , sur la > liste tagging par exemple. > > Pieren _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
