[PROJ] Dealing with epoch and transformations

[Greg Troxel]

Javier Jimenez Shaw via PROJ <proj at lists.osgeo.org> writes:

> If I connect to this NTRIP service
> https://support.swiftnav.com/support/solutions/articles/44002386941-configuring-your-receiver
> it says explicitly that "Skylark Nx RTK uses ITRF2020 reference
> frame."
> Does it mean that the coordinates that I measure today do have an epoch of
> 2024.x (today's epoch), or the epoch of those measurements is 2015.0 (the
> epoch of ITRF2020
> https://epsg.org/datum_1322/International-Terrestrial-Reference-Frame-2020.html
> )

FWIW, the RTK network I use documents "NAD83 (2011) epoch 2010.0" which
is unsurprising in the US, and a static datum -- avoiding all of this.

I would say their statement doesn't cleanly mean either of those, and it
would be reasonable to ask them to adjust it to say epoch 2015.0, some
other fixed date, or "today", which I think is sometimes written "epoch
of data".

There's a larger question lurking, due to their reference stations
having velocities in ITRF2020.  I believe that is a separate issue from
the motion of ITRF2020 itself.

I would also think that if you have another service that uses a
plate-fixed datum, you would be able to compare and determine if they
are dealing with their station velocities, as few cm * 9 years should be
resolvable.  With an F9P, repeat occupations (days apart), that each are
a 30s average, cluster within a 4 cm diameter.  That's with a hand-held
pole with a level, and some tree cover.

Thinking about how the network operates, they need to do static
solutions to determine coordinates, and those could reasonably be in
either ITRF2020 2015.0 or ITRF2020 day they do the observations.
(Really, they should be and probably are doing static solutions
repeatedly.)  With either, they could transform to 2015.0 or today's
epoch.  Then, they might need to apply station velocities and load the
reference station coordinates.

Or does RTCM contain station coordinates and a date and velocities?
Because my network is a plate-fixed datum with a fixed epoch
(because... the datum is not quite plate fixed!), I have so far not
understood this.

It's interesting to consider what GPS does, which as I understand it is
to compute reference station coordinates once a year and use them over
the year.  But the link from reference station coordiantes to
clocks/orbits to user coordinates has a big enough error budget that
this 1 year step of a few cm -- in varying directions for varying
reference stations -- is almost certainly not detectable.

> If I want to transform from that reference system (ITRF2020) to, let's say,
> ETRS89 or NAD83(2011), should I add an epoch? which one? where? what
> happens if I do not set any?

My somewhat hazy understanding is that ITRF2020 without a specified
epoch means 2015.0.

Does proj have plate motion models, to be able to answer not what a
coordinates a point in space has, but a point fixed to the ground?

> I have the impression that I could convert from one epoch to another for
> the same CRS, something like this
> PROJ_DATA=data ./bin/projinfo -s EPSG:9989 -t EPSG:9989 --s_epoch 2015.0
> --t_epoch 2020.0 -o proj
> Candidate operations found: 1
> -------------------------------------
> Operation No. 1:
>
> unknown id, Null geographic offset from ITRF2020 to ITRF2020, 0 m, World.
>
> PROJ string:
> +proj=noop

I think we need to really understand how ITRF2020 itself, vs moving
reference stations, evolves over time.