[OSM-talk-fr] routage surfacique

Mar 25 Juin 17:17:14 UTC 2019

Merci de ton retour.

On peut faire un fil spécifique sur Talk-fr (c'est peut-être mieux 
d'utiliser la page de discussion pour des évolutions plutôt que des 
clarifications ?) : je vais envoyer un mail dédié.

Pour le schéma il y a bien un highway=crossing sur chacun des nœuds 
représentés par un passage piéton. J'ai mis à jour le schéma : 
https://wiki.openstreetmap.org/wiki/File:Sidewalk_crossing-FR.png . 
C'est plus clair comme ça ?

Antoine.

Le 25/06/2019 à 18:17, osm.sanspourriel at spamgourmet.com a écrit :
>
> Tu veux qu'on en discute comment ? En direct ? Sur talk-fr (avec un 
> fil spécifique ;-)), sur la page de discussion ?
>
> Sur la première image :
>
>
> J'ai du mal à comprendre : n'est-ce pas plutôt un nœud commun au 
> chemin séparé (highway=footway) et à la route (highway=*, sidewalk=*) 
> qui est tagué crossing=) ? Et grosso-modo juste la petite partie entre 
> le croisement des deux trottoirs séparés et et les rues qui doivent 
> être en footway=crossing c'est à dire la partie linéaire correspondant 
> aux zébras sur la route ?
>
> Le 25/06/2019 à 16:17, Antoine Riche via Talk-fr - 
> talk-fr at openstreetmap.org a écrit :
>>
>> 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
>>
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
> _______________________________________________
> 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/3da35c19/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/3da35c19/attachment.png>