When matching, ignore 'is_startpoint' propert, snap to any edge #5297
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue
A while back, we added a
is_startpoint
property to the Lua profiles. If this is set to "false", it means you can't snap a coordinate to that edge.This was handy for not accidentally snapping to tunnels, ferries and a few other things, but the heuristic wasn't subtle enough.
One bug it caused is trying to map-match across a
highway=service,access=private
road - we won't start/end you on one of these, but we will route over it. Because of the hardis_startpoint
property, the map-matching algorithm wouldn't snap trace points to these edges, and it lead to some sometimes wonky traces.This PR re-adds all those
is_startpoints=true
edges to the RTree, but adds a filter at query time - forviaroute
, the behaviour remains as before - start/endpoints won't snap tois_startpoint=false
. However thematch
plugin now overrides the filter, and will consider any edge that the Lua scripts have imported, even ifis_startpoints=false
.This should improve matching across
is_startpoint=false
edges.Tasklist
Requirements / Relations
Link any requirements here. Other pull requests this PR is based on?