Hi all!
I’m using the CDM XML parser (orekit 12) to parse the CDM downloaded from Jspoc but I’m getting errors at each not mandatory empty tag, i.e. if the tags are
<START_SCREEN_PERIOD nil=“true”/>
or
<START_SCREEN_PERIOD />
or
<START_SCREEN_PERIOD/></START_SCREEN_PERIOD>
the error is
org.orekit.errors.OrekitException: value for key START_SCREEN_PERIOD has not been initialized
at org.orekit.files.ccsds.utils.parsing.AbstractMessageParser.process(AbstractMessageParser.java:215)
at org.orekit.files.ccsds.utils.lexical.XmlLexicalAnalyzer$XMLHandler.endElement(XmlLexicalAnalyzer.java:232)
If the not mandatory entries are missing the parser works fine but the problem is that Jspoc inserts
<START_SCREEN_PERIOD nil=“true”/> for the empty fileds!
I tested directly from the orekit unit tests by passing code but I get the same results.
Could you help me to solve the issue? Do you have a workaround?
Thanks in advance.
Sabrina
Maybe this could be done using the fix for issue 991 that has been added last year.
you have one example at line 368 of the OMM parser test, where we replace an empty OBJECT_ID entry.
Thanks Luc,
Your clue did work, but I had to add the filter for all not mandatory tags that could be empty.
Since JSpOC generate XML this way, I believe the parser should be modified to handle these cases.
Best Regards,
Sabrina
Honestly if the file does not satisfy the standard (is the CCSDS clear about that particular field or is there room for interpretation?), it’s more a problem for the provider. Can they be reached to know about this?
well we know the standard, it’s the CCSDS blue book on CDMs, it’s just that I hadn’t yet taken the time to check it regarding that specific field. It says it’s a date and as such must follow the format described at paragraph 6.3.2.6. Here the provider leaves it empty. So I think, strictly speaking, it’s a standard violation. However, it could be argued that Orekit should have a mechanism reading the optional fields that are empty and ignore them or something (rather than throw an exception), in which case an issue could be opened on the forge. Could we have anyone else’s opinion on that? @dgondelach maybe?
I encountered the “issue” with empty fields with the latest Orekit version as well. The Orekit CDM parser does not accept Spacetrack CDMs. Which is a real pity, because of course most CDMs come from Spacetrack.
The CDM standard states (CCSDS 508.0-B-1): 6.2.3.1 A nonempty, valid value must be specified for each obligatory keyword.
The ODM standard states (CCSDS 502.0-B-3): 7.5.1 A non-empty value field must be assigned to each mandatory keyword except for *‘_START’ and *‘_STOP’ keyword values.
Therefore, to me it seems that the non-empty requirement only applies to mandatory fields. So, we can allow empty fields while parsing optional fields. Do you agree with me? Or did I miss some other requirement?
As far as I can see, all empty fields in Spacetrack CDMs are optional (non-mandatory) fields. So allowing empty optional fields while parsing would resolve the Spacetrack CDM issue I believe.
Best regards,
David
PS: Empty fields in Spacetrack CDM XML even have an attribute nil="true", e.g. <START_SCREEN_PERIOD nil=“true”/>. Also, surprisingly, in the KVN version of Spacetrack CDMs the empty fields that appear in XML are not present at all.
In my opinion, Orekit has to be extremely strict when writing, but can be open to format violations when reading.
I remember a few years ago, just after the implementation of the support for RINEX observations files, when we accepted numerous format violations on reading, some of them quite huge!
In that case @sputils6 why don’t you open an issue to ignore empty optional fields in CDMs. @dgondelach if you want to do the same as per the rule you cite for ODMs, please do it. And as always, contributions welcomed.