Forum OSM France

Encore des problèmes de routage!

Je débute !
#1

Bonjour,

J’ai toujours parfois des difficultés à trouver comment corriger la carte pour que les routeurs se comportent correctement, que ce soit OSRM ou GraphHopper.

J’ai notamment ces deux exemples :

  1. Itinéraire Ce bâtiment « Hall Comminges » a une route d’un côté, et un parking de l’autre, et son entrée est du côté du parking. On aimerait donc bien sûr que le routage nous amène sur le parking devant l’entrée, plutôt que nous fasse tourner plus tôt à l’arrière du bâtiment dans une impasse. J’ai donc ajouté un tag « entrance=main » du bon côté sur le bâtiment il y a deux semaines (node), mais cela ne change rien, que ce soit OSRM ou GraphHopper

  2. Itinéraire Sur ce grand site privé « Francazal » où plusieurs entreprises sont installées :

    1. OSRM accepte de guider les voitures jusqu’à une destination à l’intérieur, en faisant passer par l’entrée principale qui a une barrière taggée « private », ainsi que par des routes intérieures taggées « private ». Tout va bien… sauf qu’en fait il ne le fait que sur quelques routes, et pas d’autres, alors qu’elles semblent toutes taggées de façon parfaitement identique.
    2. GraphHopper lui se refuse complètement à faire rentrer dans le site, en arrêtant le guidage au niveau de l’avenue la plus proche, loin de l’entrée, avec un grillage infranchissable entre les deux.
    3. Encore plus étrange, en mode vélo ou à pied, OSRM refuse à son tour de guider jusqu’à l’intérieur du site, alors que tous les accès sont homogènes en « private » pour tous les modes de transport, et qu’il l’accepte donc en mode en voiture.

Auriez-vous s’il vous plait des éléments pour m’aider à comprendre ce qu’il se passe, et si possible à faire en sorte d’avoir un comportement correct des routeurs ?

Merci !

1 Like
#2

Bonjour,

J’aurais tendance à penser qu’il s’agit plus d’un problème de routeur que d’un problème de données OSM. Et donc qu’il faudrait poser la question aux développeurs de ces routeurs.
Ensuite, le fait qu’un routeur m’amène près de ma destination en me laissant choisir où je veux me garer est déjà pas mal ? :wink:

#3

Pour le premier cas, on touche aux limites des routeurs mono-mode.

Ils se contente de trouver la voie la plus proche compatible avec le mode de déplacement pour les points de départ et d’arrivée, puis calcule l’itinéraire entre eux selon ce mode.

Dans le lien que tu donnes, on a des coordonnées en départ/arrivée, il faudrait explorer les données OSM alentour pour déterminer:

  • qu’on est dans un bâtiment,
  • regarder si il y a des noeuds entrance sur ce bâtiment,
  • en choisir un (lequel ?) ou calculer tous les itinéraires de/vers chaque entrée
  • envisager une partie piétonne

On arrive dans une sorte de micro-routing qui nécessiterai aussi du micro-mapping… avec toute la partie piétonne entre éntrée et parking.

Comme @zorglubu je pense que cela dépasse l’objectif des routeurs actuels, mais ce serait une amélioration très appréciable.

#4

Effectivement on ne peut pas forcément attendre que le routeur dise parfaitement où se garer, mais en cherchant à s’approcher plutôt de l’entrée que du milieu du bâtiment, il augmente nettement les chances de tomber juste. Et si ce n’est pas le cas, en indiquant où se trouve l’entrée il permet au conducteur de faire un choix éclairé sur où se garer, et ne laisse pas complètement dans l’inconnu, sans savoir exactement quand est-ce qu’il faut arrêter de suivre les instructions… En tout cas j’ai ressenti de la frustration de devoir faire demi-tour dans cette impasse :smile:.

En continuant à creuser j’ai trouvé un élément pour le cas 1, qui amène en fait d’autres questions… la modification que j’ai faite était simplement de changer « entrance=yes » en « entrance=main », mais cela n’a donc pas eu d’effet (ce qui est assez logique puisqu’il n’y en a qu’une seule, mais bon). En revanche quand j’effectue une recherche pour « Hall Comminges, Colomiers », deux résultats ressortent, un « Theatre » et un « Community Center ». Il se trouve que c’est le bâtiment qui est taggé « amenity=theatre » et l’entrée qui est taggée « amenity=community_centre » (il y a en fait une seule salle et entrée principale qui peut servir les deux usages, les sièges étant amovibles). Et quand on demande le routage vers le community centre (l’entrée)… on arrive du bon côté !

Donc la question que cela amène est de savoir si cest normal de tagger à la fois (et différemment) le bâtiment et l’entrée, et sinon lequel préférer. Je dirais qu’avoir les deux dans les résultats de recherche est déroutant pour l’utilisateur (et le premier résultat est le bâtiment), donc qu’il faudrait n’en garder qu’un. Et il me semblerait plus naturel de tagger le bâtiment, c’est d’ailleurs ce qu’il me semble comprendre du wiki (ne tagger un noeud du bâtiment que s’il y a plusieurs amenity dans le bâtiment), même si tagger l’entrée fonctionne mieux pour les routeurs… Quant au choix du type d’amenity je partirais sur community_centre qui est plus général (puisqu’on ne peut pas en lister plusieurs).

En fait le lien contient effectivement des coordonnées pour l’arrivée, mais c’est une limitation du système d’URL, à la base j’ai choisi le POI avec une recherche, mais dans l’URL il y a les coordonnées et quand on la recharge le nom du POI disparait et est remplacé par les coordonnées. Après je ne sais pas si ça veut dire quelque chose sur ce qui est communiqué au routeur… mais MagicEarth, OrganicMaps et Osmand se comportent de la même façon.

En effet, commencer à regarder les entrées pose la question du cas où il y en a plusieurs, et les tester toutes semble assez compliqué. Mais simplement gérer le cas où il y en a une, puis celle de plus haut-niveau s’il y en a plusieurs, et continuer à router simplement au plus proche de cette entrée, limiterait la complexité tout en apportant une plus-value non négligeable. Mais c’est effectivement du côté des routeurs qu’il faut voir ça…

#5

Justement, je pense que le problème se situe en amont, dans le géocodeur qui va chercher le POI et fournir une coordonnée au routeur.

Le routeur va ensuite cherche un arc du graphe le plus proche de la coordonnée, puis faire sa recherche dans le graphe. Il ne sait pas que le bâtiment existe, ni l’entrée, ni même que c’est un POI.

C’est donc à mi chemin entre le géocodeur et le routeur qu’il manque de l’intelligence.

#6

Je vois, merci. En effet Nominatim et Photon fournissent le centroïde du bâtiment dans les résultats, directement utilisable pour le routage. Ils fournissent aussi les références de l’objet OSM, mais cela nécessite a priori une requête Overpass supplémentaire genre "[out:json]; way(74971446); (._;>;); out body;" pour récupérer les infos avec la liste détaillée des noeuds permettant de retrouver une entrée, ce qui est un peu lourd et ajoute de la latence… Idéalement on pourrait imaginer que ce soit le géocodeur qui fasse le travail en précalculant tout. Il y a d’ailleurs déjà un (vieux) ticket exactement à ce sujet pour Nominatim…

#7

Le géocodeur ne sait pas ce qu’on va faire du résultat… le routage n’est qu’une des possibilités.

C’est pour ça que je pense que ce n’est ni le rôle du géocodeur, ni celui du routeur, mais d’un intermédiaire actuellement inexistant.

1 Like
#8

Hello, j’ai une interpretation très différente en fait. Prenons le « centre » du bâtiment. Et ensuite, avec le trajet en mode voiture, on prend les points les plus proches atteignables par une voiture. On voit que depuis le parking, c’est deux fois plus loin que depuis la rue à l’ouest.

image
image477×727 62 KB

#9

Je n’ai pas l’explication pour toutes tes questions. Juste deux remarques :
concernant la qualité du routeur : le fait que faire passer le trajet par des éléments Private, ça dépend du routeur . Sur smartphone dans l’application OSMand par exemple, il y a une option « passer par des voies privées ».

Ensuite concernant le mapping des objets, je ne sais pas si les barrier=* sont vraiment utilisées. Mais mettre une lift_gate private, je pense que ce n’est pas suffisant. Je commence à regarder du côté de l’attribut locked=yes .
Une lift_gate private, concretement ça peut être une barrière basculante que tout le monde peut ouvrir sans clef / code / passe.

#10

Je comprends le point de vue… Cependant si le géocodeur ne sait effectivement pas ce qu’on va faire du résultat, j’ai quand même l’impression qu’il retourne un certain nombre d’informations utiles à différentes applications, et pas uniquement pour le choix du résultat désiré dans la liste retournée. Et le routage n’est pas une application anecdotique. Techniquement le géocodeur pourrait se limiter à retourner « osm_type » et « osm_id », qui permettent de retrouver toutes les autres informations, mais on préfère qu’il retourne directement un certain nombre d’informations utiles à des applications classiques. Avec l’option « extratags » Nominatim retourne même des informations assez spécialisées (wheelchair, …). Donc retourner les coordonnées du point d’accès du POI ne me semble pas si éloigné, tout en présentant un avantage d’efficacité par rapport à un traitement intermédiaire à la volée. Bref, du pour et du contre…

C’est effectivement la façon dont procèdent les routeurs actuellement de ce que j’ai maintenant compris, et explique leur comportement, mais je voulais juste dire que je trouverais plus pertinent qu’ils fassent cela depuis l’entrée principale du bâtiment, et non son centre. Cela ne serait pas forcément suffisant, comme l’a indiqué @cquest il faudrait idéalement du routage multimodal, car si l’esplanade piétone était plus grande on pourrait toujours avoir la porte côté parking plus proche à vol d’oiseau de l’impasse à l’arrière du bâtiment que du parking… D’ailleurs MagicEarth semble faire du multimode, et en théorie Valhalla aussi mais ça ne se voit pas sur le serveur de démo…

On ne veut en effet pas toujours la même chose, selon les accès que l’on a… En revanche ne router sur les voies privées que au début ou à la fin de l’itinéraire semble un comportement par défaut raisonnable, qu’ont apparemment adopté OSRM et Valhalla…

#11
  • Dans le premier cas, l’attitude du routeur me semble parfaitement cohérente. Pour moi il eut tout simplement été préférable que le POI soit en ponctuel (plus proche de l’entrée naturelle) et non en surfacique (où on laisse que building=yes).
  • Dans le second cas le routeur OSRM semble en réalité limiter ses possibilités d’accès après la barrières aux trois parkings. Seulement parce que trois petits tronçons de route devant ceux-ci n’ont pas le tag private !
#12

C’est la question que je me suis posée au départ oui, mais la plupart des grands bâtiments à « usage unique » semblent taggés ainsi… mettre le POI sur la frontière donne un rendu pas top, et le mettre un peu à l’intérieur n’est pas optimal d’un point de vue routage. Mais je suis d’accord que c’est un workaround intéressant, car il n’y a que la carte à toucher, et cela reste plus lisible que de mettre le POI sur un noeud du bâtiment. Je ne me sens pas trop de modifier beaucoup de POI comme ça par contre…

Bien vu, je n’avais pas remarqué ces trois petits chemins qui sont en accès publique. Mais est-ce que ça peut vraiment empêcher le routage ? En mode Car (OSRM) il accepte de les emprunter. Je voulais surtout parler de la route parallèle au nord, et des routes perpendiculaires au sud

#13

Pas vraiment, quand un bâtiment n’a qu’un usage, la règle est de tagguer le bâtiment plutôt que de mettre un noeud seul, voire même sur une emprise encore plus large pour inclure le parking de l’établissement.

On ne va pas « tagguer pour le routage ».

1 Like
#14

Ce sujet m’a permit de découvrir cette excellente page : https://map.project-osrm.org/debug
Elle permet de détecter les anomalies dans les données OSM, souvent des erreurs de topologie, qui peuvent éventuellement impacter les applications de routage utilisant ces données.

#15

Je n’ai pas bien compris l’usage. Il y a une légende qui existe pour tous les petits chiffres affichés ? Tu peux détecter autre chose que les limites de vitesse ?

#16

Excellent en effet !

Si je comprends bien les routes autorisées aux voitures mais non accessibles (non reliées au réseau routier) sont explicitement mises en évidence en étant entourées en magenta. Autour de chez moi il s’agit plutôt de chemins qui ne sont en réalité pas autorisés, plutôt que en réalité accessible, mais c’est utile aussi. Et le code couleur pour les vitesses permet aussi d’identifier des anomalies facilement.

Toujours si je comprends bien, les vitesses s’affichent explicitement sur les tronçons quand on zoome suffisamment, mais ce sont plus des vitesses « pratiques » utilisées par le routage que des limites de vitesse. Ensuite il y a les temps de transition entre chaque paire de tronçon à chaque intersection, qui semble être en secondes. Quant au « rate », il est proportionnel à la vitesse mais peut-être biaisé pour tenir compte d’autres préférences d’après la documention.

#17

C’est surtout les tronçons routiers contourés en magenta, en effet, qui permettent de détecter les incohérences de tags sur les tronçons routiers. La couleur met en avant les éléments du réseau routier déconnectés du reste du réseau alors qu’ils son sensés être utilisables par tous. A contrario les tronçons routiers non contourés ne sont pas utilisés pour le routage, et dans ce cas celà permet aussi de détecter des anomalies. Dans un des cas que j’ai traité une partie de réseau était inaccessible à cause d’un limiteur de hauteur de 1.9m mal positionné.
Par contre je n’ai pas trouvé la documentation et la légende de cette page.

#18

Avec cette mise en couleur j’ai pu corriger une première anomalie dans mon secteur (magenta). Je verrai quelle est la fréquence de rafraichissement des données.

En ville on peut aussi surveiller les rues en jaune et orange (50-70 km/). Sauf exception type périph’ ça ne devrait pas exister. La réponse est souvent très simple : il manque le maxspeed.

En montagne j’ai des chemins carrossables en magenta loin des routes. Il faut remonter toute la suite des chemins pour voir les autorisations d’accès. Moins simple à corriger.

J’ai aussi trouvé un segment en gris, qui cause une zone en magenta derrière. C’est une living_street avec une limite de hauteur à 1.9 et de poids à 3.5 mais je n’ai pas encore compris l’erreur.

#19

Dans le cas d’OSRM il semble que le gabarit minimum accepté soit de 2m correspondant à un véhicule de type van. Cela exclue du routage les portions derrière un limiteur à 1.9m donc.

#20

Effectivement j’ai trouvé aussi un bel example de route taggée max_height=1.9m à tort. Le profil « car » d’OSRM spécifie en effet un véhicule de hauteur 2m. Dans les vrais positifs, j’ai aussi trouvé quelques « boucles » en sens unique dont la courte partie commune d’entrée/sortie était aussi en sens unique, ou d’autres problèmes liés à des ererurs de sens unique qui empêchent d’entrer ou sortir d’une zone.

L’inconvénient de la hauteur de 2m c’est que cela génère pas mal de faux positifs : une barrière 1.9m => paf tout ce qui est derrière est en magenta. Beaucoup de faux positifs également parce qu’une barrière interdit l’accès, mais la route inaccessible n’a pas été taggée « motor_vehicle=no ». Pas très pratique pour « dégommer » et essayer d’avoir quelque chose de propre…