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
0x0024705C4FC20AF6.asc
Description: application/pgp-keys
_______________________________________________ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
