Following the definition I need to divide the coordinates by 100000 to get the WGS coodinates
[5.2.1.Coordinate pairCoordinate pair stands for a pair of WGS84 longitude (lon) andlatitude (lat) values. This coordinate pair specifies a geometric point in a digital map. The lon and lat values are stored in decamicrodegreeresolution (510, five decimals)]
in fact I get this kind of coordinates after decoding the open-lr data
Coords(lon=135.04869818623044, lat=80.60155034026813)
the coordinates must be in the range lon=4.xxxx lat=50.xxxx
I do not see how I can reach these value from the decompressed 135.xxx and 80.xxx
Is there somewhere an offset to use?
I am using the openlr-js from https://github.com/tomtom-international/openlr-js to decode the open-lr protocol.
We have similar question. We are using openlr python library to decode openlr string to location. I noticed there is a below method that decodes to WGS84 coordinates.
As detailed in Section 7.2 of the OpenLR White Paper v1.5, WGS84 coordinates in an OpenLR byte array are stored in two different formats: absolute and relative. The reason for two different formats is that it saves space: the absolute format requires 6 bytes to represent a lat/lon, whereas the relative format requires only 4.
The “absolute format” reserves 3 bytes for each lat/lon component (i.e. 3 for lat, 3 for lon, 6 bytes in total), and is used in the first LRP to act as a base relative to which the other LRP coordinates are resolved. The conversion of a lat or lon in absolute format is described in section 7.2.1, and consists in essence of concatenating the three bytes to form a 24-bit integer, and then producing the corresponding WGS84 lat or lon value in degrees using the formula at the top of page 45 in the White Paper.
Once the first WGS84 lat/lon is derived, subsequent (if any) coordinates are described with 2 bytes per component (lat or lon). Each component in relative format describes a value to be added to the corresponding component of the previous WGS84 coordinate. The offsets to be added are stored in the “relative format” described in section 7.2.2. The two bytes of a component are concatenated to form a 16 bit integer, whose value is derived by the formula in Equation 3 on page 45. You will notice the value 100,000 appears in that formula. The reference to decamicrodegrees in the White Paper refers to the maximum resolution possible with this absolute/relative scheme: 10 ^-5 degrees, and not to how it is encoded.
As an aside, when OpenLR location references are transmitted textually, they are encoded in one of two physical data formats: XML or binary, base64-encoded strings. However: the OpenLR references in the Intermediate Traffic Feed protobuf are not encoded in a physical format, but rather as an array of raw bytes. These can be easily interpreted programmatically using either the openlr-js JS library (GitHub - tomtom-international/openlr-js: OpenLR implementation in JavaScript) via the Python equivalent (GitHub - tomtom-international/openlr-python: OpenLR library for Python). I can provide more details if needed.
I hope this clarifies things. If not, I would be happy to assist further.