"Test" d'édition concernant les chemins et voies

Bonjour,

En cas d’éditions complexes (certains carrefours avec plusieurs voies et des interdictions de tourner, par exemple), j’éprouve le besoin de “tester” mes modifications afin de m’assurer que cette modélisation correspond bien à ce que l’on observe sur place dans la réalité (dans le respect du code de la route, évidemment). Pour ce faire, j’utilise Mapquest en mode OSM data (http://wiki.openstreetmap.org/wiki/MapQuest).

Avant toute chose, est-ce une bonne démarche à votre sens ou y a-t-il meilleur moyen de faire ?

Et à supposer que ce soit un moyen efficace, j’ai constaté que certaines de mes modélisations ne fonctionnent pas comme je l’entends, même plusieurs jours après édition (d’après le wiki, les infos de routing de MapQuest ne sont mises à jour qu’une fois par jour). J’ai pu en fixer certaines, mais d’autres demeurent récalcitrantes. Est-ce à dire que ma modélisation est erronée quelque part, ou cela peut-il venir d’un temps de mise à jour supérieur à ce qui est indiqué dans le wiki, ou simplement à un souci d’algorithme de routing côté Mapquest ?

Afin d’être plus concret, voici deux exemples qui marchent (certains après un grand nombre de modifs du fait de ces tests):

  • Sens unique d’accès à l’allée Jean de Brunhoff à Vannes et interdiction de couper l’avenue du Général Delestraint: http://mapq.st/1j6hwsE : a impliqué de diviser l’avenue du Gnal Delestraint en deux, ce qui est conforme à la réalité du terrain
  • Carrefour de la Place St Michel à Paris: http://mapq.st/1j6tcNz : initialement, tout convergeait au niveau du feu situé au croisement du Pont St Michel et du quai des Grands Augustin, ce qui ne correspondait absolument pas à la réalité du terrain: il y a deux feux, des voies clairement attribuées, et le virage à gauche tout comme le demi-tour autour de la place St Michel ne s’effectuent pas sans respecter nombre de règles indiquées sur place

Et voici un exemple qui ne marche clairement pas:

  • Domaine de Graville: http://mapq.st/1j6rRpY : l’arrivée au Domaine devrait se faire par l’allée allant directement à ce point, ouverte à ceux qui s’y rendent (‘destination’), alors que le routage m’envoie sur une allée privée située juste à côté et n’allant pas jusqu’à destination…

Que faire ? Je suis à l’écoute de tous vos conseils.

Bonne journée!

Bonjour,

Réponse partielle : je fais le même genre de tests que toi, à la différence que j’utilise OSRM. Je ne connais pas la fréquence de mise à jour d’OpenMapQuest, sur OSRM ça prend au plus quelques jours.

Pour l’exemple de ton dernier itinéraire cela donne-t-il le résultat escompté : http://osrm.at/73Y ?

Oui, effectivement, dans OSRM (que je ne connaissais pas, d’ailleurs, merci !) ce parcours fonctionne parfaitement.
Par contre, celui de Vannes, qui fonctionne bien sous MQ, me faire sous OSRM fait un violent demi-tour sur l’avenue Delestraint : http://osrm.at/742

Est-ce que ça veut dire que ma modélisation n’est pas assez bien définie pour que ces deux moteurs parviennent à faire leur routage correctement (du fait d’ambiguïtés, ou de permissivités de notation exploitées par inadvertance, par exemple), ou est-ce un problème lié aux algorithmes eux-mêmes ?

Clairement OSRM permet le demi-tour car il n’y a pas de turn-restriction dans les données OSM. J’ignore pourquoi MapQuest fait faire le tour du giratoire ; peut-être son algorithme juge par lui-même que l’angle est impossible.

Concernant la séparation de la chaussée en deux, si c’est comme ce que l’on voit avec Bing, cela ne correspond pas à la réalité. S’il n’y a qu’une chaussée (pas de terre plein central, par exemple) et juste une ligne blanche, il faut représenter la voie avec un seul way (qu’il faudrait couper en deux pour y placer une restriction=only_right_turn).

edit : tu connais bien les relations de type restriction, au fait ?

En fait, il y a aujourd’hui une séparation par les plots aux endroits modélisés comme séparés. Donc la chaussée est bien séparée par un obstacle physique tout en étant pas dissociée (ce qui est plus récent que la photo de Bing sur laquelle ça n’apparaît effectivement pas). Ca me semble cohérent d’un point de vue logique, mais il y a peut être une meilleure méthode pour le représenter.

J’avais tenté les restrictions, sans succès, mais il faudrait peut-être que je re-essaie car je débutais sur OSM au moment de cette modif. J’ai pu comprendre des choses depuis, sans m’en rendre forcément compte.

Le comportement de MQ est le bon en tous cas : il faut effectivement passer par le giratoire pour effectuer ce trajet. Il me faut maintenant le modéliser pour que tous les moteurs l’interprètent sans ambiguïté et sans compter sur l’algorithme de routage.

Avec cette restriction, cela devrait être bon dans OSRM.

Génial, merci ! J’étais justement en train de regarder la page wiki.
Je vais tester demain après mise à jour des données, et si ça fonctionne comme attendu, je m’en inspirerai pour mes futures modifs.

Pour modéliser les interdictions et obligations imposées par la signalisation, il faut utiliser les relations restrictions comme indiqué par Mr Couteau. En effet, on ne peut pas tout modéliser uniquement avec les tags sur les ways. Ce n’est pas étonnant que tu doives tâtonner pour arriver à tes fins dans ce cas là.

Et au passage, sur un highway=tertiary, secondary, etc… pas besoin de rajouter access=yes, motor_vehicle=yes, bicycle=yes, parce que c’est implicite.

Oui, j’ai découvert ça plus tard… ouf :slight_smile:
Pour le moment, pas de changement sur OSRM mais il est possible que la synchro n’ait pas encore eue lieu.

Il semble bien que oui : http://osrm.at/742

Cela me guide pour les modélisations futures, merci !

Bonjour,

Deux ans plus tard…
Je ne comprends pas, j’ai appliqué ce principe à un trajet similaire (et situé dans le même quartier), et sans que je ne me l’explique, j’ai le même problème:

http://www.openstreetmap.org/directions?engine=osrm_car&route=47.65868%2C-2.73267%3B47.65807%2C-2.73403#map=18/47.65849/-2.73271

Alors que la solution ci-dessus à très bien fonctionné dans l’autre sens:

http://www.openstreetmap.org/directions?engine=osrm_car&route=47.65807%2C-2.73403%3B47.65300%2C-2.74152#map=18/47.65790/-2.73495

Qu’est-ce que je n’ai pas compris ?
Merci d’avance !

ça m’a l’air normal
peut-être fallait-il attendre la prise en compte d’Osrm ?

Je n’avais pas pensé à ça. Je supposais que sur www.openstreetmap.org l’itinéraire proposé utilisait l’algorithme demandé, mais sur les données de la base mère OSM.
Mais ce n’est peut être pas le cas, je re-testerai dans quelques jours.

Je confirme, c’était bien un problème de temps de mise à jour, comme tu le supposais. Cette même route, maintenant, fonctionne parfaitement sous OSRM.
Bonne journée !