I used google map to get the polyline, and the Interactive Polyline Encoder Utility can be used to display it on the map, and it is obvious that I am passing the M1 toll highway.
However, when I passed to the Toll Calculator API(v2), it returned “Requested resource was not found”.
I don’t know where the problem is, please help me.
At present, my polyline data contains 2790 points. I thought it was caused by too many points. When I kept the total route unchanged and reduced it to 300 points, the error message Requested resource was not found was still returned.
Did some debugging and it looks like the issue is with slight differences in underground tunnel alignments between polyline you’re passing into the API vs OpenStreetMap (which is what the toll calculator’s mapping data is based on).
You can specify manually specify a match accuracy using the "accuracy" parameter in the JSON payload. For your polyline, 30m seems to work ok:
I used the accuracy parameter, and the Toll Calculator API can work normally. Thank you so much. But I still have the following questions:
Toll Calculator API uses OpenStreetMap, but I use Google Map. There are certain differences between them in matching routes, which leads to the problem of inability to calculate. Is my understanding correct?
Does this happen only on underground tunnel routes?
We will also calculate Toll in other areas of Sydney. Should I always pass in the accuracy parameter?
The smaller the accuracy parameter value, the higher the matching degree? If it is bigger? How should I better control the value of the accuracy parameter? If possible, I would like to understand the accuracy parameter in more detail.
On second examination, I suspect the issue here is actually to do with routing data in and around the business park at Botany rather than underground tunnel alignment. I’ve gone in and fixed some incorrect turn restrictions in OpenStreetMap and added new routing inside the business park. It won’t be reflected in the Toll Calculator matching straight away, but we can see if it resolves this problem in a future map update.
Think of it as the “GPS accuracy” value. The higher the value you pass in, the more lenient the matching algorithm is going to be matching against the OSM road network.
If you put in 30, it indicates to the algorithm that the coordinates you provided in the polyline are accurate to about 30 meters. It’ll try and match against all roads in a 30m radius of each point in the polyline.
I think the better strategy here might be to run /matchwithout the accuracy parameter first as the response is quicker. If it comes back with a “no match” error, then try again with a higher accuracy value.
Thank you for your detailed answer, we applied the accuracy parameter to the production environment.
Today I found that using the data in polyline.txt and adding accuracy=30, it still returns Requested resource was not found.
Adjust the accuracy parameter to 10 20 50 100, and the returned result remains unchanged.
API returns: “error”: “Unexpected token _ in JSON at position 27”
The original data is used.