<br><br><div class="gmail_quote">Le 15 janvier 2013 23:53, Vincent de Chateau-Thierry <span dir="ltr"><<a href="mailto:vdct@laposte.net" target="_blank">vdct@laposte.net</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Le 15/01/2013 23:35, Philippe Verdy a écrit :<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Petite idée : ce serait nettement plus pratique de donner les ids des<br>
deux ways qui se coupent à ces coordonnées (les as-tu encore dans ton<br>
outil ou bien c'est perdu par la transformation OSM vers OpenGIS ?).<br>
</blockquote>
<br></div>
Un seul way suffit pour produire le problème indiqué</blockquote><div> (oui effectivement mais la mention de 'self-intersection concernait les tests sur les polygones de relations, et le plus souvent ces cas se produisent entre deux ways d'une même relation, souvent par des modifs faites sur d'autres relations sans vérifier les dépendances)</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Mais surtout, les coordonnées remontées par Postgis (OpenGIS, kesako ?) ne sont pas forcément sur le(s) way(s) en question, mais "sur ou à proximité de" sans plus de précision.</blockquote>

<div><br></div><div>"à proximité" ? Le Log parle de "self-intersection" donc la notion de "self" implique qu'un objet est bien référencé quelque part pour faire une intersection avec lui-même. C'est cet objet qu'il faut identifier (que ce soit une relation à cause de l'iintersection entre deux de ses chemins membres, ou un seul chemin qui se recoupe lui-même.</div>

<div><br></div><div>Les auto-intersections ne sont pas toujours faciles à repérer parfois cela peut être pour seulement quelques centimètres à cause de la précision de la vue dans l'éditeur, mais cela peut venir d'un oubli de fusionner correctement deux noeuds en un seul (cas assez courant chez les utilisateurs de Potlatch, qui préfèrent sans arrête redessiner des polygones superposés plutôt que de gérer des fusions et travailler sur des relations qui sont presque impossibles à comprendre dans Potlatch et très peu pratiques à éditer avec).</div>

</div>