SP3 Parser Crash


#1

Hi,

I am a OREKEIT newbie, therefore sorry if my question is stupid.
I am trying to parse a SP3 ephemeris file using the class SP3Parser.
Unfortunately, the method “parse” crashes for each file I used.

My code is very very simple:

        SP3Parser tSP3Pars = new SP3Parser();
        try {
            SP3File pFp = tSP3Pars.parse("C:\\Tmp\\esa20056.sp3");
        } catch (IOException ex) {
            Logger.getLogger(ConvertorMainFrame.class.getName()).log(Level.SEVERE, null, ex);
        } catch (OrekitException ex) {
            Logger.getLogger(ConvertorMainFrame.class.getName()).log(Level.SEVERE, null, ex);
        }

I have downloaded a SP3-c file on standard website and i have checked the consistency of the file.

Thanks for your support.


#2

Could you tell us the exception message you get during the crash and if possible
join the SP3 file (if its content is not confidential, of course)?


#3

Thanks for your prompt message.
Sorry, but i don’t know how to send you the file. I tried to copy/paste it here, but the message size is limited…
Actually, i have tested many sp3 files from the website: ftp://cddis.gsfc.nasa.gov/gnss/products and the error is always returned.

I have also tested the method SP3File parse​(InputStream stream) -> same result.

And here is the returned error:


#4

Hi gmoura,

To avoid spam, Discourse (the forum engine) gradually grants rights to users. According to this policy, new users are not allowed to attach files to their messages. I just upgraded your « trust level » to grant you this right. So, you should be able now to attach the log file to your message.

Regards,

Sébastien


#5

Sorry, but it stiil does not show any icon to upload files. I tried to upload the file as an image but as it is not an image it does not work… Here is my editor:


#6

It was the content of the exception ex) in your code that would be more helpful. The code to catch it does
not really bring much information. As I read it, you log the exception somewhere, so it probably ends up in
some log file.

First possible problem is that on the cddis ftp site, despite the directory for week 20056 already exists,
there are no files there yet, which is expected since week 20056 will be in year 2364 (and even week
2056 is in the future, at beginning of June 2019). So I could not file the exact same file that triggered
the error.

I tried to download one of the file with a similar name, but for available data. I used esa19986.sp3.Z, which contains data from April 2018.

Another possible problem is that as the file is compressed as a .Z file, it should be uncompressed before
reading it. Orekit can help there with something like:

  NamedData raw = new NamedData(fileName, () -> new FileInputStream(fileName));
  NamedData uncompressed = new UnixCompressFilter().filter(raw);
  SP3File file = parser.parse(uncompressed.getStreamOpener().openStream());

However, I don’t think this is your problem since your initial post does not have a .Z so it
seems you already uncompressed it before attempting to load it.

After having done this, I tried to directly load the esa19986.sp3.Z and got a parsing error.
The error message related to an unknown orbit type.

Looking at the uncompressed file content, I saw the orbit type near the end of the
first line was set to BHN. There are only four predefined orbit types in the SP3 file
formats (even in the newer version d of the format): FIT (fitted), EXT (extrapolated
or predicted), BCT (broadcast), and HLM (fitted after applying a Helmert
transformation). Other types could potentially be added. It seemed ESOC did that
and defined a new BHN type. I don’t know what BHN stands for.

Adding just a new entry for BHN in the enumerate SP3OrbitType at https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/files/sp3/SP3File.java#L65 allowed Orekit to
parse the file successfully.

Could you:

  1. try to add the BHN entry and check if this fixes the problem for your files?
  2. find the definition of this BHN type?

#7

You are right. Only images were allowed. I just modified the Discourse configuration to allow upload of any type of file.

Sébastien


#8

First possible problem is that on the cddis ftp site, despite the directory for week 20056 already exists,
there are no files there yet, which is expected since week 20056 will be in year 2364 (and even week
2056 is in the future, at beginning of June 2019). So I could not file the exact same file that triggered
the error.

Sorry, I forgot that the last digit was the day number, so esa20056.sp3 is day 6 of week 2005, i.e. 2018-06-15. This file parses correctly when adding the BHN entry. Note that if BHN is another way to describe an already supported type (like BCT for example), then we could also ensure we parse it
as the existing type. We already do this for some sp3 files that use “EST” (for estimated) instead of “FIT”.

If adding this support to the BHN key in the file solves the problem for you, I suggest that you
open an issue on the forge at https://gitlab.orekit.org/orekit/orekit/issues.


#9

Dear Luc,

First of all, thank you very much for your very quick reply.

  1. I did unzip the sp3 and i only play with the unzipped version.
  2. Sorry for the lack of information regarding the exception, but my code does not catch anything and crashes immediatly. I think that i would be able to get more information but I am very very poor in Java (and i just want to read a SP3 file without learning the beauty of this langage :-)) so i sent you what i got without long investigation.
  3. The solution you suggested does fix the problem. However, I did not follow strictly your advice. Because I only use the jar file (without the sources) and i don’t want to recompile the solution, I just change in my file “BHN” by “FIT” and it seems to work. You suggest to add “BHN” in the enumerate of the class, therefore i assume that there is no specific “BHN” part in the content of the file.
  4. I will ask my ESA colleagues what BHN means and i will contact you afterwards.
  5. I am going to raise the bug in your system.

Thank you very much !
Best regards,
Grégory


#10

Thanks, it works now !