Traffic flow API returning garbled geometries

The traffic flow API appears to be returning garbled geometries. It was fine yesterday.

For example today vs yesterday

I just checked this location and do not see those artifacts.

Are you querying specific zoom level?

If you use the example vector flow tiles call from the api explorer.

https://api.tomtom.com/traffic/map/4/tile/flow/relative/12/1207/1539.pbf?roadTypes=[0%2C1%2C2%2C3%2C4%2C5%2C6%2C7%2C8]&margin=0.1&tags=[traffic_level%2Ctraffic_road_coverage%2Cleft_hand_traffic%2Croad_closure%2Croad_category%2Croad_subcategory]&key=*****

Yesterday all the geometries parsed as single linestrings, today a lot seem be nonsensical multiline strings? For example

tags: 0
tags: 68
tags: 1
tags: 13
tags: 3
tags: 3
type: LINESTRING
geometry: 9
geometry: 128
geometry: 215
geometry: 50
geometry: 35
geometry: 44
geometry: 43
geometry: 44
geometry: 11
geometry: 16
geometry: 71
geometry: 76
geometry: 11
geometry: 16
geometry: 27
geometry: 28
geometry: 9
geometry: 8204
geometry: 2928
geometry: 18
geometry: 116
geometry: 376
geometry: 60
geometry: 136

Are you using your own algorithm do draw those data?

Hi, yes i am. Is there an sdk with a reference implementation? The thing is the file I downloaded two days ago still renders perfectly, however the data i receive now seems like a garbled mess with the same code.

This file (downloaded two days ago) renders perfectly

https://file.io/Nt1cWRGePRBH

This one (downloaded this morning) is all jumbled up

https://file.io/iN9Ubw5BKTbj

We are not showing internals of our SDKs.
There was a change introduced in the service recently. That change was introduced to shrink the size of tiles.
From our perspective probably MoveTo command may be wrongly implemented on your side.

Is there any documentation on the changes? I am following the current online docs exactly and the file from two days ago still renders without any problem.

Unfortunately the change is not documented.
We will investigate this further.

Thanks. If it is any help the geometries which still decode to a single line string (that is there is a single MoveTo command followed by a single LineTo command) still render correctly as below.

It appears that the when the count in the LineTo command does not consume all the remaining data the resulting MultiLineString does not make sense.

Hi. Sorry, realised my bad. I didn’t realise that each MoveTo command is still in reference to the previously reach location, i had assumed they were absolute.

I guess the API has been changed to bundle together segments with the same underlying values and this was throwing my code.

Apologies.

Exactly. MoveTo refers to the previous point, even if it is a new line.

1 Like