Unable to read OMM generated by Space-Track

Hello!

I was trying to read an OMM file generated by Space-Track but I encountered an error from Orekit saying that the format is unsupported.

Error message

The error message is this one

org.orekit.errors.OrekitException: unsupported format for file OMM file

	at org.orekit.files.ccsds.section.XmlStructureProcessingState.processToken(XmlStructureProcessingState.java:64)
	at org.orekit.files.ccsds.utils.parsing.AbstractMessageParser.process(AbstractMessageParser.java:221)
	at org.orekit.files.ccsds.utils.lexical.XmlLexicalAnalyzer$XMLHandler.startElement(XmlLexicalAnalyzer.java:206)
	at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
	at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)

How to reproduce?

Here a test to reproduce the bug. ExtendedFiles is just an internal class that convert the file to a byte[] array. The file is this one:

omm.xml (2.0 KB)

@Test
public void testImportOmmFromSpacetrackWithoutCovariance() {
    Omm ommFile = new ParserBuilder(QDataContext.getDataContext()).withConventions(Frames.getReferenceIersConvention())
                                                                  .withMu(FdConstants.MU)
                                                                  .withDefaultMass(Propagator.DEFAULT_MASS)
                                                                  .buildOmmParser()
                                                                  .parseMessage(new DataSource("OMM file", () -> new ByteArrayInputStream(
                                                                          ExtendedFiles.toBytes(getClass(), "omm.xml"))));
}

Interpretation

After analyzing the problem, I saw that the issue comes from the XML header. The XML header generated by Space-Track is

<?xml version="1.0" encoding="UTF-8"?>
<ndm xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="https://sanaregistry.org/r/ndmxml_unqualified/ndmxml-3.0.0-master-3.0.xsd">
    <omm id="CCSDS_OMM_VERS" version="3.0">

However, it look like the test runs well if the header is

<?xml version="1.0" encoding="UTF-8"?>
<omm id="CCSDS_OMM_VERS" version="3.0">

Or

<?xml version="1.0" encoding="UTF-8"?>
<omm xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:noNamespaceSchemaLocation="https://sanaregistry.org/r/ndmxml_unqualified/ndmxml-3.0.0-master-3.0.xsd"
     id="CCSDS_OMM_VERS" version="3.0">

So the problem is that there is <ndm> key before the <omm> key.

I’ve look at the Blue Book and indeed, it is not expected to have this (it is only expected for aggregated ODM files). But, since Space-Track is an important data provider and since we still consider that Orekit should be very strict in writing formats, but can be more lenient when reading them, could we find a solution to be able to parse OMM from Space-Track?

Thanks

Bryan

Hey,

This is similar to an old issue from @petrus.hyvonen which was about OEM from Nasa. I dont remember the issue right now but i’ll update my comment later.

update: It’s this one ISS OEM failing in XML format (#1184) · Issues · Orekit / Orekit · GitLab

Cheers,
Vincent

That’s exactly the same issue as Petrus!

I found a solution.

For my case, a simple filter can be added to the ParserBuilder before calling .buildOmmParser:

.withFilter(token -> {
            if (token.getName().contains("ndm")) {
                return Collections.emptyList();
            }
            else {
                return Collections.singletonList(token);
            }
        })

It works well with it.

For @petrus.hyvonen, I recommend exactly the same filter.

So in fact, we can even close Petrus issue because there is already the fix in Orekit with the filter feature