Skip to content
This repository has been archived by the owner on Dec 4, 2018. It is now read-only.

[Don't merge][POC][RFC] Map matching test #44

Closed
wants to merge 7 commits into from

Conversation

rinigus
Copy link
Contributor

@rinigus rinigus commented Jul 8, 2018

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:

  • map matching with Valhalla
  • map rotation in accordance with the compass.

[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?

@rinigus
Copy link
Contributor Author

rinigus commented Jul 14, 2018

I think I have an idea on how to make it more general and easier to use for the apps. I'll make few more tests and then will write it up. At present, I am planning to continue discussion at SFOS devel list and then we can separately discuss API within WhoGo Maps.

@rinigus
Copy link
Contributor Author

rinigus commented Jul 19, 2018

Closing as PR, proper PR in the works

@rinigus rinigus closed this Jul 19, 2018
@rinigus rinigus deleted the mapmatching_test branch July 25, 2018 20:51
@rinigus rinigus restored the mapmatching_test branch July 25, 2018 20:51
@rinigus rinigus deleted the mapmatching_test branch July 25, 2018 20:51
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant