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,



pgp-key attached

Attachment: 0x0024705C4FC20AF6.asc
Description: application/pgp-keys

OSRM-talk mailing list

Reply via email to