<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="transparent">
<p>Le 20/12/2017 à 00:23, Philippe Verdy - <a class="moz-txt-link-abbreviated" href="mailto:verdy_p@wanadoo.fr">verdy_p@wanadoo.fr</a> a
écrit :<br>
</p>
<blockquote type="cite"
cite="mid:CAGa7JC15Tc+YpqnsCzxA+2+iuoTuVyyaj5iKTXdoLaSC_gW4RA@mail.gmail.com">
<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>
</blockquote>
Si tel n'était pas le cas, je n'aurais pas écrit le message.<br>
<br>
<blockquote type="cite"
cite="mid:CAGa7JC15Tc+YpqnsCzxA+2+iuoTuVyyaj5iKTXdoLaSC_gW4RA@mail.gmail.com">
<div dir="ltr">
<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><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>- 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>
<i>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=*</i><br>
<br>
Pas un nouveau tag, Philippe tu joues sur les mots : c'est une
nouvelle valeur non prévue par le Wiki (<a moz-do-not-send="true"
href="https://wiki.openstreetmap.org/wiki/FR:Fronti%C3%A8res">https://wiki.openstreetmap.org/wiki/FR:Fronti%C3%A8res</a>).<br>
Que pensent les autres de l'introduction d'un boundary=natural ?<br>
<br>
<br>
<i>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</i><br>
Mais tu perds la notion d'inclusion : tu va voir 4 chemins fermés et
non une subarea comportant les Pierres Noires.<br>
C'est ce que je disais : <i>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).</i><br>
Je crois que c'est l'intérêt de la méthode proposée par Philippe.<br>
Et ce que tu proposes c'est ce que je veux éviter : perdre cette
notion d'inclusion.
<div>
<div><br>
</div>
</div>
<blockquote type="cite"
cite="mid:CAGa7JC15Tc+YpqnsCzxA+2+iuoTuVyyaj5iKTXdoLaSC_gW4RA@mail.gmail.com">
<div class="gmail_extra"><br>
<div class="gmail_quote">Le 19 décembre 2017 à 20:52, <span
dir="ltr"><<a
href="mailto:osm.sanspourriel@spamgourmet.com"
target="_blank" moz-do-not-send="true">osm.sanspourriel@spamgourmet.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 text="#000000" bgcolor="transparent">
<p>J'ai fait quelques correctifs sur les Glénan mais ça
reste problématique :</p>
<p>- l'<a
href="http://www.openstreetmap.org/relation/332410"
target="_blank" moz-do-not-send="true">archipel</a>
est décrit comme un multi-polygone<br>
</p>
<p>- mais avec des nœuds (que l'ai remplacé par des
chemins, bien)</p>
<p>- sauf que certaines zones comme les <a title=""
href="http://www.openstreetmap.org/relation/7824629"
target="_blank" moz-do-not-send="true">Les Pierres
Noires (7824629)</a> sont à leur tour un multipolygon.</p>
<p><br>
</p>
<p>Ne doit-on pas remplacer le type multipolygon par site
?</p>
<p>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).<br>
<br>
Y a-t-il une règle ? Une raison de choisir l'un ou
l'autre ? Indice : il n'y a pas de lagon, <a
href="http://www.openstreetmap.org/way/256301139"
target="_blank" moz-do-not-send="true">Le Loc'h</a>
c'est de l'eau douce (et sinon on pourrait cartographier
l'ïle du Loc'h comme multi-polygone.<br>
</p>
<p>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).<br>
</p>
<p>Mes modifs : <a
href="http://www.openstreetmap.org/changeset/54768293"
target="_blank" moz-do-not-send="true">http://www.openstreetmap.org/<wbr>changeset/54768293</a><br>
</p>
</div>
<br>
______________________________<wbr>_________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org"
moz-do-not-send="true">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.openstreetmap.<wbr>org/listinfo/talk-fr</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Talk-fr mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-fr">https://lists.openstreetmap.org/listinfo/talk-fr</a>
</pre>
</blockquote>
<br>
</body>
</html>