Constant "Requested waypoint parameter could not be matched." error.

Hi there,

I am trying to get the tolls on the following polyline.

Actual polyline

f{flE{oow[O`Oy^}Bi]`f@r`@td@dc@fs@nYl\zd@n_@hWiN~eAgg@nlAos@niAqeAjfAigAt^a[ll@{f@bTuNRQh}@y_@|g@aCjl@yIvQuLjGkGrcAxPdyBdBr^sEdWm_@ty@oc@p|AvWjpBvMhaBo\|jBlVfnBld@r}@`Sti@_w@cAyaAN}DjWw_AlDm`@zSqf@rSs[l{@ah@lOoDf^ab@|NaZlZux@~CiTj@mItLwLfIdAP@ACIAD@VAnHvBVT

The same polyline but with more points between the points of the first one.

f{flE{oow[G`GG~F??{N_A}N}@??eNnRcNpR??xOzQxOxQ??bQbY`QbY??fLtMfLvM??|QfO|QfO??dKsFbKuF??nb@cSnb@cS??ve@gYve@gY??fd@gb@fd@ib@??tb@cc@tb@ec@??xN_MzNaM??tU}RvU}R??pIyFpI{F??HGHI??b^kOd^mO??lSaAnS_A??tUmDtUkD??jH{EjHyE??dCeCdCeC??ha@zGha@|G??`|@p@b|@r@??xNiBxNiB??`KeObKgO??h\gQj\gQ??vm@jKxm@jK??tw@jFtw@jF??dp@wMbp@wM??~t@vJ|t@tJ??rv@vQrv@tQ??h^`Ih^~H??jT_[hT_[??a@k`@a@m`@??F}AF_B??dKk_@dKk_@??tAuOvAwO??lIwRlIyR??hIiMhIiM??d]oSf]qS??fGwAdGwA??rNoPrNqP??|FqL~FoL??tL{[vLy[??nAsInAuI??TeDTgD??xE{EzE{E??bDb@bD`@??H?F@??AA?A??E?CA??@?B@??JAJ???vCz@vCz@??JJJH??

But I keep getting the following error when I make the request in the api (with both polylines):

Requested waypoint parameter could not be matched.

I cannot find any documentation that provides anything help in regards to finding out exactly what the problem is, would anyone be able to point me in the right direction?

Sorry, going to bump this. We are currently relying on a third party to generate a route and its forcing us to split our polylines up, we want to know exactly what is wrong with the supplied polyline?

Hi @mathewp,

Would you know how that second polyline is generated? I had a look into this and it appears the second polyline has a few extraneous points which are quite far from the road network that’s causing for the matching algorithm.

Using the following tool to decode the polyline:

You can see that there are points which would make it hard for the algorithm to find a match - e.g.:

Examples

image

image

image

image

They seem like those extraneous points which are interpolated, so it would be good to understand how they came about and see if you can exclude them.

Thanks,
Ken

Okay that second polyline is using points in between the actual points so some of them are bit off because its like a “middle point” between 2 actual points. We thought originally the problem was that there was a lack of points so we increased the point count.

I’m mainly wondering about the first polyline as to why that error is popping up as that is the polyline we would normally go with.

Ah I see, my bad.

Debugging the first polyline, it looks like the culprit is actually the first point (in yellow). If that point is excluded, the polyline matches with "accuracy": 10 or greater.

Payload:

{
	"polyline": "vzflEy_ow[y^}Bi]`f@r`@td@dc@fs@nYl\\zd@n_@hWiN~eAgg@nlAos@niAqeAjfAigAt^a[ll@{f@bTuNRQh}@y_@|g@aCjl@yIvQuLjGkGrcAxPdyBdBr^sEdWm_@ty@oc@p|AvWjpBvMhaBo\\|jBlVfnBld@r}@`Sti@_w@cAyaAN}DjWw_AlDm`@zSqf@rSs[l{@ah@lOoDf^ab@|NaZlZux@~CiTj@mItLwLfIdAP@ACIAD@VAnHvBVT",
	"accuracy": 10
}

You can see why that’s failing to match when we overlay this on the OSM basemap. The matching algorithm uses OSM for the road network data and there aren’t any roads mapped within that facility. The matching algorithm is particularly sensitive to outliers which are at the start of the trace.

We’ll see if there are additional strategies we can put in place to better handle outliers at the start of the route. For now, it may be worth seeing if there’s a way to exclude the first few points.

image

1 Like

Hey @mathewp

We’ve made some improvements to the matching algorithm so that it’s more lenient on matching the first few points. I tested the first polyline you provided and it looks like it’s now matching fine with accuracy >= 30.

Thanks for flagging this issue!

Cheers,
Ken