Hi, all,
Many days ago, I asked the enhancement of sp3parser to be more smart to read in the orbit files of ilrs(
https://forum.orekit.org/t/should-the-sp3parser-be-more-smart/1557).
@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;
(2) The DATA_EPOCH is CONTINUOUS and EQUAL SPACING.
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} */
@Override
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
.shiftedBy(pi.file.getEpochInterval());
}
pi.nbEpochs++;
}
/** {@inheritDoc} */
@Override
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.