<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Le 4 mars 2014 21:35, Vincent Pottier <span dir="ltr"><<a href="mailto:vpottier@gmail.com" target="_blank">vpottier@gmail.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 class="">Le 03/03/2014 11:45, Pieren a écrit :<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2014-03-03 9:21 GMT+01:00 Jean-Baptiste Holcroft <<a href="mailto:jb.holcroft@gmail.com" target="_blank">jb.holcroft@gmail.com</a>>:<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Pour les places : les logiciels de routage ne savent pas traverser des<br>
surfaces. Donc il faut faire une voie qui la traverse pour que le logiciel<br>
s'y retrouve.<br>
</blockquote>
Non. Si la modélisation est correcte, c'est aux logiciels de s'adapter<br>
aux données et non l'inverse. C'est du bricolage.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dans tous les cas, OSM n'est pas encore très bon pour gérer les places.<br>
</blockquote>
Ca n'est pas un problème d' "OSM" mais un problème des logiciels<br>
d'analyse et ceux de routage qui ont du mal, techniquement, à traiter<br>
facilement ce cas de figure. Pour osmi, on peut ignorer<br>
l'avertissement. Pour les routeurs, il faut faire pression auprès<br>
d'eux pour qu'ils supportent ce cas (messages, tickets). En corrigeant<br>
une place, le problème est de toute façon encore là pour toutes les<br>
autres.<br>
</div></blockquote>
Sur le principe, je suis d'accord ; c'est au logiciel de s'adapter.<br>
<br>
Mais je ne me sens pas de taille à faire du lobbying auprès de Garmin pour qu'ils intègrent la logique OSM.<br>
Je préfèrerai dans un premier temps que Garmin nous aide à encoder les adresses correctement, quitte à supporter encore quelques temps les "artifices" concernant les places : filaire + surfacique.<br>
<br>
Et dans cette problématique on est à la limite de deux modèles : filaire et surfacique.<div class=""><br></div></blockquote><div><br></div><div><br></div><div>Ce n'est pas à Garmin de faire ça, Garmin n'a à ma connaissance rien fait en direction d'OSM.</div>

<div>C'est au développeur des outils de conversion d'ajouter un préprocessing.</div><div><br></div><div>D'ailleurs, la solution réside sûrement là: un outil de préprocessing qui ajoute les linéaires virtuels pour que la construction des graphes de navigation fonctionnent en l'état. C'est sûrement le plus simple et le plus universel car attendre que chaque routeur fasse se travail me semble illusoire vu que le problème n'est pas nouveau.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Concernant les escaliers, il me semble qu'un chemin piéton doit y accéder<br>
pour ne plus avoir ton erreur.<br>
</blockquote>
Mouais. J'ai encore des doutes sur la capacité à faire du routage<br>
piéton. Les escaliers sont un problème parmi d'autres.<br>
</blockquote></div>
J'arrive de deux jours de rando.<br>
Garmin (Dakota 20) fait du très bon routage piéton, même avec des escaliers, dans Arbois, quand c'est bien cartographié (Merci Damouns ;-).<br>
Ok, je n'ai pas testé le routage piéton sur du surfacique.<br></blockquote><div><br></div><div>Yapuka ! ;) </div></div><div><br></div>-- <br><div dir="ltr">Christian Quest - OpenStreetMap France<div><a href="http://openstreetmap.fr/sotmfr" target="_blank">Conférence "State Of The Map" France du 4 au 6 avril à Paris</a></div>

</div>
</div></div>