This repository has been archived by the owner on Dec 4, 2018. It is now read-only.
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.
I would like to start discussion with this PR and then develop another one as a result of the discussion. So, don't merge it, its mainly to show that the whole approach is possible in practice.
Background
While using WhoGo Maps during navigation, it assumes, up to some point, that I follow the proposed route. On the basis of this assumption, the direction is calculated and set. Which, when you miss or have to skip the turn, gives you the wrong result. Similarly, while passing the part of the route which intersects itself (above highway while turning into it), we can jump between different parts of the route. While the latter should be probably fixed in narrator, the first issue requires more accurate direction estimation that would not depend on the expected route.
In addition, while driving, its would be great to get current street name and speed limits. Enter map matching.
Map matching
We have an option to run Valhalla on our devices in offline mode. So, I tested whether I can use it in practice. In short, it works very well! You can get the current location snapped to the route and determine direction of the motion quite accurately.
I have made a small class that calls map matching on every PositionSource update. The result was calculated and communicated fast enough that the delay on the map was rather small, if noticeable.
In this implementation, I am calling Valhalla service directly, bypassing OSM Scout Server. Turns out, that Valhalla has a recent API that would allow me to link it with OSM Scout Server and run it through it directly. So, we don't need HTTP connections between Valhalla and the server, but it will be sufficient to have direct connection between the server and the maps client.
Proposed API
I propose to make a new API that would allow us to call some kind of filter / processor on every position update. If the result is obtained, it will be used instead of current implementation of position filtering. I can envision that it could be used for:
[Compass seems to be fixed few weeks ago in the latest hardware adaptation for the ported devices, making it usable for us].
I would suggest to model the API similarly to map, route, and geocoding layers.
Thoughts? If we are going forward with it, what could be the name of such API?