Je poense que pour des cas comme ça, il faudrait que l'algo de routage ne cherche pas la route à partir du seul point accessbile le plus proche masi à partir d'un ensemble de points accessibles facilement dans un rayon acceptable (qu'on peut finir à pied). Malgré tout la difficulté est de trouver ce qui est routable à pied: il n'y a pas toujours de chemin précis mais des surfaces accessibles.
Bref, pourquoi ne pas chercher les routes qui aboutissent (ou passent) dans les surfaces englobant le point cherché (aussi bien au départ qu'à l'arrivée) il reste le bout de route inconnu entre le point cherché et le dernier point routage: on doit malgré tout s'en sortir avec un rayon de recherche où existe au moins un point accessible à pied. Et quand il y a plusieurs point routables dans ce rayon et qu'il ne sont pas routés directement entre eux, classer les résultats et ne pas se contenter d'un seul résultat sur le seul point routable le plus proche (car là on aura toujours des résultats aberrants, mais classer les résultats obtenus par distance ou par temps de parcours sur la partie routable (tout en estimant à la louche la distance ou le temps "à vol d'oiseau" de la partie non routable) peut grandement améliorer les choses. On trouvera parfois un classement incorrect mais afficher une liste de résultats et non un seul peut aider beaucoup: il suffit de cliquer sur le choix suivant. Une liste qui proposerait une choix avec au moins 5 ou 6 alternatives devrait toujours permettre de s'en sortir. Si le logiciel ne trouve aucun point routable dans le rayon raisonnable cherché (environ 50 mètres devrait suffire, au delà le lieu devrait avoir des chemins piétons ajoutés), il peut demander à l'utilisateur de préciser mieux son point de départ ou d'arrivée en présentant un zoom sur la zone déjà cherchée. Ce zoom devrait montrer les positions de départ (ou d'arrivées) possibles déjà trouvée, de sorte que la plupart du temps il suffira à l'utilisateur de choisir parmi les points proposés en cliquant dessus, ou déplacer son point de recherche plus précisément) Note que Google propose par défaut de compléter les chemins voiture trouvés par des chemins à pied sur une distance courte (là aussi de l'ordre de 50 mètres). Conclusion: dans des lieux au cheminement compliqué (barrières et interdictions/restriuctions) diverses, ne pas oublier de tracer les chémins pîétons entre les différentes zones. Le logiciel de routage trouvera alors ce qu'il faut (en tenant compte des préférences: voiture/vélo, sinon terminer à pied, et il trouvera non seulement le chmin principal mais aussi les derniers segments de chemins piétons tracés aussi même s'ils ne sont pas complets et ne détaillent pas les surfaces). Le jeu. 6 août 2020 à 12:20, Percherie OnDaNet <[email protected]> a écrit : > C'est aussi vers cette réflexion que je m'orientais. Les données sont > cohérente avec le terrain mais c'est au routage de s'adapter. > > Après essai sur l'Aire d'Hastingues : > https://www.openstreetmap.org/way/473891861 : > > - OSRM : échec > - GraphHopper : échec > - OpenRouteService : échec > - MapQuest : échec > - Application OsmAnd : échec > - Application MapFactor Navigator : déplace l'arrivé (drapeau) > clairement sur le segment le plus proche, ça à le mérite d'être > compréhensible > - Application Magic Earth : échec > - Bing Maps : échec > - GoogleMaps y arrive seulement parce que le nœud de l'aire est bien > positionné, autrement ça plante : > - Trajet 1 : https://goo.gl/maps/BTma9uZD7wuTEide6 > - Trajet 2 : https://goo.gl/maps/y3XSoj7c1YPxzAJR9 > - Waze : échec avec des détours hallucinant > - ViaMichelin plante avec une arrivée imposée en dehors de l'aire > - Mappy ne connait pas l'aire > > En l'état seul un service GAFAM y arrive. Que faut-il faire ? Remonter > l'anomalie à tous les services ? > Le 06/08/2020 à 10:24, Christian Quest a écrit : > > Le 05/08/2020 à 22:37, Arnaud Champollion a écrit : > > Le 05/08/2020 à 17:23, Jérôme Amagat a écrit : > > Si on remplace par un node, je pense qu'on aura toujours le problème, dans > un sens ou dans l'autre de l'autoroute. > > > Et si l'on met ce node sur une zone non accessible en voiture, par exemple > une zone de pique-nique, peut-être que le routeur n'aura plus intérêt à > faire effectuer un détour routier ? > > > Le routeur ça chercher la voie d'accès la plus proche, y projet le POI > d'arrivée et calculer la route sur ce point trouvé. > > Cela ne résoudra pas le problème qui est en fait lié à un routage > mono-mode. Si on faisait un routage multi-modal (voiture + pédibus) il > trouverai bien sûr qu'il est plus simple de marcher un peu à l'arrivée que > de faire un énorme détour en voiture. > > C'est pour moi plutôt un défaut des algos de routage sur le routage à > l'arrivée qu'un problème dans les données OSM qui décrivent, il me semble, > correctement le terrain. > > > _______________________________________________ > Talk-fr mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
