Forum OSM France

Routage non optimal de GraphHopper

Bonjour,

J’ai besoin d’aide pour interpréter un mauvais choix de routage de OrganicMaps que j’ai vécu à côté de Brive-La-Gaillarde pendant mes vacances, et j’ai du mal à déterminer si le problème vient de la carte ou du router.

J’ai reproduit le problème avec l’interface d’OSM, et j’obtiens même un comportement différent avec OSRM et GraphHopper :

  • Avec OSRM, il fait bien passer par la déviation D921
  • Avec GraphHopper en revanche il fait passer par le coeur de village D169+D130

OpenRouteService (qui utilise pourtant une version forkée de GraphHopper) fait également prendre la bonne route, mais présente l’avantage de calculer des alternatives et d’afficher à la seconde près la durée de parcours. Cela permet de constater qu’il considère la route par le centre village légèrement plus lente (1’23 contre 1’16). Même si c’est la bonne route qui est choisie, la différence me semble sous-estimée (la route fait 100m de plus, passe par le centre village, sur une route de niveau tertiaire au lieu de primaire, avec une intersection Stop à 90° et un cédez-le-passage supplémentaires).

Le seul élément suspicieux que j’ai trouvé dans la carte est que la déviation D921 est taggée comme limitée à 50km/h à partir du rond-point, alors que ce n’est en réalité qu’à l’entrée de la « residential area ». La route D169 qui passe par le centre village n’est quant à elle pas taggée, donc je me dis qu’elle utilise peut-être les vitesses limites par défaut en fonction de la zone, et serait donc plus correcte. Cela n’explique cependant pas que les routers se comportent différemment, et surtout si je restreins l’itinéraire à cette section hors agglomération, j’obtiens exactement la même durée sur chaque route (ce qui signifie donc que la vitesse limite n’est pas prise en compte par le router d’ORS).

De la même façon, si je calcule un tronçon de longueur 300m, j’obtiens 21s sur la route primaire, et 22s sur la route tertiaire qui comprend une intersection Stop à 90° au milieu… ce qui laisse penser qu’aucune différence n’est faite avec le type de route, ni avec le rayon de courbure, ni avec la priorité des intersections…

Donc au final j’ai beaucoup de questions, mais les principales seraient :

  • est-ce qu’une vitesse est associée par défaut et automatiquement aux routes qui se trouvent à l’intérieur d’une « residential area » ?
  • est-ce que vous voyez un problème possible avec la carte à cet endroit, ou est-ce que je dois simplement ouvrir un ticket de bug pour GraphHopper ?
  • je serais également preneur d’informations sur la gestion des limites de vitesse, virages, intersections, priorités, par les routers se basant sur OSM, mais je crains que cela ne mérite un sujet à part entière !

Merci,
Cyril

1 Like

Si tu ajoutes les limitations de vitesse manquantes, ça devrait corriger le problème.

1 Like

Il faut regarder l’implémentation de chaque algo et surtout de la préparation des données.
Le mieux est d’être explicite sur les limitations de vitesse, ça évite d’avoir ce genre d’incohérences.

Consulter la doc de chacun ou descendre dans le code… c’est là qu’on peut avoir confirmation des traitements réellement faits.

Je n’ai aucune idée par exemple de qui prends en compte la présence d’éléments de ralentissement comme les feux, les passages piétons, les stop, les cédez le passage ou même… les ralentisseurs.

Par exemple, quand on cherche « landuse » sur GitHub - Project-OSRM/osrm-backend: Open Source Routing Machine - C++ backend on ne trouve pas grand chose qui indiquerai que landuse=residential soit effectivement pris en compte. Il y a un exemple LUA pour aller chercher dans une base postgres/postgis des infos complémentaires, mais ce n’est qu’un exemple. C’est le mécanisme possible pour inclure des analyses géographiques, pour vérifier si un tronçon de route se trouve ou pas dans un polygone landuse=* et par défaut ça ne semble pas utilisé, mais possible.

1 Like

Merci, je ne suis pas persuadé que le problème vienne des limites de vitesse car elles ne semblent pas prises en compte, mais dans tous les cas ce sera une bonne chose de les corriger, donc ça ne coûtera rien de vérifier si ça résout le problème en effet.

Par contre de ce que j’ai compris de certaines guidelines je ne dois modifier que les routes où je suis passé, il faut éviter les éditions « mécaniques » qui consisteraient à mettre 50km/h comme vitesse limite sur toutes les routes dans la « residential area » de la commune qui n’en ont pas déjà une, sans avoir vérifié sur le terrain qu’il n’y a pas de panneau 30 ou 70 sur certaines par exemple ?

Merci @cquest pour les infos, il faudra que j’aille regarder ça de plus près à un moment alors !

J’ai mis à jour les limites de vitesse sur les deux routes concernées, par contre je ne sais pas combien de temps je dois attendre pour que la mise à jour soit utilisée par le routage, et donc savoir si ça n’a pas d’effet ou si ça n’est pas encore pris en compte… (une modification que j’ai faite il y a quelque jours pour restreindre l’accès à une route n’est toujours pas prise en compte).

Pour revenir sur les limites de vitesse par défaut, dans la relation « France highway default values » c’est le type de voie qui définit la limite de vitesse par défaut, en l’occurrence 50km/h pour « residential » (et même 20km/h pour « living_street »).

En l’occurrence la route en question qui m’intéressait est « tertiary », donc selon ces défauts elle serait interprétée à 80km/h en traversée de ville (par contre inutile de tagger la vitesse limite toutes les petites rues). Tout cela en supposant que les routers utilisent ces défauts, ce qui serait toujours à vérifier, mais on pourrait dire que c’est un problème de routage et non de carte…

Ca y est la modification est prise en compte, GraphHopper fait dorénavant également passer par la bonne route, donc la mise à jour des limites de vitesse suffisait, merci pour votre aide !