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)

               // if bad or absent clock values then continue
            if (rec.clk == 999999.999999)

               // Ephemeris and clock are valid, then add 
            rec.version = header.version;

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


-- OctavianAndrei - 10 Jul 2008


ALERT! 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.



-- DagobertoSalazar - 28 Jul 2008

-- DagobertoSalazar - 16 Sep 2008

Topic revision: r4 - 28 Jan 2010, YanWei

This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback