Question
Here I am again with another comment
There is a case that is not considered by the
SP3EphemerisStore class.
According to the SP3c-manual [1], line 24 of the SP3 format might contain
bad or absent positional/clock values (see 'Discussion of the SP3-c Format', paragraph Line 24).
That means that these values are set to 0.000000 (positional) and 999999.999999 (clock). If this values are considered in the interpolation procedure then the results of
gpstk::TabularEphemerisStore::getXvt()
become
unreliable. This is the case of the actual implementation of
SP3EphemerisStore.
Thus I come up with the proposal that before
SP3Data
object is added to the 'store' (see
gpstk::SP3EphemerisStore::loadFile(),
line 84 ) a conditional expression should be introduced as follow:
SP3Data rec;
while(strm >> rec)
{
// if bad or absent positional values then continue
if (rec.x[0] == 0.0 || rec.x[1] == 0.0 || rec.x[2] == 0.0)
continue;
// if bad or absent clock values then continue
if (rec.clk == 999999.999999)
continue;
// Ephemeris and clock are valid, then add
rec.version = header.version;
addEphemeris(rec);
}
In this way the ephemeris with bad or absent positional/clock values are skipped and the input for the interpolation procedure returns
reliable results. In addition, the order of the interpolation procedure (i.e., Lagrange interpolation) remains 10 and have not to deal with unreliable input.
However, the affected satellite requires a larger time span with valid ephemeris then the others that are not affected. Thus you might need to add more sp3-file into the 'store' because
gpstk::TabularEphemerisStore::getXvt()
might throw some
gpstk::InvalidRequest.
I hope someone will evaluate this and do the corrections.
Best regards,
Octavian
Reference:
--
OctavianAndrei - 10 Jul 2008
Answer
If you answer a question - or have a question you asked answered by someone - please remember to edit the page and set the status to answered. The status is in a drop-down list below the edit box.
Hi all!
I believe that there is a valid concern here, and I think that the proposed solution is a good first approach.
On the other hand, we should thread very carefully: There are applications (getting common, by the way) that need valid orbits from sp3 files but may use satellite clocks from other sources, so we should not slash out satellite data when clock data are missing.
Maybe dropping the proposed clock filter but adding a "reliability flag" will do the trick.
Regards,
Dago
--
DagobertoSalazar - 28 Jul 2008
--
DagobertoSalazar - 16 Sep 2008