[OSM-talk-fr] Multipolygones et sites

[Philippe Verdy]

Le 20 décembre 2017 à 06:49, Jérôme Amagat <jerome.amagat at gmail.com> a
écrit :

>
>
> Le 20 décembre 2017 à 00:23, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :
>
>> 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)
>>
>> 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 :
>>
>
> 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=*
>
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.

>
>> - continuer à mettre tous les ways "outer"/inner" nécessaires pour toutes
>> les îles et îlots.
>> - 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.
>>
>
> 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é.
>

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.


>
>
>> - 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.
>>
>
> 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.
>

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).


>> 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=natural"+"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.
>>
>
> Pourquoi toujours ces type=boundary type=multipolygon convient très bien
> et pourquoi changer place=island en natural=island.
> Le noeud en plus de la relation fait que l'on a l’île en double dans osm.
>

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.
Non encore: on ne peut mettre aucune relation ni aucun noeud dans un
multipolygone qui ne convient donc pas du tout.
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=*)

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...)

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.
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20171220/5b2dfd14/attachment.htm>