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.
This is my polyline data:
Please ignore the json format error in postman, it is actually correct.
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.
Hi Mike,
If possible, it might be useful to share the 300 point route payload you used for reproduction 
Nevermind, just realised you’d shared the polyline in Google Docs.
Hi jxeeno
Thank you for your prompt reply.
I reviewed it last night. It may be related to the precision of Polyline encode, but it is just a suspicion and cannot prove it.
The encoding plugin I use is google-map-polyline-encoding-tool
Hi Mike,
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:
{
"polyline": "noenE}ayy...",
"accuracy": 30
}
Thank you jxeeno,
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.
That’s right. See below map extracts for the key differences (red = supplied polyline, blue = OSM).
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 /match without 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.
Hi jxeeno
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.
Hi Mike,
We are investigating this issue and will update.
Okay, waiting for your good news.
We also have our own development team in Sydney, if there are any changes we can participate in, please also suggest.
Thank you terencekhoo
Hi Mike,
Please try it now. Thanks.
API returns: “error”: “Unexpected token _ in JSON at position 27”
The original data is used.
{
“polyline”: “”,
“vehicleClass”: “A”,
“excludeToll”: true,
“departureTime”: “2020-12-17T18:38:55.889”,
“accuracy”: 30
}
That error message means the payload sent isn’t valid JSON (at the 27th character). Are you able to post the serialised payload? You can see an example of a working payload below.
{
"polyline": "ffenEyfyy[??GZ?@oA~GaAjFAf@@D?B?@?B?BA@A@C@A@A?AF?FAHAHCN?@R~@@HDX@PBT@T@H?H@F@F?B@HJn@L~@@BFb@BJH\\@LTbA??DRw@Ze@P}@Xq@R??e@Nc@NYHa@NQFODA?A?CACCCCAAAAAAAEEWIc@Kk@[uBSiAUiAOw@Os@IYIWKYO]S_@EGYc@OSY]a@_@MMECSO[S[OWMSGUIUGGAKCOCGAIAYC[F??uBIGAy@CIA_BGoACQ?WAoAEa@@m@???YEeAOAA?AAAA??AAA?AAAAC?CACACAE?CAC?CAE?EAE?EAE?EAE?EAW?[AcA?EEo@QiA??CMCKm@cCIUg@oBGQI]a@iBQy@EQGg@_AiDAGS_AWkAa@yBKm@Im@Iq@MmAGq@Gs@ImAEs@Cu@CeAAo@CcCBqBLwE@MBq@Bg@?I@Y@Y?W?M?W?Y?AAIAe@AYCYC_@E_@E[Ga@GWMm@UcAMm@Qu@Oq@GUGYIUIUIS_@w@GMIKOWOQOQMOQQQOQMQMy@i@i@_@gAq@s@c@kDwBQKAACAGEeC}Aa@Wc@YAASKc@Y}AaAs@e@w@e@c@Yo@a@YQc@Yg@[a@Wc@WSKQKUKOISIMGICQGOEKC]IIASEMAQCUCUAk@Ci@?k@Bi@DSBUDSDUD[HKDQFWJ_@PC@QHIFIDQLSLQNOLKHKHQRIHKLMPIHEHOP[f@U\\CFQXc@r@QXU^_@f@[`@OPQROLONQLOLSLQLQJKFIDQFSJQFQFQFQDG@QD]FMBUBUBQ@M?M@S?Q?g@AWASAk@Ea@Eq@G_AME?a@E_AKWCg@G_AKg@GiBUi@IWCeBYaAO]Gk@KsCi@aAS}@OgB[wBWm@Gm@EkAIKAKAOAi@CKAsAGw@Em@EK?KA]?E?AAI?i@?m@Ag@CSAM?c@AMA_@CIAYCiBSA?wDc@wBUiAKkAO??MGOCQCWCe@EaBQCAc@EAAi@Gi@KgAU[GC?mDq@c@IwCi@yAYe@Ic@Ii@KeCY_Fo@{@KsDc@sFs@cBSwB[]Iw@Oa@Gg@EGAs@IcEe@mC[aBEi@Gi@Gk@Gg@K_F}@uAU{AQ_@GUCcC[{@Km@IQBmAMAAq@G]GA?uAOy@GgDZqAJi@D]Dc@FG@YDSDODa@JiCl@i@Ls@NcAFWBk@Dm@Dc@BO@kAFuBPaABo@@a@@uB[SCSAIAQ?OAy@GOAMAUASA]C{@GOAMAC?SAQAKAKAE?QA[CGAQAOAc@CSAOAoAI[Cc@CMAMAk@CQAQAGAYCc@CsAIq@GI?A?CAA?KAKAE?a@Ce@EOAa@CoAKIAS?A?MAG?[@O?I?a@?UAYAK?WAcAKo@IcAMoAQq@Qc@M]Ic@MSEyAS??E?GAM?S?W?U@YBOBQBSDKDMBKDKBIDIDULUJULSLSNSNQPSPGFMRMPCDGFKTKRKTKTIVIXGTERI\\_@dBOr@Qn@Sn@Up@_@~@Yn@KPa@r@STON_@b@A@URIFA@MHWLEBSFGBA?SFUDSBI@U@S@UAI?KAIAIAICUCSGICCAOEICGCA?MEOGIESGQIg@UME[MMCQEIAOCSCQAWCW?SAM?G?M@s@?O?k@?]?E?A?M?O?e@?s@?k@?gD?i@?K?S?W@g@BqADk@Bm@B}@Bs@@U@i@@S?k@@sBF_ABi@@gBDA?a@@c@@mEJiBDo@BcA@uDJgHHS@_A@m@@Q@s@DUBSBKBI@K@G@IBUDSFSD{@Vu@RE@UFc@LKDA?g@NSDg@N]JIBa@J[JE@MD{@TSFGBgAZSFeBd@g@Ng@Na@JA@k@PwA`@MBWHw@Tg@NUFu@TC?q@RIBe@LC?SFIBSDG@A@I@A?SDG@KBIBSB_@FC@i@Fc@D[Be@BA?Y@G?[?]?WAy@C_COIAEAk@Gc@Ia@EKA]CaAKcFe@a@EqAMk@I_@Gg@GIAs@MOCq@OWE[Iw@Oe@MaAYqAg@o@WSKMG]Oe@Ui@[e@UYOi@Y??AKCGEGIGUOQIi@UUOUMMGQIWM[MSGYGaASm@OOCMEKMKK???A?ABS?C@OBI?_@@i@@a@?_@?A?I?EAM?CAQAMCIAECGGMk@_AEKCCAGCEAG?ECI?G@YLcBDa@B_@BUBKBQ@G@IDM\\gATo@d@aBRm@J[h@mBNi@Jc@^uAd@gBXeAV{@d@mBRm@R{@DSDc@@i@Aa@?WC[AGAGKYCKIY{BmIGWOg@EOGQo@qBM_@a@gASi@IQGOMYSYSYc@i@e@m@]c@IMCCa@}@g@mACGGMYq@q@sBWo@Wm@GQCGg@eAWc@GKEEIMGE_AaASU_@[KI_@a@OQOOa@a@WYCCg@g@sAuA[a@U]IMGIEIGMQa@KUIUUi@c@gAGOM_@CMCKCIAME]E]C]CUAQA[A]?_@?s@@qA?mA?iE@o@?o@?a@@e@@A@]BMJmBBq@@s@@YAO?GAEAEAEa@q@kEsHe@y@Yg@We@GIIKQOKIOEOGYEwAM}CSg@?_@@e@Bo@D]Bs@DW?MASCSCUCuASWCK?K?I?yB\\QBQDu@V{@XgA`@g@Nc@NODMDMBM@QBU@O?G?SAQCWEWEWEUEKCSEWKMGIEKEc@]OMIEMIEAMGEAOCKCICQAu@Ks@IYEKAKCGCECMEKIGEGGIIOUCGGIGKEIKKCECACACAAAEAICCAIAG?E?C?G@E@E@G@EBIFEDCB?@IJCDIRKV?@EHEHCDEDCDEDKFEBE@E@C@C@K?E?G?EAGACCMGIE[WKKYYWYg@g@YYIIc@_@[UKKOMgAy@y@q@eA}@SOSOAAKIICYO]Oa@MWIGCSC]EQCMAMAQ?U?W@UBMBKBKDkAPuBZi@HcANkARc@HaAPO@UBW@U?S?OAE?SAQAE?CAGAGC[CaCMwBM]C_@AKAEAGAGCA?KAM@M?OAK?KCKAECGAMGIEECWMSOGGIIEIGEKQGKQ_@GSIWGYUgAMm@[{AMm@UgAI]Ke@Qo@Ss@I[_AoDQm@EKCIEMEKGKO[MSMOEEIKIIOOIEGGAAOISMKEMEIEGAKEGEg@Ic@EUC]Ee@E{@M??ST?@ABA@AB?B?BA@@B?D?BBJDRp@tAf@bAHPJXBDJZFRBLDTN|@BPBHBH??@@@?@??@@??@@??@@??@@??@@@?@@@?@?@?@?@?@?@?@?@?@?@?@A@?@A@?@EBC@A?C?A@CAC?EACCK@S?U?I?M?e@@QAe@GQCy@KqCa@}AQe@G]GIAa@GMAi@G?ASAG?E?A@C?C?EBE@??EGCCCCECCAIAkC]oC]QC[EI???OA]?_B?mAAWA]ASE?@A??@?@A@?@A?A@A?A?A?A?AAA??AAA?A?AA??A?A?AqDa@wAOw@K",
"vehicleClass": "A",
"excludeToll": true,
"departureTime": "2020-12-16T03:09:01.249Z",
"accuracy": 30
}
I used another polyline data, sent a request, and returned successfully.
{
"polyline": "",
"vehicleClass": "A",
"excludeToll": true,
"departureTime": "2020-12-16T03:09:01.249Z",
"accuracy": 30
}
My polyline data indicates an error, which is caused by the backslash "". It is correct to replace it with “\”.
Hi jxeeno and terencekhoo
We checked the production environment log and everything seems to be normal now.
Thank you very much 
Regards,
Mike