add rx position at which the corrections have been computed

[plutonheaven]

Some corrections are computed assuming a receiver position. This information should be provided in prx.

I think the default position that we consider is the rx position from the header.

[plutonheaven]

More details on why I think a per epoch receiver position is an additional required information.

First, the RNX header field APROX POSITION XYZ is optional, so our code should not rely too much on it.

Then, if we process a RNX file from a long dynamic data collect (car/plane moving across a country), the receiver position may have changed significantly, leading to significant impact on the correction computation (atmospheric, Sagnac).

This position could come from

• the RNX OBS header if available for fixed data collect
• a Least Squares solution with uncorrected observations
• a reference trajectory when provided (but this would be a hassle to deal with non-standardized reference trajectory files...)

The Least Squares solution is probably the most robust, self-contained one.

[jtec]

@plutonheaven I like the analysis a lot!

Having the option for a reference trajectory would be great though - it would provide the possibility to bake a ground truth directly into the CSV file, which is great for unit testing.

We could require it to be a very simple CSV file with a header

gpst_s, x_ecef_m, y_ecef_m, z_ecef_m, dx_ecef_m, dy_ecef_m, dz_ecef_m

where the velocity columns can be empty. We'd then linearly interpolate the columns to get the reference, as the timestamps won't exactly match the receiver observation times.

[jtec]

On second thought, probably easiest to always run a LSQ in between ephemeris evaluation (we get time of emission from code obs) and computing those corrections that need user position.