[Proj] Proj4 and Epoch

Chris Crook ccrook at linz.govt.nz
Wed Mar 9 14:32:48 EST 2016



Cheers
Chris


> -----Original Message-----
> From: Greg Troxel [mailto:gdt at ir.bbn.com]
> Sent: Wednesday, 9 March 2016 2:01 p.m.
> To: Chris Crook
> Cc: 'proj at lists.maptools.org'; 'barronian'
> Subject: Re: [Proj] Proj4 and Epoch
>
>
> Chris Crook <ccrook at linz.govt.nz> writes:
>
> First, let me say that your note was from my viewpoint an excellent
> discussion of the issues.  In particular the point about the difference
> between velocities of the frame and velocities of particular stations adds a
> level of complexity that I wasn't thinking about.
>
> But the biggest thing I realized is that there don't seem to be EPSG codes for
> the different WGS84 realizations, so the first agenda item is to resolve
> whether to push EPSG to do that or to model them outside of EPSG or to
> decide that all WGS84 realizations are equivalent for proj purposes.
>
> > I think the following doesn't work ...
> >
> >> So, I suspect you have to transform to the standard epoch in some
> >> frame, and then to another frame, and then to the epoch you want.
> >
> > The reason is that it is the conversion between frames that is time
> dependent.
>
> Yes, I was trying to take that into account, and to let someone use proj for
> part of the work, but do velocities of each frame separately.
>
> What I meant as an example
>
>   Given coordinates in NAD83(2011) epoch 2016.0, transform them
>   (somehow, correctly) to NAD83(2011) epoch 2010.0.   This gets you
>   coordinates that proj just calls NAD83(2011).
>
>   Then use proj to transform to ITRF2008, which I think implies epoch
>   2005.0 as the standard epoech.
>
>   Then transform ITRF2008 epoch 2005.0 to ITRF2008 epoch 2016.0
>
> This is probably not right because it blurs the frame motion vs ground motion
> issues, and I think the conclusion is that this sort of geodetic pickyness is
> beyond what proj is currently trying to or succeeding at doing.
>
>

The last bit of this is the bit that doesn't work, as there is no transformation of ITRF2008 between 2005 and 2016.   The ITRF2008 coordinate of a point may be different at 2005 to what it is at 2016 (because the point has moved within the ITRF2008 reference frame in the mean time), but this is not part of ITRF2008 or its definition.

However the transformation between different global reference frames, such as ITRF2008 and ITRF2000, is time dependent.   That is to say that the transformation between an ITRF2000 coordinate and the equivalent ITRF2008 coordinate for coordinates observed in 2005 is different to that for coordinates observed in 2015.

Most national datums are aligned more or less with the tectonic plate on which the nation is mainly located, and so the transformation between the national datum and a global datum such as ITRF2008 is similarly time dependent.   This is nothing to do with deformation, it is that the coordinate axes of the reference frames are moving relative to each other.

In the past this may have been geodetic pickyness but I'm not sure that is the case now, for two reasons.  One is that there is a trend towards using coordinates with higher precision.  The other is that as GNSS (global navigation satellite systems such as GPS) become more and more accessible much more data is acquired in global reference frames, so conversion between national and global reference frames is a more common requirement.  Possibly a third reason is that the length of time we have had accurate coordinates in GIS databases is increasing and the difference between reference frames over the time span of the data is becoming more significant.

While PROJ itself was originally formulated for map projections (a simple mathematical conversion) it has nonetheless evolved into the de factor coordinate conversion toolkit for the open source GIS software stack, and certainly does handle reference frame conversions to a degree.  So it doesn't make sense to have some other software that is used when your data gets a bit too precise (or too geodetic?) for it to handle.

On the other hand coordinate conversion does become much more ambiguous when converting  coordinates between reference frames rather than between projections - the parameters are not absolutely defined but generally realized by observations, and jurisdictions may adopt different parameters for the relationships between datums.




This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info at linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.


More information about the Proj mailing list