Hello every one,
I am still struggling with CDM files reading…
Do you know why Header > messageId field is modified from :
38755_conj_09320_2014251115221_2491611321055NR
to
38755 CONJ 09320 2014251115221 2491611321055NR
It has removed the underscores.
I would expect that this value is not modified at reading ?
What do you think ?
Best regards,
Anne-Laure
In all CCSDS files, there was a statement like:
In value fields that are text, an underscore shall be equivalent to a single blank.
Individual blanks between non-blank characters shall be retained (shall be significant) but
multiple blanks shall be equivalent to a single blank.
We interpreted this a long time ago as: we should replace ‘_’ with ’ '.
However, during some discussions with the CCSDS navigation group, it was agreed that this should not happen and ‘_’ should remain. So we changed it back in ODM and ADM. We probably forgit to do it in CDM.
See commit d6b3e08c for how to change this.
The change is applied to CDM. However, the change is only in develop branch. Therefore, we can’t see it because we’re using Orekit 11.3.3. Version 12.0 will fix the problem.
We definitely need this 12.0 
Bryan
12.0, the version that will break every existing code 
Thanks to every one! I will cherry pick that commit to make it work on my project.
Ok, I have the same problem with CdmMetadataKey.OBJECT_NAME.
Do you think the same fix must be applied ?
Yes, it applies.
You can look at CCSDS specification and check if the entry is set to “free text”.
I did not find a clear “free text” mention but:
In the example, there is always a space 
I also quoted this :
In the value fields for the keywords ORIGINATOR, MESSAGE_ID,
OBJECT_DESIGNATOR, CATALOG_NAME and INTERNATIONAL_DESIGNATOR,
values shall be given as alphanumeric text. The underscore ‘_’ and dash ‘-’ may also be used.
More generally, I am wondering if it is normal that Orekit changes values at reading.
At writing, it makes sense as Orekit is kind of the author of the generated file.
In the case of a file not matching the standard (written with another application), it is more simple to investigate the wrong values if we are sure they are the values from the file, unchanged at reading.
(just a thought)
We also change the numerical values as we enforce SI units and CCSDS enforces km, km/s and degrees. So I would say text normalization is simply the text version on units conversions.
But it is also just a (different) thought
Totally agree with SI units!