This is closely related to issue #926.
We're creating routes based on GPS data. Occasionally, the GPS indicates that a start or end location is situated in a place where there is no entry or exit, an island of sorts as described in #926, when the real location is probably on a main road a few meters away.
Is there any way to route between what I would call the "nearest viable point"? In effect, this would mean detecting when a point cannot be routed to and scanning for the nearest point that can be reached.
I believe this is similar to the z parameter, but adapted for when the nearest location cannot be routed to.
Example failing query to the API:
Thanks for any advice!
This is already on the roadmap and (IIRC) captured in an earlier issue. Planned to come with the release after next one.
isn't this the same as the current z parameter filtering islands - just taking deadend oneways into account?
Not only that, but also somewhat more. The following example illustrates it:
so in effect setting a 'search radius' for A and B, and finding the shortest path possible?
Thanks @DennisOSRM ! Yes, your image looks like it could be solved in the same way and would also help us for other similar situations.
The feature was discussed in #204 - also the option to pass a direction/velocity hint, which is used to pick the start way.
Thanks @emiltin for digging this up
use compass bearing when selecting start way #605
@DennisOSRM We've run into a few more situations where this would be very useful for our platform. Is there any way to sponsor the development of a rapid solution for this? We don't have enough knowledge about OSRM in-house to solve such a complex issue, but would be willing to sub-contract.
btw, there are already cucumber tests related to this in the repo. see the file features/testbot/bearing_param.feature
@DennisOSRM Is there any change regarding this issue in latest v0.4.1? I'm asking because you included this issue on distance matrix "battle plan" and I think I saw a commit related with 180° flip bearing or so... :-)
This is on the list for 0.4.2
@DennisOSRM... This one didn't come with 0.4.2, right?
I've tried tracking this one down through the commits but I didn't make it! :-)
The example API call in the original issue seems to work, but I've encountered one that didn't:
Thx for providing a new example @mck-
Another example I've just encountered: 33.86486,-84.47322 is on a private road. The nearest point on the network (as returned by /nearest) is 33.864792,-84.47303, which is at the end of a short one-way stretch and therefore unroutable.
At times it can also be data issues, e.g.:
Here it is a mandatory right turn that makes going straight impossible.
The issue I've encountered several times now is where you have a short 'divided highway' access to a private estate:
The default car profile won't route onto the private road, so looks for the nearest segment, which happens to be a one-way "dead end" in the divided highway.
This is implemented now and will be part of the upcoming release.
This is still not working: http://map.project-osrm.org/?hl=en&loc=54.696766,25.277030&loc=54.696654,25.279863&z=16¢er=54.695675,25.274005&alt=0&df=0&re=0&ly=-1171809665
there is a barrier=cycle_barrier at https://www.openstreetmap.org/node/3341832207
also it has no highway=*
Is there some kind of radius variable that I could tweak?
I changed this constant and got bigger search radius https://github.com/Project-OSRM/osrm-backend/blob/4ec323c5ccb3db4b31df1bedb12e596a388d49d0/data_structures/static_rtree.hpp#L649
I'm still seeing problems. Not getting a viable point for viaroute.
I start with a coordinate in the middle of a mountain (the other end of the route is an OK road point). I use /nearest to get to the nearest road segment: http://localhost:5000/nearest?loc=37.6756461497,-119.467181647
However, this mountain road segment is closed in winter so I am still receiving "impossible route" from viaroute when I swap in this nearest point.
To provide a true viable route, nearest would have to provide the first open road segment down the mountain.