[PROJ] EPSG v10 update status

Sun Oct 11 13:04:36 PDT 2020

3. Even wrote:

> I don't think the last sentence matches what the authors of standard have in mind (I don't think a datum can be *defined* by a transformation to another datum. a datum exists as such. one may establish transformations to others, but they are not defining. at least for geodetic datums. for vertical datums, some of them are indeed defined by a geoid model that applies to a given geodetic datum).

The National CRS of the Netherlands (EPSG crs: 28992) has its own has datum (EPSG datum: 6289). Since 2000, this Dutch datum IS defined as the transformation from ETRS89 (ETRF2000). EPSG mentions for the origin of the datum: "Originally defined through fundamental point Amersfoort, latitude 52°09'22.178"N, longitude 5°23'15.478"E (of Greenwich). Since 2000-10-01 has been redefined as derived from ETRS89 by application of the official transformation RDNAPTRANS(TM)."

Similarly in NZ, NZGD2000 has been defined since 2000.0 as based on ITRF96 by deformation model transformation from ITRF96 (and now by additional transformations from ITRFxxxx as ITRF96 is no longer directly accessible).  Which is not to say it isn't what the authors of the standard had in mind - but it is a geodetic reality.

Regards
Chris

________________________________

From: PROJ <proj-bounces at lists.osgeo.org> on behalf of Lesparre, Jochem <Jochem.Lesparre at kadaster.nl>
Sent: 11 October 2020 05:41
To: Even Rouault <even.rouault at spatialys.com>; Greg Troxel <gdt at lexort.com>
Cc: proj at lists.osgeo.org <proj at lists.osgeo.org>
Subject: Re: [PROJ] EPSG v10 update status

Hi list,

I would like to add some comments on 4 unrelated remarks by Greg and Even.

1. Greg wrote:

> "I know this is in some flavor of WGS84 but I don't know which."

The label WGS84 is often also used for data in ITRS or ETRS89 (and I suppose this happens for NADxx too), so it often is "I know this is in some kind of latlon but I don't know which", or even worse: "I know this data is in ETRF2000 but the data format I'm using forces me to call it WGS84".

2. Greg wrote:

> I would also expect an ensemble to implicitly declare a low-accuracy transform (perhaps that accuracy is or should be carried in the ensemble definition) among any two members.

The EPSG registry has a precision parameter for each transformation (not for a CRS). The transformation to/from a datum ensemble has lower precision than the transformation to a specific realisation of that ensemble. It would be nice if PROJ could propagate this precision as a 5th value (after the 4 values for the 3D coordinates and time).

3. Even wrote:

> I don't think the last sentence matches what the authors of standard have in mind (I don't think a datum can be *defined* by a transformation to another datum. a datum exists as such. one may establish transformations to others, but they are not defining. at least for geodetic datums. for vertical datums, some of them are indeed defined by a geoid model that applies to a given geodetic datum).

The National CRS of the Netherlands (EPSG crs: 28992) has its own has datum (EPSG datum: 6289). Since 2000, this Dutch datum IS defined as the transformation from ETRS89 (ETRF2000). EPSG mentions for the origin of the datum: "Originally defined through fundamental point Amersfoort, latitude 52°09'22.178"N, longitude 5°23'15.478"E (of Greenwich). Since 2000-10-01 has been redefined as derived from ETRS89 by application of the official transformation RDNAPTRANS(TM)."

4. Greg wrote:

> My guesstimate would be that it must be at least one-full time geodesist to maintain and enchance it [EPSG].

In fact, there are two geodesists at IOGP for this, but I believe that EPSG is just one of their tasks.

Regards, Jochem

From: PROJ <proj-bounces at lists.osgeo.org> On Behalf Of Even Rouault
Sent: zaterdag 10 oktober 2020 17:25
To: Greg Troxel <gdt at lexort.com>
Cc: proj at lists.osgeo.org
Subject: Re: [PROJ] EPSG v10 update status

Greg,

> I interpet that as one of:

>

> datums defined by a set of station coordinates at a reference epoch

> and station velocities

>

> datums defined by a time-dependent transformation to another datum.

I don't think the last sentence matches what the authors of standard have in mind (I don't think a datum can be *defined* by a transformation to another datum. a datum exists as such. one may establish transformations to others, but they are not defining. at least for geodetic datums. for vertical datums, some of them are indeed defined by a geoid model that applies to a given geodetic datum).

It is not because there's a known time-dependent transformation between DatumYYYY and ITRFxxxx that DatumYYYY is a dynamic datum. The time-dependency comes from the fact that ITRFxxxx is a dynamic datum, so when changing coordinates between crust-fixed DatumYYYY and ITRFxxxx, you need to specify the epoch of coordinates in ITRFxxxx.

> It looks like GDA2020 is defined in terms of ITRF2014 and a

> time-dependent transformation. Thus it seems squarely a dynamic datum

> based on the above definition.

GDA2020 is intended to be a 'static' datum. Coordinates of an object attached to the Australian plate don't change over time in GDA2020.

> Part of what I'm having trouble understanding is that as an example,

> when you get a solution out of NRCAN PPP as IRTRF2014, it is "epoch of

> data", meaning the ITF2014 coordinates of the station at that moment.

> ITRF2014's reference epoch is the date at which the published stations

> had the published coordinates. So data in IRF2014 may be of an epoch

> that is not the reference epoch, and I think proj doesn't yet deal with

> that.

That's not true. PROJ isn't able to deal properly (at least easily) with "point motion operation", that is transformations in the same dynamic datum, where coordinate epoch changes.

But it can transform coordinates from a plate-fixed/static datum (let's say GDA2020) to a dynamic datum (let's say ATRF2014/ITRF2014), or the reverse. When the transformation is published of course.

Demo:

$ projinfo -s GDA2020 -t ITRF2014 -o PROJ -q

+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=cart +ellps=GRS80 +step +inv +proj=helmert +x=0 +y=0 +z=0 +rx=0 +ry=0 +rz=0 +s=0 +dx=0 +dy=0 +dz=0 +drx=0.00150379 +dry=0.00118346 +drz=0.00120716 +ds=0 +t_epoch=2020 +convention=coordinate_frame +step +inv +proj=cart +ellps=GRS80 +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1

You can see in the above a time-dependent Helmert transformation with the reference epoch being 2020 (since GDA2020 and ITRF2014 are concidered coincident for all practical purposes at epoch 2020.0)

Now let's try at 2020, the reference epoch of the transformation:

$ echo -30 120 0 2020 | cct $(projinfo -d 8 -s GDA2020 -t ITRF2014 -o PROJ -q)

-30.00000000 120.00000000 0.00000000 2020.0000

And in 2030:

$ echo -30 120 0 2030 | cct $(projinfo -d 8 -s GDA2020 -t ITRF2014 -o PROJ -q)

-29.99999472 120.00000379 -0.00169912 2030.0000

> > I don't know why the NAD83 family isn't there. Probably depends on NOAA

> > deciding on how it wants to deal with that.

>

> Interesting concept that they would decide :-) Did NGA really weigh in

> on what EPSG is doing, for WGS84?

Well, it **IS** the responsibility of geodetic agencies to speak actively with IOGP to make their data conveniently available to users. Each party might have their views on the best solution, but from exchanges I've been copied to, such discussions are done in a constructive way. If an agency doesn't speak with IOGP, their data might be just ignored, or if it is needed, IOGP or submitters to IOGP will make their own decisions. As an individual you can also talk with IOGP and submit change requests:

https://epsg.org/dataset-change-requests.html

Let be realist: the PROJ team isn't staffed to do the job that IOGP does with the EPSG dataset. My guesstimate would be that it must be at least one-full time geodesist to maintain and enchance it.

> I guess that's the big point. As I see it, in an ideal world, we

> wouldn't need datum ensembles because data would be labeled in the

> actual realization it is in. We need ensembles because of all the data

> that is "I know this is in some flavor of WGS84 but I don't know which."

There's a practical reason for datum ensembles to be used. It is to avoid the proliferation of "derived objects". A projected CRS points to a geographic CRS which points to a datum/datum ensemble. Currently you have 120 projected UTM CRS over WGS84. If you wanted to have them for each of the realizations, you'd have to multiply that by 6. The database would grow unwidely.

> > Datasets referenced to the various

> > realizations may be merged without change of coordinates.

>

> The last sentence is interesting and surprising.

>

> I would expect that if there is a high-quality transform between two

> members of an ensemble, and data is expressed in those members, that

> transform will be used.

Yes, there are definitely transformations that exist between ITRF realizations. It is just that if you've data referenced to a datum ensemble and not a given realization, this is game over: you don't know which realization, so no high accuracy transformation possible.

> I would also expect an ensemble to implicitly declare a low-accuracy

> transform (perhaps that accuracy is or should be carried in the ensemble

> definition) among any two members.

Such transformations exist in the database as said above. They are just not exposed in the datum ensemble itself (it would be quite messy !)

$ sqlite3 data/proj.db "select code, name from coordinate_operation_view where (name LIKE '%ITRF%to%ITRF%' or name LIKE '%WGS 84 (G%)%to%WGS 84 (G%)%') and auth_name = 'EPSG' and deprecated = 0 order by name"

6302|ITRF2000 to ITRF2005 (1)

6300|ITRF2000 to ITRF2008 (1)

8078|ITRF2000 to ITRF2014 (1)

9080|ITRF2000 to ITRF96 (2)

6389|ITRF2005 to ITRF2008 (2)

8079|ITRF2005 to ITRF2014 (1)

9081|ITRF2005 to ITRF96 (1)

7790|ITRF2008 to ITRF2014 (1)

9082|ITRF2008 to ITRF96 (2)

9083|ITRF2014 to ITRF96 (2)

6281|ITRF88 to ITRF2000 (1)

6291|ITRF88 to ITRF2008 (1)

8069|ITRF88 to ITRF2014 (1)

9020|ITRF88 to ITRF89 (1)

7814|ITRF89 to ITRF2000 (1)

6292|ITRF89 to ITRF2008 (1)

8070|ITRF89 to ITRF2014 (1)

9021|ITRF89 to ITRF90 (1)

6283|ITRF90 to ITRF2000 (1)

6293|ITRF90 to ITRF2008 (1)

8071|ITRF90 to ITRF2014 (1)

9022|ITRF90 to ITRF91 (1)

6284|ITRF91 to ITRF2000 (1)

6294|ITRF91 to ITRF2008 (1)

8072|ITRF91 to ITRF2014 (1)

9023|ITRF91 to ITRF92 (1)

6285|ITRF92 to ITRF2000 (1)

6295|ITRF92 to ITRF2008 (1)

8073|ITRF92 to ITRF2014 (1)

9024|ITRF92 to ITRF93 (1)

6286|ITRF93 to ITRF2000 (1)

6296|ITRF93 to ITRF2008 (1)

8074|ITRF93 to ITRF2014 (1)

9025|ITRF93 to ITRF94 (1)

6287|ITRF94 to ITRF2000 (1)

6297|ITRF94 to ITRF2008 (1)

8075|ITRF94 to ITRF2014 (1)

9026|ITRF94 to ITRF96 (1)

6288|ITRF96 to ITRF2000 (1)

6298|ITRF96 to ITRF2008 (1)

8076|ITRF96 to ITRF2014 (1)

9027|ITRF96 to ITRF97 (1)

6289|ITRF97 to ITRF2000 (1)

6299|ITRF97 to ITRF2008 (1)

8077|ITRF97 to ITRF2014 (1)

9079|ITRF97 to ITRF96 (2)

7668|WGS 84 (G1150) to WGS 84 (G1762) (1)

7667|WGS 84 (G1674) to WGS 84 (G1762) (1)

Some of them are time-dependent, some sone.

$ projinfo "ITRF2000 to ITRF2005 (1)" -o PROJ

+proj=helmert +x=-0.0001 +y=0.0008 +z=0.0058 +rx=0 +ry=0 +rz=0 +s=-0.0004 +dx=0.0002 +dy=-0.0001 +dz=0.0018 +drx=0 +dry=0 +drz=0 +ds=-8e-05 +t_epoch=2000 +convention=position_vector

$ projinfo "WGS 84 (G1150) to WGS 84 (G1762) (1)" -o PROJ

+proj=helmert +x=-0.006 +y=0.005 +z=0.02 +rx=0 +ry=0 +rz=0 +s=-0.0045 +convention=coordinate_frame

Even

--

Spatialys - Geospatial professional services

http://www.spatialys.com

Disclaimer:
De inhoud van dit bericht is uitsluitend bestemd voor geadresseerde.
Gebruik van de inhoud van dit bericht door anderen zonder toestemming van het Kadaster
is onrechtmatig. Mocht dit bericht ten onrechte bij u terecht komen, dan verzoeken wij u
dit direct te melden aan de verzender en het bericht te vernietigen.
Aan de inhoud van dit bericht kunnen geen rechten worden ontleend.

Disclaimer:
The content of this message is meant to be received by the addressee only.
Use of the content of this message by anyone other than the addressee without the consent
of the Kadaster is unlawful. If you have received this message, but are not the addressee,
please contact the sender immediately and destroy the message.
No rights can be derived from the content of this message.

________________________________

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20201011/628957c2/attachment-0001.html>