Back to using the SP3 parser, and I may have an issue with several sp3 files from NASA’s CDDIS website. This is not an issue with Orekit, so I’m trying to see if others have encountered this!
The Problem
Some files designated as format-c compliant include an extra comment line (totaling 5 instead of 4 allowed). This is caught by Orekit and an exception is thrown. Reading the exception error and the standard helped to pinpoint this issue.
The Workaround
Manually changing the designator to d in the first row of the file and keeping the 5th comment line, or keeping the designator and deleting a comment line is the workaround. Orekit will gracefully handle the format identification, and will be strict with the format compliance in the second case!
The input file is attached. The exception thrown when trying to use the line below follows: SP3 sp3 = parser.parse(new Datasource(myFileObject));
org.orekit.errors.OrekitException: invalid header entry comments "/* …" in file myTest.sp3 (format version c)
at org.orekit.files.sp3.SP3Header.validate(SP3Header.java:164) ~[orekit-12.0.jar:na]
I opened a ticket with CDDIS support and look forward to their response.
Have you encountered such an issue? Or is this a false alarm?
Thank you Rongwang @lirw1984 for pointing me to the code and your workaround!
I’ll keep coming back when I get news as my ticket updates.
I appreciate the thorough checking mechanism of SP3Header.java. With an ill-defined input, automated sp3 parsing from that source becomes cumbersome…
Thanks to the amazing help from the CDDIS support center, it turns out that not all SP3 files found in CDDIS are created equal!
The above artifact has shown up for the STELLA satellite. Now, according to the response from the CDDIS support experts:
The ILRS Analysis Centers all contribute to the orbits for LAGEOS and ETALON but not Stella or the other LEO satellites. The LAGEOS and ETALON are version controlled and the current version is v70 although I believe early next year they will be switching to v80.
Notice that the problematic file version is V00 (part of the name of the attached file)
The support representative continued:
For the LEO satellites including Stella, the orbits are provided by UKRI/NERC/British Geological Survey Space Geodesy Facility (SGF)onlyand they may have gone with v00 to show that it’s not version controlled.
Then, in a follow-up, the representative mentioned the following:
I’ve reached out to the ILRS analysis center representatives and they noted that the v00 files are not official products. They’ll discuss at their next meeting about any format changes but in the meantime, please process the SP3C files as SP3D files.
Final thought: Knowing that V00 is not officially versioned controlled is great news because this is part of the name of the file (which follows a strict convention) and can be easily evaluated. Therefore, any user can carefully proceed with the parsing of such files by opening the file and changing the format from c to d (in a temporary file or otherwise) and continue with using the SP3 parser, or some other way.
I have created issue 1294 for this and provided a fix.
The idea is to set up a DataFilter that can be added to a FiltersManager in order to filter the DataSource when they match the names of wrong files. When these files are found, the filter is inserted automatically and will change the first line, replacing the ‘c’ format marker by a ‘d’ format marker.
Wow @luc Thank you so much for this new enhancement and such a speedy implementation!
It will help a lot with automated parsing for files, and the design with the filters helped me to further understand their design and how extensible they are
