Le 20/12/2017 à 00:23, Philippe Verdy - [email protected] 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)
Si tel n'était pas le cas, je n'aurais pas écrit le message.
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 :
- 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.
- 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.
/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=*/
Pas un nouveau tag, Philippe tu joues sur les mots : c'est une nouvelle
valeur non prévue par le Wiki
(https://wiki.openstreetmap.org/wiki/FR:Fronti%C3%A8res).
Que pensent les autres de l'introduction d'un boundary=natural ?
/Tu peux avoir des ways qui appartiennent à plusieurs multipolygon. Tu
gardes le multipolygon des pierres noires tel quel et les way qui sont
dans ce multipolygone tu les mets aussi dans le multipolygone de l'archipel/
Mais tu perds la notion d'inclusion : tu va voir 4 chemins fermés et non
une subarea comportant les Pierres Noires.
C'est ce que je disais : /L'autre solution c'est de mettre tous les
polygones des Pierres Noires dans le multipolygon, mais on perd le
regroupement logique des Pierres Noires (qui n'ont pas à ma connaissance
de nom individuel)./
Je crois que c'est l'intérêt de la méthode proposée par Philippe.
Et ce que tu proposes c'est ce que je veux éviter : perdre cette notion
d'inclusion.
Le 19 décembre 2017 à 20:52, <[email protected]
<mailto:[email protected]>> a écrit :
J'ai fait quelques correctifs sur les Glénan mais ça reste
problématique :
- l'archipel <http://www.openstreetmap.org/relation/332410> est
décrit comme un multi-polygone
- mais avec des nœuds (que l'ai remplacé par des chemins, bien)
- sauf que certaines zones comme les Les Pierres Noires (7824629)
<http://www.openstreetmap.org/relation/7824629> sont à leur tour
un multipolygon.
Ne doit-on pas remplacer le type multipolygon par site ?
L'autre solution c'est de mettre tous les polygones des Pierres
Noires dans le multipolygon, mais on perd le regroupement logique
des Pierres Noires (qui n'ont pas à ma connaissance de nom
individuel).
Y a-t-il une règle ? Une raison de choisir l'un ou l'autre ?
Indice : il n'y a pas de lagon, Le Loc'h
<http://www.openstreetmap.org/way/256301139> c'est de l'eau douce
(et sinon on pourrait cartographier l'ïle du Loc'h comme
multi-polygone.
Question subsidiaire : les pierres sont des place=rock. Bien, mais
doit -on factoriser au niveau de la relation ? Je dirais non
(c'est chaque pierre et non l'ensemble qui est un roc).
Mes modifs : http://www.openstreetmap.org/changeset/54768293
<http://www.openstreetmap.org/changeset/54768293>
_______________________________________________
Talk-fr mailing list
[email protected] <mailto:[email protected]>
https://lists.openstreetmap.org/listinfo/talk-fr
<https://lists.openstreetmap.org/listinfo/talk-fr>
_______________________________________________
Talk-fr mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr
