CRG Data Type: double precision road data practically unused

[HeyImJordi]

The CRG standard supports road data to be written as double precision values to a CRG file.
The two data types which indicate the data section to be of type double are:

• KDBI
• LDFI

This increased precision is practically unused because after reading the road data from file it is cast
to the single precision floating point type.
There is one exception. The C-API stores the refline angle phi as double precision floats.

Solution: Properly implement support for road data of double precision floating point type.

This would very likely result in a big overhaul of the API implementations.
Therefore fixing this issue should have a lower priority

[tbleher]

Before we implement this, I think we should understand if people would use double precision. Float has 6-7 digits accuracy, so if you measure a road at say 500m height, you still have sub-millimeter precision. I did not have any user requests so far about higher accuracy. One alternative would be to mark the double precision types as deprecated.

[CarawaySeed42]

Before we implement this, I think we should understand if people would use double precision. Float has 6-7 digits accuracy, so if you measure a road at say 500m height, you still have sub-millimeter precision. I did not have any user requests so far about higher accuracy. One alternative would be to mark the double precision types as deprecated.

I personally would have only benefited from storing the heading angle as double precision floats to reduce the error build up for long CRGs. This is an issue that a provider of CRG data is more likely to run into, than a CRG user.

Marking the double precision types as deprecated would require a change to the OpenCRG Standard and to the implementation
but it has the best (lowest) cost-benefit ratio.

[tbleher]

I personally would have only benefited from storing the heading angle as double precision floats to reduce the error build up for long CRGs. This is an issue that a provider of CRG data is more likely to run into, than a CRG user.

Good point! I can see that storing the heading angle as double would be helpful. For that case it would be great if different columns could have different precision (store heading angles as double, but heights as float). This would reduce the storage overhead (relative to using double everywhere) and increase precision (relative to using float everywhere). But this would probably be a larger change to the standard?

[CarawaySeed42]

Yes, it would be a larger semantic change to the standard. Definitely a topic for 1.3 or later.
The necessary changes to the implementation and the standard's specification should be very managable. The specification does not describe the double data types very detailed.

[jorauh]

There is some useful application generating (small) crg file snipplets out of other applications, stiching them to each other to generate one (large) crg file in matlab conserving precision by intelligently generating heading, banking and slope before cast to float data types. (Doing a simple cast may result in precision problems, e.g. for heading).
For any further evaluation of a crg file (in matlab and c-api) , float precision will be sufficient. So the double data types are only relevant for some few matlab routines manipulatiing crg files.

Except from that special use case, the clear text crg representation with float type (which was availble in the OpenCRG predecessor) lacks presicison with only 4 digits mantissa accuracy. So converting a binary crg file to a clear text version would immediately result in precision problems. This was the reason clear text files are always of double type, while binary files are float/single.

I suggest to keep the double types as is.

If juged necessary we could write some lines of text to explain the limited use (or even provide a sample for the intelligent stiching approach).

[CarawaySeed42]

If juged necessary we could write some lines of text to explain the limited use (or even provide a sample for the intelligent stiching approach)

The proposed "solution", stated in the original issue, is not the solution I want to see implemented short term. I did not make that clear.

The specification states that the CRG file can contain double precision data defined by KD_Definition. But the specification should also make it clear, that the Matlab- and C-API can read double precision floating point data but do not retain this precision and internally cast it down to single precision float (exception C-API heading angle).

The specification is confusing to readers in regards to what the CRG format supports and what the API supports/how it is handled. When I first saw "KDBI", I thought I can create double precision data CRG files using the Matlab-API, which is not the case.
-> You can use double precision but not with the APIs