OpenLR Live Traffic: Last Update Failed "OpenLRCache table is empty" & "Failed to retrieve traffic data"
Hi,
Environment: ArcGIS Pro 3.5.4 / TomTom Intermediate Traffic Data for Hong Kong
I'm working to integrate TomTom OpenLR Live Traffic feed in ArcGIS Pro.
Following the instructions published on the "Work with Live Traffic" article,
- I've successfully created a compliant network dataset based on TomTom Multinet (Classic) data.
Compliant: network dataset has historical traffic and all the required attributes - I skipped step 4 and 5 because they are not relevant to me
- I configured the "Traffic Service" "Traffic Feeds" and checked "Hong Kong"
- I left "Use TMC Live Traffic" unchecked.
- I clicked "OK", saved, and created the corresponding .traffic file.
- I closed and restarted ArcGIS Pro,
Upon opening the project file, there appears to be traffic data!
I checked the traffic cache directory and there's stuff there too.
Horray? - I opened the "Traffic" tab in the Network Dataset Properties for my network dataset
- The Live Traffic Data Status shows:
"Last update failed" and the following messages:
***************
Current time : 11/18/2025 5:46:52 PM
Last Updated : None
Start Window : None
End Window : None
Speed Data Available : False
Road Closure Data Available: False
Messages warning. Traffic speeds not updated because N_1_OpenLRCache table is empty.
warning. Failed to retrieve traffic data.
"lastUpdatedMessages": [
{
"description": "Traffic speeds not updated because N_1_OpenLRCache table is empty.",
"type": "warning"
},
{
"description": "Failed to retrieve traffic data.",
"type": "warning"
}
Question 1: Is this a bug??? What does this error mean? How can I fix it?
I ran procmon and tcpmon to watch Pro and yes, indeed it was able to access the tomtom traffic feed server.
Not to mention there appears to be traffic data in map view ... So clearly Pro is lying to me here 😅.
Question 2: The document says "The appropriate network attributes for Functional Road Class, Form of Way, Travel Direction, and Length" How do I configure the Network Attribute Mappings? What is the correct workflow for this?
Question 3: I think my scenario is the "access to traffic feeds from a data provider such as TomTom" option (as documented) but the workflow seems to forget to talk about this. I see data in the map but all indicators shows red and errors (see attached "BuildOpenLrCache" and "Live Traffic Data Status" screenshots). How can i reliably know Pro fetched the data? Are these error indicators bugs in this part of the product?
Question 4: I have access to the TomTom incidents data which I also configured in the .traffic file but it seems like Pro didn't bother to fetch that.
a) How can I make Pro fetch and more importantly use the incidents data?
b) How can i ensure the Route solver will use the traffic data as a factor in its calculation?
c) How do I incorporate the incidents data for incorporation into Route solver?
Many thanks,
Derek
Quick answers to some of the above
Q1
- give the files in the openlr.75eaa3e... folder it does not look like it is pulling down file, you should have files of the form "speed.*.dat" files
- I'm assuming you configured historical traffic from the multinet data. So if you are seeing traffic it is probably the historical.
Q2
- so the attribute mapping as shown in the screenshot in the help is from the SMP data we create (from a different version of TomTom data )
- As in the dialog shown of the OpenLR attribute mapping in the help they point to descriptor attributes "OpenLR FRC", "OpenLR FOW", and "Travel Direction" (and distance).
The data you have needs to have attribute that adhere to the OpenLR spec, in the help under "Configure OpenLR live traffic from a traffic service" it has a table that has a link to the OpenLR spec pdf.
Although Mulitnet classic has FOW and FRC I don't believe they are the same as what is defined in the OpenLR spec. And I'm not sure about Travel Direction in Mulitnet classic yet.
As an example, the esri SMP date we create has specific attributes for these and their definitions are below. But the source data is from not Multinet classic, and I believe during processing of the raw data these might be created (that is the source data we use might need to be manipulated to adhere to what OpenLR needs)
Let me see if I can find out about the Mutlinet classic re the attributes it does have. The first steps are to ensure the streets data has the correct values for OpenLR, then setup the maps.
Looking a the above some more when you ran the `BuildOpenLrCache` you got the error
I don't think the Mulitnet values out the box could be used but even so I don't believe you should get that error. The tool should run but probably not find many or any matching OpenLR string to features.
Can you provide the .traffic file you use? But REMOVE your apikeys from the urls, similar to the way the help shows it, e.g. <APIKEY> vs actual key, like below
ffUrl": "https://cert-traffic.tomtom.com/tsq/hdf-detailed/MEX-HDF_DETAILED-TMCOPENLR/<APIKEY>/content.proto?flowType=ff",
@FrankK wrote:I looked at the multinet data regarding the fields need to create the network descriptor attributes.
1) for the Functional Road Class you need a new feature class attribute, something like OpenLR_FOW,
And then I believe its values can be mapped as below from the MultiNet FOW:
- FOW=1 --> OpenLR_FOW=1
- FOW=2 --> OpenLR_FOW=2
- FOW=3 --> OpenLR_FOW=3
- FOW=4 --> OpenLR_FOW=4
- FOW=8 --> OpenLR_FOW=5
- FOW=10 --> OpenLR_FOW=6
- all other FOW values --> OpenLR_FOW=7
Okay, implemented and will put it in the field script evaluator:
More to come as i find out more ..
Hi @FrankK
More debugging fun ... :
Event time="Fri Nov 21 15:18:28.895" type="Error"
HTTP Status 406 returned when downloading
https://cert-traffic.tomtom.com/tsq/hdf-detailed/HKG-HDF_DETAILED-OPENLR/---APIKEY---/content.proto?...
Details: Accept-Encoding header must be present and support gzip.�x8np$�@~ۮ�
Then I noticed your sample .traffic file has some interesting additions:
"acceptGZipEncoding": true,
"tdsCompressionLevel": 5,
These are not documented in https://pro.arcgis.com/en/pro-app/3.5/help/analysis/networks/live-traffic.htm
How can we ensure these get properly added to the documentation?
Anyway, continuing ... So I plugged them in and ...
But it returns this:
Processed Matched: 0 Unmatched: 3431 Already cached: 0 Outside extent: 0 Removed: 0 Total: 3431
And in the Network Dataset properties - after running "BuildOpenlrCache" gp tool:
So - in summary:
- Through a lot of instrumentation in Pro, found out all paths leading to getting the traffic data from TomTom resulted in a HTTP 406 error
- Specifically, the server side is looking for a "Accept-Encoding" key with the corresponding value "gzip"
- Added the (undocumented) "acceptGZipEncoding" and "tdsCompressionLevel" to my .traffic and BuildOpenlrCache now shows success
Questions:
- Perhaps can we log a bug / enhancement in the product to surface such errors more clearly? This costed me 2 weeks. (feel free to tag me for the bug credits!) 🤣
- Would you have a cheat sheet /answer card for the OpenLR to Multinet Classic (Network Dataset) field data mapping? 😅
- How do I find out how to align the OpenLR field values with the road network (multinet classic)?
- For this Live Traffic functionality, what is the recommended source road network datasets for TomTom live traffic integration?
I thought ... "I have TomTom traffic data ... Hmm, maybe I should use MultiNet" makes sense but maybe not?
Thanks so much
Derek
Hi @FrankK
Apologies for the delay - Spent some time to take a deep look into this and wanted to share some findings:
@FrankK wrote:Quick answers to some of the above
Q1
- give the files in the openlr.75eaa3e... folder it does not look like it is pulling down file, you should have files of the form "speed.*.dat" files
I can confirm yes, it does look like the OpenLR speeds info file wasn't created:
Here is some telemetry from the ArcGIS Pro Diagnostic Monitor;
Specifically, I had the map with the network dataset open and ran the "BuildOpenLRCache" geoprocessing tool.
(Of interest: a lonely untagged "Parse error" entry)
