Le problème par rapport au logiciel SIG sur le mutipolygones c'est de considérer qu'un Inner peut être différent du polygon englobant... En fait il faudrait faire que les way inner et outer. Puis créer le mutipolygone à la fin et le qualifier.
Exmeple: Comme pour les lacs à élément multiple contenant des ilots de terre. Et traiter ça comme une seule couche. Puis dessiner ensuite dans les trous les landuses sur les noeuds existant. ça fait un double traitement mais ça c'est propre et simple à convertir sur d'autre SIG. Là, sur OSM, on considère que tout est mélangeable (empilable) pour avoir des objets imbriquable à souhait. C'est là que pose le problème et c'est une logique qu'un sigiste n'a pas car l'ensemble des autres soft ne focntionnent pas ainsi mais par couches séparées ou par objet séparé et jointif. Donc non imbriqué. 9a c'est lié au format XML ou JSON Le 16 octobre 2014 10:36, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Si on met les tags juste sur les ways outer, les autres ways inner > risquent de ne pas être chargés et on va obtenir un rendu ou une analyse > incorrecte sur les zones couvertes par les enclaves où le tag ne s'applique > pas. > De plus il arrive assez souvent que les tags applicable au multipolygone > entier ne puisse PAS s'appliquer sans conflit sur les ways outer qui sont > aussi des way outer d'autres multipolygone (il y a souvent des conflits > d'interprétation entre les valeurs de tag selon la présence d'autres tags > ou selon le type de multipolygone (notamment les highway=*, waterway=*; > natural=*; man_made=* qui sont un peu trop fourre-tout) > Il est logique de ne plus utiliser des tags sur des ways qui ne sont pas > interprétables correctement hors du multipolygone complet qui seul définit > la géométrie applicable sur l'objet complètement délimité. > De plus en terme de maintenance on évite une redondance de données, l'info > est centralisée au bon endroit sans avoir besoin d'être dupliquée et > maintenue de façon cohérente dans tous les membres outer (d'autant plus > qu'il arrive fréquemment que lors de correction de précision, des ways > changent de role outer/inner (et nombre d'utilisateurs oublient de changer > ce rôle qui est surtout informatif dans les relations multipolygon, > boundary et similaires décrivant des surfaces) > > Il faut absolument apprendre aux utilisateurs qu'un chemin seul même s'il > ne semble pas avoir de tags utile, peut être lié à des relations qui > définissent son usage. Mais du fait que les éditeurs "si,ples" pour > débutant dissimulent trop ces informations (iD est horrible, il rend ces > infos quasi invisibles), on doit encore mettre quelques infos minimales > redondantes sur les ways. Ce problème existe tout autant quand on consulte > un objet sur le site ou son historique: sans cette redondance minimale (ou > un tag informatif de note) ces objets ne sont pas facilement repérable dans > des longues listes d'objet pour faciliter leur sélection correcte lors de > l'édition. > > Bref on doit mettre tous les tags utile sur les polygones et non sur les > ways si ces tags sont implicitement interprétés comme applicables, et > surtout si ces ways sont fermés. On doit supprier ces tags des ways pour > éviter aussi des conflits de valeurs de tags entre la valeur donnée dns le > multipolygone et celle sur le way. > > Pour le reste on peut mettre un peu de redondance mais à caractère > informatif sur le way. L'ennui est que pour certains tags, il est tout à > fait normal d'avoir une différence de valeur entre le tag de la relation et > celui du way; notamment sur les tags "name" qui autorisent d'avoir un nom > local approprié différent de celui de la relation complète. > > Dans d'autres cas c'est tout bonnement incorrect d'avoir le tag sur le way > outer, notamment sur les ways partagés par des relations décrivant des > surfaces adjascentes et toutes deux avec le rôle outer, car le tag sera bon > pour une relation mais pas pour l'autre. Le seul moyen de résoudre le > conflit d'interprétation est de mettre les tags appropriés pour chaque > surface dans chaque relation et pas du tout sur le way mitoyen (où ne peut > figurer qu'un tag informatif qui ne doit jamais être interprété comme > modifiant localement l'interprétation donnée par les relations complètes, > et sans ce cas on n'a souvent qu'un seul moyen, celui d'une note > informative mais surtout pas avec les mêmes tags avec des valeurs locales > différentes). > > > Le 16 octobre 2014 09:53, Pieren <pier...@gmail.com> a écrit : > >> 2014-10-15 23:55 GMT+02:00 Vincent de Château-Thierry <osm.v...@free.fr>: >> >> > Ça interpelle les débutants, soit. Mais, si je te suis, il faudrait >> > préconiser 2 manières de tagguer, en fonction de l'analyse faite sur les >> > tags des membres. À expliquer et à assimiler, c'est pire... Au moins, >> > statuer que pour _tous_ les multipolygons les tags sont sur la relation, >> > c'est constant, donc au final, à mon avis, plus simple. >> >> Pas forcément. On pourrait aussi dire que la valeur du polygone se >> définit toujours sur le/les ways extérieurs (outer), qu'il soit simple >> ou multi. >> >> Pieren >> >> _______________________________________________ >> 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 > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
