Route between via points does not match route between start and end points at the same position

[rkflx]

Test case

Routing in BRouter-Web (separate GET request with start and end point for each route segment):

https://brouter.de/brouter?lonlats=14.031333,50.955913|14.034385,50.956474&profile=trekking&alternativeidx=0&format=geojson
https://brouter.de/brouter?lonlats=14.034385,50.956474|14.034932,50.955997&profile=trekking&alternativeidx=0&format=geojson
https://brouter.de/brouter?lonlats=14.034932,50.955997|14.033516,50.95494&profile=trekking&alternativeidx=0&format=geojson

After exporting the route in BRouter-Web (single GET request with via points):

https://brouter.de/brouter?lonlats=14.031333,50.955913|14.034385,50.956474|14.034932,50.955997|14.033516,50.95494&profile=trekking&alternativeidx=0&format=geojson

Note that BRouter seems to be missing the pier in the OSM data (see #263). Still, the routing result (i.e. handling missing data) should be consistent in both cases, preferably in a way close to the user's intention (e.g. ferry instead of detour).

[abrensch]

Well, that's a very special case that is caused by the fact the ferry-route is a routing-island due to the man_made=pier sections with no additional highway-tag (see #263)

What happens here is that in exporting as a single request, the "waypoint matching" is re-used between the individual sections. And the waypoint-matching has an automatic "island-supression". So your via-points will be shifted away from the water by this island supression. While in the case of an individual GET request for the ferry-section, island supression will not get active because both start- end endpoint are on the island.

So I would say that's a wont-fix.

[rkflx]

Thanks for the explanation.

While it may seem like a minor edge case from BRouter's point of view, from BRouter-Web's perspective this can become a major issue: If you plan a route, you'd expect the exported route to exactly match your planning. In general you won't check the exported route again, and just upload it to your head unit. Thus you might suddenly face a long detour while riding (17 km in the example above), possibly leading to running out of fuel, missing an appointment or even getting stopped at a closed border (or, in the worst case, all of it at the same time).

Also, #263 is only one of potentially many cases. There can always be some island you might end up placing your via on, not noticing until you are on tour and it is too late.

Please reconsider. Maybe there is a way to make island suppression configurable for a request?

[nrenner]

The gaps between the segments are already an indicator to the user that something might be wrong and that not everything might be working as expected. Still a consistent export result would be nice.

Probably another reason not to recalculate the full route on export in BRouter-Web, but to combine and format the segment results we already have in the client, see also brouter-web#68 (comment).

[rkflx]

The gaps between the segments are already an indicator to the user that something might be wrong

Tiny gaps can be seen only when zoomed in sufficiently. Typically, users simply place vias until they see the route they want. They won't zoom in on every single via to check for its precise and island-free placement, in particular for long 100 km routes with a large number of vias. I doubt they are even aware that such issues might exist in the first place.

---

Anyway, here are some ideas to consider in the short-term, until this and other issues can be solved on a more fundamental level:

• For BRouter, clearly list the limitations regarding vias in the API docs.
• For BRouter-Web, show a warning if the exported route differs from the planned route.

[Phyks]

For BRouter-Web, show a warning if the exported route differs from the planned route.

This could be easier to implement this with gap detection and a warning. In any case, 👍 for signalling gaps and possible different downloaded route, at least as a short-term workaround!