[OSM-talk-fr] routage surfacique

Antoine Riche antoine.riche at zaclys.net
Mar 25 Juin 14:17:26 UTC 2019


Bonjour,
Je raccroche cette échange un peu tardivement...

Le wiki sur la clef area:highway inclut une section 
<https://wiki.openstreetmap.org/wiki/Key:area:highway#Differentiation_area:highway_vs._area.3Dyes_on_a_highway> 
qui dit explicitement que area:highway n'est *pas* fait pour le routing, 
alors que la combinaison de highway=* et area=yes peut être utilisée 
pour le routing surfacique.

Je suis d'accord aussi sur une approche pragmatique : conserver des 
éléments linéaires qui permettent aux principaux outils de calcul 
d'itinéraires de fonctionner, sans pour autant tracer toutes les routes 
possibles. Et permettre aux logiciels qui font du routing surfacique de 
produire des itinéraires plus réalistes. Il faut pour cela connecter les 
routes linéaires aux places surfaciques en partageant un node.

C'est le moment de vous présenter la page de recommandations pour le 
routage piéton 
<https://wiki.openstreetmap.org/wiki/FR:Recommandations_pour_le_routage_piéton>, 
qui inclut une grosse section sur le routage surfacique, prend en compte 
le indoor comme le outdoor, et inclut une dizaine de schémas. Cette page 
a été présentée lors du SOTM à Montpellier, la présentation 
correspondante est téléchargeable avec ce lien 
<https://nextcloud.openstreetmap.fr/index.php/s/xzAqyacaJWsnXNZ/download?path=%2F&files=SOTMFR2019-40-routing-pieton-guider-les-voyageurs-dans-et-autour-des-gares-(Riche-Defarge-Durupt).pdf>.

Je suis preneur de vos retours sur cette page.

Antoine.


Le 19/06/2019 à 17:09, Jérôme Seigneuret a écrit :
> Pour l'exemple de Montpellier, les tracés ont été supprimés par mes 
> soins puis rajouté par les services de la métropole qui utilise des 
> extractions pour ses propres outils de routing (non OSM compliant) et 
> qui existe historiquement. Donc les linéaires correspondent à une 
> nécessité de leurs outils pour le routing et je pense pour 
> l'intermodalité (adresse vers adresse). (non compatible avec de 
> l'itinéraire polygonale)
>
> D'où un commentaire dans les tracés.
> C'est pas la seul zone en double (voir la zone d'Odysseum) et il y a 
> aussi des tracés en double pour palier au problème d'affichage des 
> noms (linéaire plus zone en dessous)
>
> L'autres système qui a encore d'autres implications c'est 
> *area:highway=**.
>
> Je suis d'accord que la double infos n'a pas d'intérêt et qu'il vaut 
> mieux faire un post traitement sous forme de maille avec détection 
> d’obstacle pour générer du tracé virtuel plutôt que ce que l'on voit 
> sur ta capture d'écran.
>
>
>
>
> Le mer. 19 juin 2019 à 16:54, lenny.libre <lenny.libre at orange.fr 
> <mailto:lenny.libre at orange.fr>> a écrit :
>
>
>     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  <mailto: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  <http://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.
>
>     _______________________________________________
>     Talk-fr mailing list
>     Talk-fr at openstreetmap.org <mailto:Talk-fr at openstreetmap.org>
>     https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> -- 
> Cordialement,
> Jérôme Seigneuret
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20190625/d09388c0/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/20190625/d09388c0/attachment.png>


Plus d'informations sur la liste de diffusion Talk-fr