<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">Le 20 décembre 2017 à 06:49, Jérôme Amagat <span dir="ltr"><<a href="mailto:jerome.amagat@gmail.com" target="_blank">jerome.amagat@gmail.com</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">Le 20 décembre 2017 à 00:23, Philippe Verdy <span dir="ltr"><<a href="mailto:verdy_p@wanadoo.fr" target="_blank">verdy_p@wanadoo.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">La logique actuelle des multipolygones est de n'avoir QUE des "ways" comme membres (de rôle outer ou inner), les membres de type "node" ou "relation" sont dépréciés (ils ont été utilisés au début en Allemagne)<div><br><div>Pour les archipels, on peut envisager d'en faire plutot des type="boundary" (avec  "boundary=natural" à défaut de "boundary=administrative" si ce ne sont pas des entités administratives, plus "natural=archipelago" au lieu de "place=archipelago" pour les entités adminisitratives), afin de :</div></div></div></blockquote><div><br></div></span><div>Pourquoi créé de nouveau tag on a déjà quelque chose qui existe et qui convient dans notre cas c'est un multipolygon et c'est un archipel donc type=multipolygon et place=archipelago. Je ne comprend pas pourquoi "boundary" ce n'est pas une frontière de quoi que ce soit et pourquoi changer place= en natural=*<br></div></div></div></div></blockquote><div>Ce n'est pas un nouveau tag. les multipolygones n'ont aucun autre membre que des ways. Les boundary sont adaptés à ce cas cela ne désigne pas que des frontières administratives, il y a d'autres types de frontières non administratives.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div><div>- continuer à mettre tous les ways "outer"/inner" nécessaires pour toutes les îles et îlots.</div><div>- mettre en rôle "subarea" d'autres relations "boundary=natural" pour les sous-archipels possibles eux aussi décrits de la même façon.</div></div></div></blockquote><div><br></div></span><div>Les subarea ça complique les relations et ça peut être retrouver avec la géométrie des différentes relations. Je sais que tu en mets partout mais je ne comprend pas l'utilité.<br></div></div></div></div></blockquote><div><br></div><div>Ca ne complique pas tant que ça, juste un seul membre dans la relation parente, la complexité est liée uniquement aux ways membres (outer) dans la relation parent: la relation parente peut en avoir beaucoup et ils sont facilement cassés, alors que le membre unique pour la relation enfant dans la relation parente est facile à garder et permet de préserver et évite pas mal de casse justement dans les ways membres.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>- possibilité d'inclure un membre de rôle "label" pour positionner un noeud où sera affiché l'un des libellés (*name:*=*), pas forcément sur une des îles ou ilots, mais ce n'est généralement pas nécessaire sauf si un rendu cherche à cadrer par défaut les libellés uniquement sur la surface minuscule et très fragmentée des îles et donc ne rien afficher du tout, puisque le label sera mieux dans l'espace maritime qui les sépare.</div></div></div></blockquote><div><br></div></span><div>Le role label n'est pas utiliser par les rendu (pour l'instant) et ça pose le problème de ce que l'on met comme tag sur le node qui sert de label. si on remet la même chose que sur la relation alors on a un "objet" qui existe 2 fois dans osm. <br></div></div></div></div></blockquote><div><br></div><div>Il est bien utilisé mais pas par tous. Ce rôle est documenté depuis longtemps. Ce noeud membre n'a pas besoin d'être lui-même nommé (les noms dans la relation parente suffisent à indiquer, le label indique une position appropriée; il n'est pas souvent utilisé, sauf justement pour des surfaces incluant des concavités et grands espaces exclus comme c'est le cas ici. Si on ne le met pas, les rendus vont tenter de placer le label n'importe où (sur un centroide, et pas forcément au meilleur endroit, et on a des exemples comme certaines communes françaises très fortement concaves dont le centroïde tombe dans une autre commune ce qui produit un placement faux).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div><div>Pour nommer chaque ile ou ilot, on peut le faire sur le way de la bordure côtière si c'est un way fermé, mais tout découpage demandera de créer un multipolygone contenant les ways côtiers et il est plus approprié alors de nommer ce multipolygone, qui à le transformer en "type=boundary"+"boundary=natu<wbr>ral"+"natural=island" pour y inclure aussi un découpage de l'île en "subareas" et un noeud label ou place. à une position relativement centrale de l'île.</div></div></div></blockquote><div> </div></span><div>Pourquoi toujours ces type=boundary type=multipolygon convient très bien et pourquoi changer place=island en natural=island.</div><div>Le noeud en plus de la relation fait que l'on a l’île en double dans osm.<br></div></div></div></div></blockquote><div><br></div><div>Non. Le "label" ne sert PAS à donner les noms il sert juste à positionner. On peut lui donner un nom mais il ne sera pas utilisé, les noms de la relation suffisent.</div><div>Non encore: on ne peut mettre aucune relation ni aucun noeud dans un multipolygone qui ne convient donc pas du tout.</div><div>Un boundary convient d'autant plus à un archipel qu'on y a aussi un attribut place=archipelago. Mais évidemment ce n'est pas une frontière adminsitrative mais ce n'est pas non plus nécessairement un boundary=administrative (avec admin_level=* et/ou admin_type=*)</div><div><br></div><div>Regarde un peu la liste des autres valeurs de boundary=*. Les archipels sont bien des frontières naturelles, visibles physiquement sur le terrain (contrairement aux frontières administratives qui sont virtuelles et ne se voient que sur les cartes et même pas par la présence de barrières éventuelles qui ne sont que rarement placées directement dessus mais à côté quand il y en a, parfois assez loin). On a aussi d'autres types de frontières non strictement administratives aussi (zones académiques, zones de santé publique, zones de polices, zones militaires, zones judiciaires, zones franches, zones d'autorités [aéro]portuaires), réserves naturelles, et d'autres qui n'ont rien du tout d'administratif (zones de navigation TMC, zones de distribution postale...)</div><div><br></div><div>Les relations "boundary" sont une extension du type "multipolygon", justement faite pour ajouter d'autres membres interdits dans les multipolygones qui restent réservés à taguer uniquement des surfaces délimitées géométriquement et n'ayant aucune structure interne. Les trois extensions documentées sont justement "admin_centre" (utile uniquement pour les frontières adminsitratives), "label", et "subarea" pour indiquer un sous-découpage ou un rattachement (tous les rattachements ne sont pas nécessairement hiérarchiques: une "subarea" peut déborder de sa relation "boundary=*" parente et on ne peut alors pas les trouver par une recherche géographique.</div></div></div></div>