[OSRM-talk] "Forward-only" constraint for map-matching

[Alex R]

Hi everyone,

I was wondering whether the map-matching functionality can be tweaked to
ensure that new matches can only occur "downstream" of the previous ones.
Let me illustrate what I mean:

- imagine a V-shaped road
- the vehicle moves on this curve from left to right
- there's a station just a bit above the lowest point of the V, where the
vehicle stops and waits for a while

Although it is physically on the right arm of the "V", due to the noise in
the incoming readings it may look like it is somewhere between the "V"
arms. Thus,  OSRM will sometimes match the vehicle to the left branch of
the "V", just across its actual position.

Assuming that the vehicle is a public transport unit, which only moves
forward (i.e. "downstream"), OSRM could take that into consideration, and
in ambiguous cases [when the raw GPS reading says it is somewhere between
the branches of the "V"] prefer to match to a point that doesn't imply
going backward on the route.

Can this be accomplished?




The general context is explained in an earlier thread: "Map matching for
live data-streams, one point at a time". I am thinking that the problem
could be related to the way I query OSRM.

1. Raw coordinates arrive every 3 seconds, and I store them in a queue.
2. Every 20s I query OSRM, by sending it the 8 most recent locations.
3. When I get the response - I take the most recent location and display
that on the map, while the rest is discarded.
4. When I send the next query, it consists of 8 _raw_ coordinates (rather
than matched ones, returned at an earlier iteration).

Would the OSRM make a better guess if some of its previous output were fed
into its input at the next iteration? (i.e. if at step #3, instead of
discarding the matched locations, I replace the raw queue entries with
their matched counter-parts).




Looking forward to your feedback,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osrm-talk/attachments/20200301/54bee0b3/attachment.htm>