LocationIndex.findClosest at junctions (depending on the input coordinates) can return any of the edges that are intersected there.
An improvement to the query could be to somehow influence more the filtering, i.e. to have in result a specific edge despite the minimal distance differences among them, like with the heading in routing.
Is that possible with current API?
It is not possible from the high level API I think but it should be possible if you pass a custom EdgeFilter to the lookup and prefer a certain angle. Even better would be if it directly integrates with the
Thanks for the hint Peter.
That can work with some adjustments, as returned edges may not belong to the intersection but comply with the distance / angle ranges.
What do you mean here? If you really query at the junction you can be sure it will return the correct edges if you filter away the ones you dislike. I only see problems with one-ways …
I suppose oneways could pass if we don’t use any direction filtering.
Saying to filter edges based on angle, we mean those that fall within an angle’s range (e.g. ±15°).
So using a custom
EdgeFilter with the functionality to accept the edges of a certain angle’s range.
LocationIndex performs searching based on some other variables, like max distance. etc.
There are cases where due to the filtering of close edges (because of their unaccepted angle), the result has an edge at some distance away (inside limit) with an accepted angle.
So need to influence the result more, e.g. shrinking the search distance(?).
(Hope to explained the situation a little better )
Thanks, understood what you mean. Similar problem we have for the map matching where we collect 3 results and priorize them later.
What exact use case do you have? Tracking a vehicle and updating the route information?
So keeping a results history and processing them afterwards seems the obvious way to proceed.
Currently I’m trying to explore the reverse geocoding possibilities on graphs in various test cases and noticed that issue in junctions.