<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Bonsoir à tous,</p>
<p>Merci pour vos réponses. A l'heure actuelle le rendu est pire
encore car j'ai (à priori) terminé de réparer les mp mal taggés.
Et il apparait que si la précédente carte était plutôt bien
dessinée, c'est plus par "chance" que par la qualité des mp qui
existaient. Maintenant avec des parcelles "propres" (fermées,
etc.) les bugs ressortent et... c'est catastrophique.<br>
</p>
<p>Je partage globalement ton analyse Philippe (nom sélectionné
arbitraire et valeur par défaut supposément erronées de area). Au
delà du fait que se soient des relations non reconnues, je pense
qu'il y a un comportement par défaut bizarre du rendu (ou de la
moulinette qui le nourrit). Je ferai remonter les bugs à Mapnik à
l'occasion (que mes dernières modifs se stabilisent).
</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>
<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 :-) .</p>
<p>Cordialement,<br>
</p>
<pre class="moz-signature" cols="72">LeTopographeFou</pre>
<div class="moz-cite-prefix">Le 03/12/2016 à 22:17, Philippe Verdy a
écrit :<br>
</div>
<blockquote
cite="mid:CAGa7JC3PtRscxNXvMWqEgQuvvb=TLHUrxeO7Vmoamcpyzsu5Sg@mail.gmail.com"
type="cite">
<div dir="ltr">Ceci dit si je prend l'exemple du triangle formé
entre les carrefours de la Réserve, des Grès et de Madame par
les trois routes forestières de la Fresnaye, des Grès et de
Madame, il y a bien un attribut highway commun, mais aucun nom
commun.
<div><br>
</div>
<div>L'attribut highway est "remonté" au niveau de la relation
mais le nom "Route Madame" (pioché au hasard entre les 3
possibles) n'a pas à l'être car il n'est pas commun: c'est
bien un bogue de la conversion OSM-GIS.</div>
<div><br>
</div>
<div>D'autre part, remonter l'attribut highway **linéaire** (par
défaut) à la relation ne devrait pas avoir lieu non plus (les
3 chemins sont des "highway=*" qui ne sont pas tagués avec
"area=yes" donc à interpréter comme "area=no" par défaut,
conformément à la documentation de "highway=*"). Donc là
encore un bogue de la conversion OSM-GIS.</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">Le 3 décembre 2016 à 22:05, Philippe
Verdy <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:verdy_p@wanadoo.fr" target="_blank">verdy_p@wanadoo.fr</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">Le rendu ne fait pas cette interprétation
tout seul: il ne le fait que si tous les chemins membres
d'une même relation partagent exactement le même attribut,
et dans ce cas il rapporte cet attribut à la relation, et
seulement si cette relation décrit une surface fermée (en
un ou plusieurs anneaux s'il y a des enclaves). Certains
attributs sont exclus de ce traitement (dont highway qui
est la plupart du temps uniquement linéaire, à moins qu'il
y ait aussi sur les chemins un area=yes).
<div><br>
</div>
<div>Ces cas de transformation sont détectés dans la
validation de JOSM qui indique de taguer la relation et
non les chemins membres.</div>
<div><br>
<div>Ensuite si la relation n'est pas exclue comme
surface par ses attributs (dont area=no), elle peut
être rendue comme une surface</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span class="">Le 3 décembre 2016
à 18:52, JB <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:jbosm@mailoo.org" target="_blank">jbosm@mailoo.org</a>></span>
a écrit :<br>
</span>
<div>
<div class="h5">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Oui, les
multipolygones, c'est élégant d'un point de vue
intellectuel et parfois, c'est absolument
impraticable dans la réalité. Et impossible à
maintenir. Pour 3 nœuds et trois ways, pourquoi
inventer un MP plutôt qu'utiliser un chemin
fermé simple ? <br>
Sinon, je pense (à confirmer) que le rendu brun
avec le nom de rue au milieu, c'est Mapnik qui
considère que le MP représente un chemin
(highway=*) : comme il ne reconnait pas le type
de multipolygone utilisé (forest=section + ref),
il prend le premier way, voit un highway=*, et
considère que la surface est un highway avec un
multipolygone mal conditionné. Et hop. Foireux
pour foireux, tant qu'à faire…<br>
JB.
<div>
<div class="m_-6092734059915255035h5"><br>
<br>
<div
class="m_-6092734059915255035m_-268440000641672065moz-cite-prefix">Le
03/12/2016 à 18:29, LeTopographeFou a
écrit :<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div class="m_-6092734059915255035h5">
<p>Bonjour,</p>
<p>Suite à mon sujet sur les intersections
en forêt j'ai essayé de savoir pourquoi
certaines parcelles et chemins en forêt
de Saint-Arnoult (mais pas que...)
génèrent des soucis de dessin alors
qu'elles paraissent toutes homogènes en
terme de tags et qu'elles sont toutes
fermées. Marron, gris, blanc,
transparent... ce n'est pas homogène !<br>
</p>
<p>A noter que je suppose que les
parcelles ne sont à priori pas dessinées
(sinon on verrait son numéro, il n'y
aurait pas de statut "proposition", et
le rendu serait plus homogène que cela).</p>
<p>Voici mes constatations :</p>
<ul>
<li>Rendu <a moz-do-not-send="true"
href="http://www.openstreetmap.org/#map=14/48.5553/1.9502"
target="_blank">http://www.openstreetmap.org/#<wbr>map=14/48.5553/1.9502</a></li>
<ul>
<li><i>Route de Madame</i> et <i>Route
de la Lieue</i> ne sont pas écrits
le long du chemin mais au milieu de
parcelles à l'horizontal (à partir
du niveau de zoom 15). En consultant
les ways en question, rien à
signaler. Une idée ?<br>
</li>
<li>Il y a des zones marrons qui
correspondent bizarrement aux
délimitations de certaines
parcelles. Sauf que ces parcelles
n'ont rien de bizarre quand on
regarde les tags (elles sont bien
fermées et toutes ne sont pas
rendues de la même manière alors
qu'elles ont des tags identiques).
Exemple : <a moz-do-not-send="true"
href="http://www.openstreetmap.org/relation/1866710" target="_blank">http://www.openstreetmap.org/r<wbr>elation/1866710</a>
Une idée ?</li>
<li>Là on a carrément une parcelle
grise : <a moz-do-not-send="true"
href="http://www.openstreetmap.org/relation/1853819"
target="_blank">http://www.openstreetmap.org/r<wbr>elation/1853819</a><br>
</li>
</ul>
<li>Rendu <a moz-do-not-send="true"
href="http://tile.openstreetmap.fr"
target="_blank">http://tile.openstreetmap.fr</a>
(je n'ai pas trouvé comment récupérer
un lien vers la zone consultée...)</li>
<ul>
<li>Beaucoup plus de chemins sont
tracés avec les noms au milieu des
parcelles et non le long du chemin.
En fait c'est comme ci le rendu
dessinait les parcelles et prenait
le nom du dernier élément de la
relation pour lui donner un nom de
relation. Une idée ?</li>
<li>Il y a moins de parcelles
bizarrement dessinées mais il y en a
qu'en même (et on notera que ce ne
sont pas les mêmes que sur OSM.org).
Exemple avec celle sous "Route de la
jumelle" qui apparait plus claire<br>
</li>
</ul>
</ul>
Résultat : c'est moche et ca fait penser
zone en construction... Je me demande si
la manière avec laquelle les parcelles ont
été cartographiées ne perturbe pas le
moteur de rendu. Ou alors c'est un bug
dans le moteur de rendu ?<br>
<br>
A vous lire,<br>
<br>
Cordialement,<br>
<pre class="m_-6092734059915255035m_-268440000641672065moz-signature" cols="72">--
LeTopographeFou</pre>
<br>
<fieldset
class="m_-6092734059915255035m_-268440000641672065mimeAttachmentHeader"></fieldset>
<br>
</div>
</div>
<pre>______________________________<wbr>_________________
Talk-fr mailing list
<a moz-do-not-send="true" class="m_-6092734059915255035m_-268440000641672065moz-txt-link-abbreviated" href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a>
<a moz-do-not-send="true" class="m_-6092734059915255035m_-268440000641672065moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">https://lists.openstreetmap.or<wbr>g/listinfo/talk-fr</a>
</pre>
</blockquote>
</div>
______________________________<wbr>_________________
Talk-fr mailing list
<a moz-do-not-send="true" href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a>
<a moz-do-not-send="true" href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.or<wbr>g/listinfo/talk-fr</a>
</blockquote></div></div></div>
</div>
</blockquote></div>
</div>
<fieldset class="mimeAttachmentHeader"></fieldset>
<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>
</body></html>