[Enhancement] Again about sp3parser

Hi, all,

Many days ago, I asked the enhancement of sp3parser to be more smart to read in the orbit files of ilrs(

@bcazabonne and @luc have worked on it and fixed the issue #895. Thank you two very much.

I must say sorry that I do not test the solution in time.

Recently, I tried the new version, 11.3. There are some other issues.

(1) There may be day=0, which is illegal for a DateComponents.
“2022 1 0” means 2021-Dec-31.
“2022 10 0” means 2022-Sep-30.
“2022 11 0” means 2022-Oct-31.

(2) The number of epochs in the header does not match the real number of epochs in the file.
For ilrsb, the number of epoch in the header is 5041, while the real number of epochs is 5040. Fortunately, there is a ‘EOF’ flag.

ilrsb.orb.lageos1.220101.v70.sp3 (616.5 KB)

So, for the DATA_EPOCH, can we expect the following two things:
(1) The START EPOCH of the orbit file and the INTERVAL-OF-EPOCH is RIGHT;

If so, we can do it like the following, instead of parsing it (so there is no need to handle hour=24 or minute=60, and other unexpected situations):

        /** Parser for epoch. */
        DATA_EPOCH("^\\* .*") {

            /** {@inheritDoc} */
            public void parse(final String line, final ParseInfo pi) {
                if (pi.latestEpoch == null) {
                    // the first epoch, use the start epoch of the orbit file.
                    pi.latestEpoch = pi.file.getEpoch();
                } else {
                    // shifted one epoch interval from the latest epoch.
                    pi.latestEpoch = pi.latestEpoch


            /** {@inheritDoc} */
            public Stream<LineParser> allowedNext() {
                return Stream.of(DATA_POSITION);


And for the case of mismatch of the number of epochs, if there is a ‘EOF’, use the real number of epochs instead of the number in the header. Unless, there is no ‘EOF’, and the number does not match, an exception is thrown.

I would still prefer to parse the date and check it against the expected date, with some allowance for discrepancy like checking components modulo 29/30/31 for day, modulo 24 for hour, modulo 60 for minutes and complain if there is un unexpected mismatch.

Could you open a new issue on the forge for this? You should truncate the test file artificially to avoid storing big files in the source archive and keep only a few entries to reproduced the bug pattern.

Hi @luc,

Ok, I created an issue #1014.