Incorrect offset position encoding/decoding

[AndersHGP]

Hi!

According to the OpenLR Physical data format binary specification regarding Line Location.

The positive and negative offset bytes are optional. This means that the negative offset can be found at byte number 17 instead of byte number 18 if only a negative offset is included.
This is not handled currently in the library.

I know this is not clearly stated in the spec but i can confirm that TomTom themselves are delivering data in this way.

[xivk]

Can you refer to the spec for this? I'm not sure if I follow completely.

If I remember correctly the presence of the offsets is determined by the total size in bytes of an encoded line.

[AndersHGP]

Version: OpenLR-Whitepaper_v1.5.pdf
Page 53 of 156
As you can see you have flags in byte 16 indicating if POff and Noff are included.
The thing not so clear here is that the negative offset can be in byte 17 instead of 18 if no positive offset is included. The lib assumes that POFF can always be found at 17 and NOFF at 18.

[xivk]

Ah ok, I see now thanks! 👍

[xivk]

Note to self:

• this can be positioned at position+6 if there is no positive offset: https://github.com/itinero/OpenLR/blob/develop/src/OpenLR/Codecs/Binary/Codecs/LineLocationCodec.cs#L186

• ... and use the flags as stated in the spec to decode positive/negative offsets: https://github.com/itinero/OpenLR/blob/develop/src/OpenLR/Codecs/Binary/Codecs/LineLocationCodec.cs#L85