<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi folks,</p>
<p>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
<i>should</i> be acounted for prior to feeding into OSRM).</p>
<p>By default, the Matching service is free to split the trace into
sub-traces based on large gaps, resulting in more than one <b>Route</b>
object in the <b>matchings</b> object. Correct me please if this
is not exactly the behaviour,and there may be other reasons for
more than one <b>Route</b> object.<br>
</p>
<ul>
<li>Q: What exactly happens if I deny the splitting; does the
whole trace get a 'No Match' if it otherwise would get split?</li>
<li>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?<br>
</li>
<li>Q: And if not, how does OSRM fill in theses gaps?</li>
</ul>
<p>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 <i>some</i> output to proceed with.</p>
<ul>
<li>Q: does that make sense in the case the <i>do-not-split</i>
setting would otherwise produce a 'No Match' for the whole
trace?</li>
</ul>
<p><br>
</p>
<p>Many thanks in advance,</p>
<p>André<br>
</p>
<pre class="moz-signature" cols="72">--
pgp-key attached</pre>
</body>
</html>