<html><head><meta http-equiv="Content-Security-Policy" content="script-src 'self'; img-src * cid: data:;"></head><body style="background-color: rgb(255, 255, 255); background-image: initial; line-height: initial;"><div id="response_container_BBPPID" style="outline:none;font-size:initial;font-family:"Calibri","Slate Pro",sans-serif,"sans-serif";color:#1f497d;" contenteditable="false"> <div name="BB10" dir="auto" style="width: 100%; background: rgb(255, 255, 255); padding: initial; font-size: initial; text-align: initial;"> Probablement parce que comme l'explique le Wiki un multipolygon est par défaut une aire (contrairement à boundary qui est une frontière, quelque chose de linéaire) et que si un tag manque au niveau de la relation il va le chercher au niveau des membres (là je suis d'accord avec toi : ce n'est pas normal et pousse à la surinterpretation). Il donne même un exemple en Allemagne ou des mp ont été massivement utilisés au lieu de boundary. Un multipolygon est conçu comme une manière de définir une aire mais en utilisant plusieurs ways au lieu de une.</div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width: 100%; background: rgb(255, 255, 255); padding: initial; font-size: initial; text-align: initial;"><br></div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width: 100%; background: rgb(255, 255, 255); padding: initial; font-size: initial; text-align: initial;">Donc comme le rendu ne reconnaît pas cette manière de tagger un parcelle, il adopte son comportement par défaut qui est "c'est une aire" et "je cherche les tags d'abord dans la relation, sinon dans les membres". Avec une boundary il ne dessine pas d'aire donc le glitche ne se produit pas. Est-ce une magouille ou un " taguer pour le rendu" ? Je ne sais pas trop encore... Si tu rajoute un tag landuse=forest à un mp de type parcel, on devrait logiquement arriver au même résultat et cela ne me paraît pas sémantiquement faux aussi.</div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width: 100%; background: rgb(255, 255, 255); padding: initial; font-size: initial; text-align: initial;"><br></div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width: 100%; background: rgb(255, 255, 255); padding: initial; font-size: initial; text-align: initial;">Résultat un multipolygon avec que des membres highway est donc vu comme un highway. Contrairement à ce que j'ai pu dire je ne pense plus qu'il y ai bug mais reste persuadé qu'il y a une erreur de conception (à savoir la remontée de tags qui pousse à une mauvaise pratique).</div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width: 100%; background: rgb(255, 255, 255); padding: initial; font-size: initial; text-align: initial;"><br></div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width: 100%; background: rgb(255, 255, 255); padding: initial; font-size: initial; text-align: initial;">Cordialement </div> <div name="BB10" dir="auto" style="width: 100%; background: rgb(255, 255, 255); padding: initial; font-size: initial; text-align: initial;"> <br style="display:initial"></div> <div id="blackberry_signature_BBPPID" name="BB10" dir="auto"> <div name="BB10" dir="auto" style="padding: initial; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);">LeTopographeFou</div> </div></div><div id="_original_msg_header_BBPPID"> <table width="100%" style="background-color: white; border-spacing: 0px; display: table; outline: none;" contenteditable="false"> <tbody><tr><td colspan="2" style="padding: initial; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"> <div style="border-right: none; border-bottom: none; border-left: none; border-image: initial; border-top: 1pt solid rgb(181, 196, 223); padding: 3pt 0in 0in; font-family: Tahoma, "BB Alpha Sans", "Slate Pro"; font-size: 10pt;"> <div id="from"><b>De:</b> verdy_p@wanadoo.fr</div><div id="sent"><b>Envoyé:</b> 7 décembre 2016 1:30 AM</div><div id="to"><b>À:</b> talk-fr@openstreetmap.org</div><div id="reply_to"><b>Répondre à:</b> verdy_p@wanadoo.fr; talk-fr@openstreetmap.org</div><div id="subject"><b>Objet:</b> Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières</div></div></td></tr></tbody></table><div style="border-right: none; border-bottom: none; border-left: none; border-image: initial; border-top: 1pt solid rgb(186, 188, 209); display: block; padding: initial; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"></div> <br> </div><!--start of _originalContent --><div name="BB10" dir="auto" style="background-image: initial; line-height: initial; outline: none;" contenteditable="false"><div dir="ltr">Je ne vois pas en quoi ce changement de "multipolygon" en "boundary" devrait avoir un impact sur l'interprétation et la "remontée" des tags des ways membres vers les relations qui les référence.<div><br></div><div>Cela reste un bogue de la conversion OSM en pgsql, qui ne tient pas compte des critères nécessaires (tags identiques dans tous les ways membres ayant un rôle "outer" ou vide, ce qui n'était pas le cas des "name=*").</div><div><br></div><div>En revanche remonter les "highway=*" vers la relation (peu importe que ce soit une "boundary" ou un "multipolygon") est problématique, dans les faits tous les "highway=*" sont linéaires (exceptions faite des "highway=pedestrian" et à condition qu'ils soient tagués avec "area=yes", ce qui n'était pas du tout le cas ici, car par défaut les "highway=*" sont soit linéaires, soit des noeuds isolés pour des passages piétons, priorités, stops...).</div><div><br></div><div>Il reste donc bien une anomalie de osm2pgsql ici, et je ne vois pas pourquoi osm2pgsql devrait se demander ce que sont ces "multipolygon", d'autant plus qu'ils ont déjà des tags nécessaires, qu'ils soient tagués comme "multipolygon", boundary", ou encore comme "landuse", "natural" (qui n'ont eux rien non plus à voir avec les "highway=*")</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">Le 6 décembre 2016 à 23:38, LeTopographeFou <span dir="ltr"><<a href="mailto:letopographefou@gmail.com">letopographefou@gmail.com</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<p><span class="">
</span></p><blockquote type="cite">J'ai basculé ces "type=multipolygon" en
"type=boundary"... et tout rentre dans l'ordre comme je l'avais
imaginé dans mon précédent message qui n'a visiblement pas été
lu ;)</blockquote>
Bonjour et merveilleux !! Je n'avais pas compris le sous-entendu.
Merci.<br>
<p></p>
<p>
</p><blockquote type="cite"><span class="">En terme de logique de tagging je verrai
plutôt quelque chose comme:<br>
type=boundary (il s'agit d'une frontière qui découpe un ensemble
plus grand)<br>
boundary=forest (frontière forestière)<br>
forest=section (il s'agit d'une section)<br>
<br></span>
Mais ça mérite discussion sur le wiki plutôt que d'y aller à
l'arrache... [...]<br>
</blockquote>
Tout là fait d'accord (sans rentrer dans la discussion ici :
j'aime bien ta proposition, elle est plus proche de l'existant et
donc plus naturelle que la proposition Section).<p></p>
<p>Pour info il se trouve que j'ai eu un échange de mail avec
l'auteur de la proposition Section cet été (à propos d'un
cimetière que je visitais/cartographiais à l'époque) et il m'a dit
qu'il n'avait pas eu le courage pour animer sa proposition
jusqu'au bout. Il m'a encouragé à la retravailler voir à faire une
contre-proposition, car il reste persuadé du besoin initial
(parcelles forestières, sections dans un cimetière...).<br>
</p>
<p><span class="">
</span></p><blockquote type="cite"><br>
<div>Mais ça mérite discussion sur le wiki plutôt que d'y aller
à l'arrache... surtout que l'import des données est pas génial
non plus car les données d'origine ne sont pas forcément bien
calées...<br>
<br>
</div>
Exemple: <a href="http://umap.openstreetmap.fr/en/map/test-rendu-osmfr_99740#18/48.53494/1.97682">http://umap.openstreetmap.fr/<wbr>en/map/test-rendu-osmfr_99740#<wbr>18/48.53494/1.97682</a></blockquote>
Alors là c'est drôle car pendant que tu changeais le type de
relation je recalais exactement l'endroit que tu cite (ce qui m'a
valu de résoudre quelques conflits d'éditions quand j'ai voulu
envoyer sur le serveur). Donc en me basant sur le cadastre j'ai
regroupé hier ce qui devait l'être dans la zone (je n'ai pas
déplacé les frontières administratives mais les layons, chemins et
bordures de forêt. Il reste encore une bonne partie du périmètre à
recaler) et j'en avais profité pour ajouter un gros morceau de
forêt manquant côté Yvelines (<a href="http://www.openstreetmap.org/relation/6770020">http://www.openstreetmap.org/<wbr>relation/6770020</a>).<p></p>
<p>Bref il reste du boulot mais problème de rendu de parcelle réglé,
je déploierai la solution sur les forêts alentours qui ont le même
soucis, merci !<br>
</p>
<p>Cordialement<span class="HOEnZb"><font color="#888888"><br>
</font></span></p><span class="HOEnZb"><font color="#888888">
</font></span><pre class="m_-3129302572214002174moz-signature">LeTopographeFou</pre><div><div class="h5">
<div class="m_-3129302572214002174moz-cite-prefix">Le 05/12/2016 à 23:18, Christian Quest
a écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>J'ai basculé ces "type=multipolygon" en
"type=boundary"... et tout rentre dans l'ordre comme
je l'avais imaginé dans mon précédent message qui n'a
visiblement pas été lu ;)<br>
<br>
</div>
Ces sections forestières sont bien des frontières et ça
évite à osm2pgsql de chercher à savoir par une
euristique imparfaite ce que sont ces multipolygones
mystérieux...<br>
<br>
</div>
En terme de logique de tagging je verrai plutôt quelque
chose comme:<br>
</div>
type=boundary (il s'agit d'une frontière qui découpe un
ensemble plus grand)<br>
</div>
boundary=forest (frontière forestière)<br>
</div>
<div>forest=section (il s'agit d'une section)<br>
<br>
</div>
<div>Mais ça mérite discussion sur le wiki plutôt que d'y aller
à l'arrache... surtout que l'import des données est pas génial
non plus car les données d'origine ne sont pas forcément bien
calées...<br>
<br>
</div>
<div>Exemple: <a href="http://umap.openstreetmap.fr/en/map/test-rendu-osmfr_99740#18/48.53494/1.97682">http://umap.openstreetmap.fr/<wbr>en/map/test-rendu-osmfr_99740#<wbr>18/48.53494/1.97682</a><br>
<br>
</div>
<div>Les tuiles sont en train de se remettre à jour... un peu de
patience.<br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">Le 5 décembre 2016 à 22:17, <span dir="ltr"><<a href="mailto:osm.sanspourriel@spamgourmet.com">osm.sanspourriel@spamgourmet.<wbr>com</a>></span>
a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<p>Le 05/12/2016 à 21:57, LeTopographeFou - <a class="m_-3129302572214002174m_1589418262703252056moz-txt-link-abbreviated" href="mailto:letopographefou@gmail.com">letopographefou@gmail.com</a> a
écrit :<br>
</p>
<blockquote type="cite">
<p>Bonsoir à tous,</p>
<p>A vrai dire je croyais que le moteur ne dessinait
que les objets issus d'une requête (donc les objets
connus) et pas tous les objets. Visiblement ce n'est
pas le cas.</p>
</blockquote>
Jusqu'à peu c'était le cas. J'ai vu que maintenant les
"noms" des transformateurs apparaissent sur la carte.<br>
Assez absurde pour une carte générique.<br>
<br>
<blockquote type="cite">
<p>Entre nous, ce système de "je fais remonter les
valeurs communes" me parait biaisé et n'incite pas à
correctement tagger. Je préfère 100x plus un moteur
de rendu stricte et exigent qui pousse à bien faire
mais dessine avec ce qu'on lui donne plutôt qu'un
qui interprète les données avec des attributs qui
n'existent pas et dessine des relations qu'il ne
connait pas (avec 50% de risque de se planter). Si
le moteur ne connait pas une relation, il devrait
l'ignorer. Si il lui manque une propriété, il
devrait pouvoir faire sans. Dixit un gars qui n'a
pas sué dans le développement de ces beaux outils
:-) .<br>
</p>
</blockquote>
Si c'est une info commune, pourquoi pas ? Je dis
bien commune c'est à dire identique dans tous les membres.<br>
Sinon c'est éventuellement un candidat pour un outil
d'assurance qualité (que des noms identiques ou pas de
noms : peut-être que les sans noms devraient avoir le même
nom, ça peut avoir du sens pour des réseaux, des trajets
tels que des pistes cyclables sans nom connectés à
d'autres pistes cyclables ayant un nom... ou une
référence).<br>
<br>
Jean-Yvon<br>
</div>
<br>
______________________________<wbr>_________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr">https://lists.openstreetmap.or<wbr>g/listinfo/talk-fr</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div class="m_-3129302572214002174gmail_signature">
<div dir="ltr">Christian Quest - OpenStreetMap France</div>
</div>
</div>
<br>
<fieldset class="m_-3129302572214002174mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
Talk-fr mailing list
<a class="m_-3129302572214002174moz-txt-link-abbreviated" href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a>
<a class="m_-3129302572214002174moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-fr">https://lists.openstreetmap.<wbr>org/listinfo/talk-fr</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>______________________________<wbr>_________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr">https://lists.openstreetmap.<wbr>org/listinfo/talk-fr</a><br>
<br></blockquote></div><br></div>
<!--end of _originalContent --></div></body></html>