I am trying to understand if there is a way to add custom units to the CCSDS OPM parsing (preferably without subclassing…). I have some cases with consistent uppercase unit in a OPM file (“KM”, “DEG”, etc). I find that one can alias a Unit, but can these be inserted into the default PrefixedUnits somehow? I am using ParserBuilder().buildOpmParser() and then parser.parseMessage(source). Would this be rather solved with the .withFilter method on ParserBuilder?
I would strongly suggest to have the file producer respect the standard and produce units as specified. Case is important in units, it has a meaning.
For example, “ms” is milliseconds whereas “Ms” is megaseconds. “K” is Kelvin (but we do not support temperatures yet in Orekit, maybe in the future), whereas “k” is kilo prefix. There is a similar case with a supported unit in Orekit: “N” is Newton but “n” is prefix for nano.
In the AEM standard, if you look at section 7.8.1.1, it reads “For clarity, units may be included as ASCII text after a value, but they must exactly match the units specified in Table 3-3 (including case).” I could not find any similar wording in OPM, but the various tables list the units with some specific case, and they refer to SANA registry.
We already have two strange cases in the units parsing, that were mandated by CCSDS (and are not correct from SI point of view). The first one is “as” which is parsed as arc-seconds, whereas in SI world it should be attoseconds. The second one is “Pa” which is parsed as Pascal, whereas it could be interpreted as Peta-years (“a” is the standard abbreviation for year, despite CCSDS also allows “yr” for that). For these two cases, we had to put these predefined units properly ordered in the list so the interpretation we want is before its alternative.
Putting different alternatives with aliases will most certainly wreak-havoc in the parsing. Doing so is opening a can of worms.
If you cannot have the units case changed but if the files indeed does use CCSDS units (kilometers for distances, degrees for angles, …), you may try to use parserBuilder = parserBuilder.withParsedUnitsBehavior(ParsedUnitsBehavior.IGNORE_PARSED). However, I am not sure if units will be parsed first (so they should at least be syntactically correct) and ignored later or ignored before parsing.
Thanks Luc for the clarification and context. Unfortunately it seems not possible to change the origin (old systems…). Making all CAPS in general would really not be a good idea then, I may go for an approach to do a text replace function to CCSDS standard on these particular files and units before ingestion…
I did check the IGNORE_PARSED and it still check that units are known. Maybe as an future update, it would be more expected behaviour if it just ignores the unit fully?