MapMatching Rigidly Follows Traffic Laws
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start with the mapMatching API and review related issue #849, then trace how custom OSRM routes are passed through the Java SDK. Compare the requested first-responder route behavior with the current voice and banner instruction flow. Done would require a clearly defined, supported way to produce those instructions without rejecting traffic-law-disobeying routes.
Written by the indexing model from the issue text.
Description
The mapMatching API doesn't work with routes that disobey traffic laws. We are providing routes for first-responders (fire, law-enforment, EMS, etc.) who don't always need to obey traffic laws so this is causing issues.
Here's an example (the image on the left is the recommended route; the image on the right is what is returned from mapMatching, not allowing the illegal left turn):
We are generating routes from our own OSRM server using custom profiles and want to use mapbox-navigation-ios for the navigation frontend. As noted in this tutorial and https://github.com/Project-OSRM/osrm-text-instructions/issues/269#issuecomment-449417857 the recommended approach is to use the mapMatching api to add voice and banner instructions to the custom generated route object (orsm-text-instructions could be used to add the simple text instructions but not the voice and banner instructions).
We don't even need the "matching" part of the mapMatching api... we already have the precise road geometry, we're not snapping fuzzy gps coordinates to a road network. We only need the voice and banner instructions but there doesn't seem to be a way to get just these without using the mapMatching API.
We could write our own package to produce the voice and text instructions based on the route object (returned from orsm) and the simple text instructions (returned from osrm-text-instructions) but it seems needless considering this is something already implemented by Mapbox but not available in any way (open source or api).
We plan to reach out directly to Mapbox support to talk about this but I wanted to post a public issue here so that other's could add to the discussion if they have similar issues or possible solutions.
related to #849
- Dominant language
- Java
- Stars
- 438
- Forks
- 117
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from mapbox/mapbox-java
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
mapbox/mapbox-java#1640 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 55/100
mapbox/mapbox-java#1635 ·
-
Difficulty 5/5 Over a week Newbie friendliness 15/100
mapbox/mapbox-java#1619 ·
-
Mapbox-java incompatible with gson 2.13.0 and up - call to internal GSON classes that were renamed Open
Difficulty 2/5 1-3 hours Newbie friendliness 48/100
mapbox/mapbox-java#1614 · 2 comments · 1 reaction ·
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
mapbox/mapbox-java#1612 · 1 reaction ·
All issues in mapbox/mapbox-java
Similar issues
-
bug untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
opensearch-project/ml-commons#5094 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
emitter:client:csharp feature
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
affects/8.10 affects/8.9 component/clients kind/bug likelihood/mid severity/mid
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Two open-case totals on one screen: the Programs tile says 15,858 and the nav badge says 15,868 Openbug frontend maui-pilot
Difficulty 2/5 1-3 hours Newbie friendliness 72/100