[OSRM-talk] Matching behaviour for split parameter

André Siefken siefken at geozelot.com
Wed Feb 12 16:04:12 UTC 2020


Hi folks,

I run an application where both large collections and incremental
additions need to be matched. This is an intermediate step in a more
complex processing, and requires consistent output (except, of course,
the input GPS point sequence is completely bogus, which /should/ be
acounted for prior to feeding into OSRM).

By default, the Matching service is free to split the trace into
sub-traces based on large gaps, resulting in more than one *Route*
object in the *matchings* object. Correct me please if this is not
exactly the behaviour,and there may be other reasons for more than one
*Route* object.

  * Q: What exactly happens if I deny the splitting; does the whole
    trace get a 'No Match' if it otherwise would get split?
  * Q: If yes, would the whole request get a 'No Match' even with
    splitting allowed, in a case where it cannot find matches for a
    subset of points?
  * Q: And if not, how does OSRM fill in theses gaps?

As a follow up: to get consistent results, I intend to implement a
fallback where I try to Route instead between the last '0
alternatives_count' waypoint and the first of two consecutive
sub-traces, to at least have /some/ output to proceed with.

  * Q: does that make sense in the case the /do-not-split/ setting would
    otherwise produce a 'No Match' for the whole trace?


Many thanks in advance,

André

-- 

pgp-key attached

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osrm-talk/attachments/20200212/26a925f8/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x0024705C4FC20AF6.asc
Type: application/pgp-keys
Size: 3155 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/osrm-talk/attachments/20200212/26a925f8/attachment.key>


More information about the OSRM-talk mailing list