TomTom OpenLR Binary Version 3, Differences and mistakes of the OpenLR Whitepaper and the TomTom Demo Tool

Question

I am currently trying to decode OpenLR binary Strings (version 3) as specified in the OpenLR Whitepaper (version 1.5, rev 2) which can be found at the OpenLR Association website.

Unfortunately, while comparing the results with the TomTom Demo Tool.

I had to find some key differences, mistakes, and missing information. For example, decoding this binary String with the Demo Tool (enable show decoding steps)

Cwl3syVRnAELHgor/6YBBw0DgP61AQwnDGz94AEIGQe1/j4BCj0TSv9NAXYZJw==

shows that:

1. Negative byte values for relative coordinates have to be flipped and 1 added to obtain the actual value. The OpenLR Whitepaper is missing this step.

• is this step also necessary for absolute coordinates or only for relative coordinates?

2. The calculation of relative coordinates is described to be the same calculation for absolute coordinates

   (int - (sgn(int) *0.5)) * 360 / 2^resolution
   

(resolution = 24 for absolute, 16 for relative), but it gets obvious that this equation does not lead to the correct value.

The calculation would lead to a value of -0.49 not -0.0009 using the values and formula as shown. Instead, for relative coords, the (eventually flipped and 1 added) concatenated byte value has to be divided by 10^5 to obtain -0.0009.

3. For Location Reference Points n>0,n<2 (the second LRP, thus first relative coordinate) the final addition of the values is somehow correct, but for n >=2 the differences get bigger, and thus the result is wrong, it can be easily seen in the demo tools calculation:

the addition of the correct decoded byte values is simply wrong:

This leads to big differences in the final location. The resulting value of the demo tool is correct, as the locations described follow the streets while using the correct sum would shift them off the street. But the equation is missing some key aspects.

Also, the OpenLR Whitepaper describes adding the relative coordinate value to the previous LRP.

(comparing the values used in the demo tool shows that the first LRP is beeing used instead of the previous LRP)

• Which formula is the correct one? The Demo Tool generated correct values but uses wrong calculations.

Edit, for the third LRP I found using the previous LRP leads to the value calculated by the online tool (which shows the first LRP value to be used).

For reference and comparison some examples:

Binary String of above example:

Cwl3syVRnAELHgor/6YBBw0DgP61AQwnDGz94AEIGQe1/j4BCj0TSv9NAXYZJw==

Differences:

Using the correct sum of relative coord value and LRP 0 (first 2 LRPs are correct, then it gets worse, can also be checked by verifying the sum of the demo tool for LRPs 3-6):

The demo tool uses a wrong calculation but the final values shown are correct as they follow the street. It seems to be mirrored along a horizontal line going through the second LRP (first relative coordinate):

I'd be very thankful for any hints on how to solve this correctly.

Steps done:

I wrote a decoder according to the whitepaper and contacted TomTom Support who asked me to discuss this issue here. I double-checked the calculations and found mistakes in the demo tool as well as in the OpenLR white paper specification.

Answer 1

I solved it. The calculation for relative Coords:

If the first bit of the concatinated bytes (of lat or lon) is 1 (negative value):

byteValueRel = bytevalue - 2^16

In any case divide it by 10^5:

byteValueRel = bytevalue/(10^5)

The resulting relative coordinate is the sum of the previous LRP value and the calculated relative value:

previousLrpValue + byteValueRel