[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