[OSM-talk-fr] routage surfacique

[lenny.libre]

Le 18/06/2019 à 20:33, marc marc a écrit :
> j'ai bien vu cela (même si n'est pas compréhensible sur la capture)
> mais aucun des 4 itinéraires n’atteint l'itinéraire réel
> alors que ce sont 2 points de osm de la place.
> donc même ce site a du limiter le nuage de way représentant la place.
> alors imagine les dégâts si tu routes entre Paris et Monpellier
> en surfacique.
A mon âge, je ne suis pas prêt de faire Paris Montpellier à pied (même 
quand j'étais jeune, je ne le faisais pas).
> Le 18/06/2019 à 20:10, marc marc - marc_marc_irc at hotmail.com a écrit :
>>> Le 18.06.19 à 18:48, lenny.libre a écrit :
>>>>> donc pour ma part, les routes donnant sur une place
>>>>> se rejoignent en un point + souvent place=square
>>>>> c'est une représentation imparfaite, mais c'est
>>>>> à l'heure actuelle sans doute le meilleur compromis
Pour l'anomalie que j'avais signalée, comme le dit Phyks (2 accès sur la 
place à quoi bon tracer un chemin fictif qui n'est pas nécessaire aux 
calculateurs)
>>>> Pourquoi les outils évolueraient-ils, si on leur mâche le boulot ? 
>>> les évolutions des tags dans osm se font généralement
>>> - soit par des tags supplémentaires (highway puis maxspeed
>>> puis lanes puis turn:lanes par ex)
>>> - soit par un changement de tags (par ex power=sub_Station
>>> divisé en 2 power=substation et power=generator).
>>> Si on suit cette logique, c'est area:highway qui devrait
>>> être utilisé pour une transitions sans dégradation.
>>>
>>> casser en disant "yaka faire du routage surfacique",
>>> c'est méconnaître ce que cela implique techniquement :
Tu caricatures ce que je dis, j'ai bien précisé "je sais, je ne devrais 
pas en parler ... , je serais bien incapable de faire ces outils" donc 
je ne suis peut-être pas technique, mais je remarque simplement qu'il y 
a des outils qui font sans ces "chemins"
>>> il y a un gros travail de prétraitement à faire.
>>> je ne retrouve plus hélas l'article qui était publiée sur osmweekly
>>> mais la moindre place avec qlq rues est transformée en un nuage
>>> de way qui connectent tous les paires de points de la surface.
>>> en passant, cela veux dire aussi qu'une place surfacique
>>> avec 8 nœuds consomme 9x l'espace disque et mémoire
>>> comparé à sa version linéaire et ce n'est pas en un claquement
>>> de doigt qu'on augmente la puissance d'un serveur gratuit.
>>>
>>> je pense que les outils continueront de s'améliorer simplement
>>> à la demande de leur utilisateur, en fonction des ressources dispo.
>>>
>>>> alors quehttps://moodwalkr.com/@montpellier/itineraire
>>>> peut calculer un itinéraire
>>> https://framapic.org/nEjSW3hpuqm3/7c38wQyfPHD1.png
>>> j'espère que tu partageras mon avis que l'amélioration par
>>> rapport à une représentation filaire ne saute pas aux yeux
>>> alors que le point de départ et d'arrivée sont accessible
>>> en ligne droite sans obstacle.

Mais non, je ne partages pas ton avis, pas plus droit avec OSRM,

>>> PS: je n'ai pas chercher à mettre l'outil en difficulté,
>>> j'ai juste demandé la place et une adresse de la place.

Peut-être parce que la partie pour aller à une adresse précise sur une 
place est améliorable, (alors qu'il permet de faire des recherches 
d'itinéraire par thèmes.)

Tout produit est améliorable (tout comme mes contributions), je vais 
donc continuer à faire comme d'hab, je ne créerais pas de chemins 
virtuels et je n’effacerais pas ceux des copains.

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20190619/cfeb9ca3/attachment.htm>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: lbgeneeakjfegiah.png
Type: image/png
Taille: 50540 octets
Desc: non disponible
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20190619/cfeb9ca3/attachment.png>