[PROJ] EPSG v10 update status

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[PROJ] EPSG v10 update status

Even Rouault-2

Hi,

 

I've now code ready to handle the update to EPSG v10

(https://github.com/OSGeo/PROJ/issues/2355). There are some backward compatibility challenges & risk assessment to do. See the cover text of https://github.com/OSGeo/PROJ/pull/2370 (targetted for 7.2) and

https://github.com/OSGeo/PROJ/pull/2371 (targetted for 8.0) for details.

 

It would be appreciated if downstream PROJ users could give a try at least at #2370 to confirm it doesn't break in major ways their apps.

 

And possibly also try #2371, but if your code inspects the details of objects, like accessing the datum of a CRS, be prepared for the dreaded datum ensemble concept to show up (for anything based on WGS84 and ETRS89), in which case you may need to use new functions added in the C API.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: EPSG v10 update status

Nyall Dawson
On Fri, 9 Oct 2020 at 10:19, Even Rouault <[hidden email]> wrote:

>
> Hi,
>
>
>
> I've now code ready to handle the update to EPSG v10
>
> (https://github.com/OSGeo/PROJ/issues/2355). There are some backward compatibility challenges & risk assessment to do. See the cover text of https://github.com/OSGeo/PROJ/pull/2370 (targetted for 7.2) and
>
> https://github.com/OSGeo/PROJ/pull/2371 (targetted for 8.0) for details.
>

This is great news -- thanks for your hard work in implementing this
and the various sponsors of this work!!

Nyall
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: EPSG v10 update status

Roger Bivand
Is there a specific PR/fork of GDAL that matches rouault/PROJ:epsg10?
Testing for the R packages I'm involved with uses both, so GDAL would need
to use PROJ functions adapted for v10.

Thanks in advance,

Roger

--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: EPSG v10 update status

Even Rouault-2

Roger,

 

> Is there a specific PR/fork of GDAL that matches rouault/PROJ:epsg10?

> Testing for the R packages I'm involved with uses both, so GDAL would need

> to use PROJ functions adapted for v10.

 

To test just rouault/PROJ:epsg10, you don't need any special GDAL patched version as the objects returned by PROJ will still have the same structure as before (no datum ensemble)

 

To test rouault/PROJ:epsg10_part2 with GDAL, you need

https://github.com/OSGeo/gdal/pull/3033 that contains fixes for dealing with datum ensemble.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: EPSG v10 update status

Greg Troxel-2
In reply to this post by Even Rouault-2

I am glad to see progress in this area as I find datum ensembles to be a
major source of trouble, especially in the US.  A few questions:

> for dynamic datum & CRS (like "WGS 84 (Gxxxx)", "ITRFxxxx"), ingest the
> frame reference epoch from the database and emit it in WKT. No/little
> backward compatibility issue foreseen.

Sorry if this is dragging you off topic, but I continue to have a hard
time following exactly what people mean by "dynamic datum".  Sometimes
it seems to mean "defined relative to ITRFxxxx via a velocity model, so
that coordinates of crust-fixed stations are stable".  And sometimes it
seems to mean "a datum that we ackknowledge is not crust-fixed".

Here, I wonder if you are referring the to progression of realizations,
or one of the above, or something else?

> datum ensembles... This is the most annoying part. The "World Geodetic
> System 1984" and "European Terrestrial Reference System 1989" datum
> have now in EPSG 10 a " ensemble" suffix in their names to reflect the
> new nature of those objects.

I understand the issue with WGS84, and am guessing ETRS89 is similar.
I don't follow why NAD83 isn't listed here, and I wonder if you think
there's a good reason, or just 'it ought to be but nobody has done the
work yet'.

From my US-centric perspective, NAD83 and WGS84 are the preeminent
examples of datum ensembles.


Also, I wonder if ITRFxxxx is going to be treated as datum ensemble.  As
I understand it, ITRFxxxx are successive realizations for ITRS (which is
itself not a datum).


I also wonder if there is a code for WGS84(TRANSIT) or whatever it's
called, so that this is nameable separately from the ensemble.

Thanks,
Greg

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

signature.asc (199 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EPSG v10 update status

Roger Bivand
In reply to this post by Even Rouault-2
On Fri, 9 Oct 2020, Even Rouault wrote:

> Roger,
>
>> Is there a specific PR/fork of GDAL that matches rouault/PROJ:epsg10?
>> Testing for the R packages I'm involved with uses both, so GDAL would need
>> to use PROJ functions adapted for v10.
>
> To test just rouault/PROJ:epsg10, you don't need any special GDAL
> patched version as the objects returned by PROJ will still have the same
> structure as before (no datum ensemble)

Thanks! I've tested sf and rgdal, and apart from changing column numbers
in the DB table for 10 compared to 9, things seem OK. I'll look to run
tests on R packages using sf or rgdal later. The only changes were in
documentation, where I opened proj.db directly from RSQLite to display the
contents, so not to do with PROJ or PR #2370.

I'll move to check part2 once 7.2 is published.

Best wishes,

Roger

>
> To test rouault/PROJ:epsg10_part2 with GDAL, you need
> https://github.com/OSGeo/gdal/pull/3033 that contains fixes for dealing with datum
> ensemble.
>
> Even
>
>

--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: EPSG v10 update status

Even Rouault-2
In reply to this post by Greg Troxel-2

Greg,

 

> > for dynamic datum & CRS (like "WGS 84 (Gxxxx)", "ITRFxxxx"), ingest the

> > frame reference epoch from the database and emit it in WKT. No/little

> > backward compatibility issue foreseen.

>

> Sorry if this is dragging you off topic, but I continue to have a hard

> time following exactly what people mean by "dynamic datum". Sometimes

> it seems to mean "defined relative to ITRFxxxx via a velocity model, so

> that coordinates of crust-fixed stations are stable". And sometimes it

> seems to mean "a datum that we ackknowledge is not crust-fixed".

>

> Here, I wonder if you are referring the to progression of realizations,

> or one of the above, or something else?

 

Sorry to just copy&paste

https://docs.opengeospatial.org/as/18-005r4/18-005r4.html , but this is the inspiring document for WKT:2019, all PROJ "metadata" handling and EPSG database content

 

"""

3.1.20

dynamic reference frame

dynamic datum

reference frame in which the defining parameters include time evolution

Note 1 to entry: The defining parameters that have time evolution are usually a coordinate set.

"""

 

Here's the extensive list of what is considered in EPSG as a dynamic datum:

 

$ sqlite3 data/proj.db "select 'EPSG:' || code || ', ' || name from geodetic_datum where frame_reference_epoch is not null order by name"

 

EPSG:1291, Australian Terrestrial Reference Frame 2014

EPSG:1245, IGS00

EPSG:1247, IGS05

EPSG:1141, IGS08

EPSG:1191, IGS14

EPSG:1244, IGS97

EPSG:1246, IGb00

EPSG:1248, IGb08

EPSG:1272, IGb14

EPSG:6647, International Terrestrial Reference Frame 1988

EPSG:6648, International Terrestrial Reference Frame 1989

EPSG:6649, International Terrestrial Reference Frame 1990

EPSG:6650, International Terrestrial Reference Frame 1991

EPSG:6651, International Terrestrial Reference Frame 1992

EPSG:6652, International Terrestrial Reference Frame 1993

EPSG:6653, International Terrestrial Reference Frame 1994

EPSG:6654, International Terrestrial Reference Frame 1996

EPSG:6655, International Terrestrial Reference Frame 1997

EPSG:6656, International Terrestrial Reference Frame 2000

EPSG:6896, International Terrestrial Reference Frame 2005

EPSG:1061, International Terrestrial Reference Frame 2008

EPSG:1165, International Terrestrial Reference Frame 2014

EPSG:6740, Parametry Zemli 1990

EPSG:1157, Parametry Zemli 1990.02

EPSG:1158, Parametry Zemli 1990.11

EPSG:1227, SIRGAS Continuously Operating Network DGF00P01

EPSG:1228, SIRGAS Continuously Operating Network DGF01P01

EPSG:1229, SIRGAS Continuously Operating Network DGF01P02

EPSG:1230, SIRGAS Continuously Operating Network DGF02P01

EPSG:1231, SIRGAS Continuously Operating Network DGF04P01

EPSG:1232, SIRGAS Continuously Operating Network DGF05P01

EPSG:1233, SIRGAS Continuously Operating Network DGF06P01

EPSG:1234, SIRGAS Continuously Operating Network DGF07P01

EPSG:1235, SIRGAS Continuously Operating Network DGF08P01

EPSG:1236, SIRGAS Continuously Operating Network SIR09P01

EPSG:1237, SIRGAS Continuously Operating Network SIR10P01

EPSG:1238, SIRGAS Continuously Operating Network SIR11P01

EPSG:1239, SIRGAS Continuously Operating Network SIR13P01

EPSG:1240, SIRGAS Continuously Operating Network SIR14P01

EPSG:1241, SIRGAS Continuously Operating Network SIR15P01

EPSG:1242, SIRGAS Continuously Operating Network SIR17P01

EPSG:1293, Sistem Referensi Geospasial Indonesia 2013

EPSG:6324, WGS 72 Transit Broadcast Ephemeris

EPSG:6760, World Geodetic System 1966

EPSG:6322, World Geodetic System 1972

EPSG:1154, World Geodetic System 1984 (G1150)

EPSG:1155, World Geodetic System 1984 (G1674)

EPSG:1156, World Geodetic System 1984 (G1762)

EPSG:1152, World Geodetic System 1984 (G730)

EPSG:1153, World Geodetic System 1984 (G873)

EPSG:1166, World Geodetic System 1984 (Transit)

 

From a quick look, at least for the datums with which I've some familiarity, it looks like they are datums which are not crust-fixed.

 

For example, Australia's GDA2020 which is crust-fixed is not there, altough it has a time-dependent Helmert transformation to ATRF2014 and ITRF2014 (both listed above)

 

> datum ensembles... This is the most annoying part. The "World Geodetic

> System 1984" and "European Terrestrial Reference System 1989" datum

> have now in EPSG 10 a " ensemble" suffix in their names to reflect the

> new nature of those objects.

> I don't follow why NAD83 isn't listed here, and I wonder if you think

> there's a good reason, or just 'it ought to be but nobody has done the

> work yet'.

 

I don't know why the NAD83 family isn't there. Probably depends on NOAA deciding on how it wants to deal with that.

 

> Also, I wonder if ITRFxxxx is going to be treated as datum ensemble. As

> I understand it, ITRFxxxx are successive realizations for ITRS (which is

> itself not a datum).

 

I don't know. But given the below definition taken again from 18-005r4, I'm wondering if someone who bothers enough to express coordinates in a ITRFxxxx datum would be really keen in seeing them degraded in a coarser ITRS ensemble. You could just use the WGS 84 ensemble for the same purpose I guess.

 

"""

A Datum Ensemble is a construct to facilitate the merging of realizations of the same Terrestrial Reference System or Vertical Reference System for lower accuracy spatial manipulation. In this document, datum ensemble is a collection of two or more reference frames that are realizations of one Terrestrial or Vertical Reference System and which for all but the highest accuracy requirements may be considered to be insignificantly different from each other. Datasets referenced to the various realizations may be merged without change of coordinates.

"""

 

> I also wonder if there is a code for WGS84(TRANSIT) or whatever it's

> called, so that this is nameable separately from the ensemble.

 

With epsg10_part2:

 

$ projinfo -k ensemble EPSG:6326

 

WKT2:2019 string:

ENSEMBLE["World Geodetic System 1984 ensemble",

MEMBER["World Geodetic System 1984 (Transit)",

ID["EPSG",1166]],

MEMBER["World Geodetic System 1984 (G730)",

ID["EPSG",1152]],

MEMBER["World Geodetic System 1984 (G873)",

ID["EPSG",1153]],

MEMBER["World Geodetic System 1984 (G1150)",

ID["EPSG",1154]],

MEMBER["World Geodetic System 1984 (G1674)",

ID["EPSG",1155]],

MEMBER["World Geodetic System 1984 (G1762)",

ID["EPSG",1156]],

ELLIPSOID["WGS 84",6378137,298.257223563,

LENGTHUNIT["metre",1],

ID["EPSG",7030]],

ENSEMBLEACCURACY[2.0],

ID["EPSG",6326]]

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: EPSG v10 update status

Greg Troxel-2
Even Rouault <[hidden email]> writes:

> Sorry to just copy&paste
> https://docs.opengeospatial.org/as/18-005r4/18-005r4.html , but this is the inspiring
> document for WKT:2019, all PROJ "metadata" handling and EPSG database content

No problem - thanks for the pointer.

> """
> 3.1.20
> dynamic reference frame
> dynamic datum
> reference frame in which the defining parameters include time evolution
> Note 1 to entry: The defining parameters that have time evolution are usually a coordinate
> set.
> """

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.

> Here's the extensive list of what is considered in EPSG as a dynamic datum:
>
> $ sqlite3 data/proj.db  "select 'EPSG:' || code || ', ' || name from geodetic_datum where
> frame_reference_epoch is not null order by name"
>
> (snip)
> EPSG:1291, Australian Terrestrial Reference Frame 2014
> EPSG:1272, IGb14
> EPSG:1165, International Terrestrial Reference Frame 2014
> EPSG:6324, WGS 72 Transit Broadcast Ephemeris
> EPSG:6760, World Geodetic System 1966
> EPSG:6322, World Geodetic System 1972
> EPSG:1154, World Geodetic System 1984 (G1150)
> EPSG:1155, World Geodetic System 1984 (G1674)
> EPSG:1156, World Geodetic System 1984 (G1762)
> EPSG:1152, World Geodetic System 1984 (G730)
> EPSG:1153, World Geodetic System 1984 (G873)
> EPSG:1166, World Geodetic System 1984 (Transit)
>
> From a quick look, at least for the datums with which I've some familiarity, it looks like they
> are datums which are not crust-fixed.

NAD83(2011) is missing from this list, but it is almost always used as
"epoch 2010.0".

I see having a reference epoch as a statement that the coordinates of a
point in that datum change over time, not so much as the datum having a
time-dependent definition.   I realize it's hard to be non-circular here.

> For example, Australia's GDA2020 which is crust-fixed is not there, altough it has a time-
> dependent Helmert transformation to ATRF2014 and ITRF2014 (both listed above)

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.


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.

This seems analogous to NAD83, which has the same issues, except:

  velocities are much lower (so more people can ignore them)

  it's conventional to use the reference epcoh coordinates for other
  stations so you get reference epoch coordinates for your station,
  modulo non-uniform motion (because you mostly stay on one plate and
  can get away with this)
 

>> datum ensembles... This is the most annoying part. The "World Geodetic
>> System 1984" and "European Terrestrial Reference System 1989" datum
>> have now in EPSG 10 a " ensemble" suffix in their names to reflect the
>> new nature of those objects.
>> I don't follow why NAD83 isn't listed here, and I wonder if you think
>> there's a good reason, or just 'it ought to be but nobody has done the
>> work yet'.
>
> 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?

(I don't mean to suggest their input isn't wanted or useful; I would
very much pay attentiont to anything anyone from either group said!)

All that said, NGS publications make it clear that NAD83 is very much a
datum ensemble by this definition.

>> Also, I wonder if ITRFxxxx is going to be treated as datum ensemble.  As
>> I understand it, ITRFxxxx are successive realizations for ITRS (which is
>> itself not a datum).
>
> I don't know. But given the below definition taken again from 18-005r4, I'm wondering if
> someone who bothers enough to express coordinates in a ITRFxxxx datum would be really
> keen in seeing them degraded in a coarser ITRS ensemble. You could just use the WGS 84
> ensemble for the same purpose I guess.

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."

It's therefore a fair point that the world does not seem to have data
that is labeled as 'some kind of ITRF'.


> """
> A Datum Ensemble is a construct to facilitate the merging of realizations of the same
> Terrestrial Reference System or Vertical Reference System for lower accuracy spatial
> manipulation. In this document, datum ensemble is a collection of two or more reference
> frames that are realizations of one Terrestrial or Vertical Reference System and which for all
> but the highest accuracy requirements may be considered to be insignificantly different from
> each other. 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.

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.
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: EPSG v10 update status

Even Rouault-2

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


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: EPSG v10 update status

Jochem

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 <[hidden email]> On Behalf Of Even Rouault
Sent: zaterdag 10 oktober 2020 17:25
To: Greg Troxel <[hidden email]>
Cc: [hidden email]
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.

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: EPSG v10 update status

Nyall Dawson
In reply to this post by Even Rouault-2
> And possibly also try #2371, but if your code inspects the details of objects, like accessing the datum of a CRS, be prepared for the dreaded datum ensemble concept to show up (for anything based on WGS84 and ETRS89), in which case you may need to use new functions added in the C API.

Hi Even,

I've been trying to get my head around how the introduction of datum
ensembles will impact downstream projects, and specifically how things
will/should change for users of these applications.

Am I correct in my understanding that a ensemble is (at this stage) a
"metadata only" concept, which indicates that the datum is only
suitable for approximate spatial referencing? Or does a datum being
flagged as an ensemble also influence the operations determined by
PROJ and their order of precedence?

How would you imagine a downstream project like QGIS should respond to
this concept? Should we add a user-visible flag on any CRS definitions
associated with a datum ensemble to say "Warning: ensemble datum, not
for use in accurate spatial referencing"? What other user-facing
changes do you think should be introduced?

Nyall






>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>
> _______________________________________________
> PROJ mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/proj
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: EPSG v10 update status

Nyall Dawson
In reply to this post by Even Rouault-2
On Sat, 10 Oct 2020 at 01:36, Even Rouault <[hidden email]> wrote:

> Here's the extensive list of what is considered in EPSG as a dynamic datum:
>
>
>
> $ sqlite3 data/proj.db "select 'EPSG:' || code || ', ' || name from geodetic_datum where frame_reference_epoch is not null order by name"
>
snip
>
> EPSG:1166, World Geodetic System 1984 (Transit)

Is there any proj c api which can be used to determine whether or not
a particular datum is dynamic? (i.e. to obtain this list without
direct database querying).

> for dynamic datum & CRS (like "WGS 84 (Gxxxx)", "ITRFxxxx"), ingest the
> frame reference epoch from the database and emit it in WKT. No/little
> backward compatibility issue foreseen.

My interpretation of your PRs is that the answer is no, but just to
confirm: does proj now have the capability to ingest coordinate
metadata from a WKT string? If so, is there any api in proj yet to
retrieve the coordinate epoch from this metadata for a dynamic datum
CRS?

Nyall


>
>
>
> From a quick look, at least for the datums with which I've some familiarity, it looks like they are datums which are not crust-fixed.
>
>
>
> For example, Australia's GDA2020 which is crust-fixed is not there, altough it has a time-dependent Helmert transformation to ATRF2014 and ITRF2014 (both listed above)
>
>
>
> > datum ensembles... This is the most annoying part. The "World Geodetic
>
> > System 1984" and "European Terrestrial Reference System 1989" datum
>
> > have now in EPSG 10 a " ensemble" suffix in their names to reflect the
>
> > new nature of those objects.
>
> > I don't follow why NAD83 isn't listed here, and I wonder if you think
>
> > there's a good reason, or just 'it ought to be but nobody has done the
>
> > work yet'.
>
>
>
> I don't know why the NAD83 family isn't there. Probably depends on NOAA deciding on how it wants to deal with that.
>
>
>
> > Also, I wonder if ITRFxxxx is going to be treated as datum ensemble. As
>
> > I understand it, ITRFxxxx are successive realizations for ITRS (which is
>
> > itself not a datum).
>
>
>
> I don't know. But given the below definition taken again from 18-005r4, I'm wondering if someone who bothers enough to express coordinates in a ITRFxxxx datum would be really keen in seeing them degraded in a coarser ITRS ensemble. You could just use the WGS 84 ensemble for the same purpose I guess.
>
>
>
> """
>
> A Datum Ensemble is a construct to facilitate the merging of realizations of the same Terrestrial Reference System or Vertical Reference System for lower accuracy spatial manipulation. In this document, datum ensemble is a collection of two or more reference frames that are realizations of one Terrestrial or Vertical Reference System and which for all but the highest accuracy requirements may be considered to be insignificantly different from each other. Datasets referenced to the various realizations may be merged without change of coordinates.
>
> """
>
>
>
> > I also wonder if there is a code for WGS84(TRANSIT) or whatever it's
>
> > called, so that this is nameable separately from the ensemble.
>
>
>
> With epsg10_part2:
>
>
>
> $ projinfo -k ensemble EPSG:6326
>
>
>
> WKT2:2019 string:
>
> ENSEMBLE["World Geodetic System 1984 ensemble",
>
> MEMBER["World Geodetic System 1984 (Transit)",
>
> ID["EPSG",1166]],
>
> MEMBER["World Geodetic System 1984 (G730)",
>
> ID["EPSG",1152]],
>
> MEMBER["World Geodetic System 1984 (G873)",
>
> ID["EPSG",1153]],
>
> MEMBER["World Geodetic System 1984 (G1150)",
>
> ID["EPSG",1154]],
>
> MEMBER["World Geodetic System 1984 (G1674)",
>
> ID["EPSG",1155]],
>
> MEMBER["World Geodetic System 1984 (G1762)",
>
> ID["EPSG",1156]],
>
> ELLIPSOID["WGS 84",6378137,298.257223563,
>
> LENGTHUNIT["metre",1],
>
> ID["EPSG",7030]],
>
> ENSEMBLEACCURACY[2.0],
>
> ID["EPSG",6326]]
>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>
> _______________________________________________
> PROJ mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/proj
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: EPSG v10 update status

Greg Troxel-2
In reply to this post by Nyall Dawson

Nyall Dawson <[hidden email]> writes:

> Hi Even,
>
> I've been trying to get my head around how the introduction of datum
> ensembles will impact downstream projects, and specifically how things
> will/should change for users of these applications.
>
> Am I correct in my understanding that a ensemble is (at this stage) a
> "metadata only" concept, which indicates that the datum is only
> suitable for approximate spatial referencing? Or does a datum being
> flagged as an ensemble also influence the operations determined by
> PROJ and their order of precedence?
>
> How would you imagine a downstream project like QGIS should respond to
> this concept? Should we add a user-visible flag on any CRS definitions
> associated with a datum ensemble to say "Warning: ensemble datum, not
> for use in accurate spatial referencing"? What other user-facing
> changes do you think should be introduced?
>
> Nyall
Sort of related: I am having a CRS problem with QGIS and the world (not
fair to blame QGIS/proj) and I thought it might be helpful to explain
it.  It's a little long but I hope straightforward.

This note is written about qgis 3.10 and proj 6.3.2 on NetBSD.  I have
tried Mac QGIS but it has proj 5 and things are much worse.

I'm in Massachusetts, US, and thus have a lot of data in "NAD83(2011)
epoch 2010.0".  (skippable details: This is a plate-fixed datum, but
there is an epoch because coordinates change over time.  However, the
changes are at the maybe 2 mm/year level and thus ignored by pretty much
everyone.  One gets epoch 2010.0 values for GPS observations today,
because the practice is to use the epcoh 2010 values as the reference
station coordinates.  I'll drop the epoch 2010.0 in the rest of this
email, because that has nothing to do with my problem.)

Some of this data is from GPS processed by OPUS, and some from GNSS RTK
from my state's reference network.  My state also makes 15cm imagery
available as NAD83(2011) UTM and they report having have done ground
control to 0.1m RMS.  My checking of that vs GNSS fails to support a
hypothesis that the imagery is worse than 0.5m anywhere, eve allowing
for deck railings which are tricky for orthorectification.  The point is
that the accuracy of the imagery registration is much better than a
meter, and thus much lower than the NAD83/ITRF offset.

There is also vector data from the state, in NAD83(2011), with varying
accuracy.  Some of it (parcels) seems sub-meter in quality in some spots.

My state also publishes TMS of some of the layers, including the 15cm
imagery and the parcels layer.  These are therefore in WGS84 spherical
mercator.  Spherical mercator is of course not a problem, but this is
the fuzzy WGS84 datum ensemble.

Obviously when publishing as TMS the data should have been reprojected
from NAD83(2011) to WGS84(G1762) because original WGS84 is an irrelevant
historical curiousity for spring 2019 imagery ground controlled to
NAD83(2011).  I 95%+ think this is true, but I'm still trying to check,
confounded by the issue I'm writing about.

I also have some data in ITRF2014, basically output from NRCAN PPP and
OPUS.  I put this into a hand-created gpx.

I have some data in gpx format that was recorded via RTK with a
NAD83(2011) reference station.

There are precise transforms from NAD83(2011) to WGS84(G1762), or
certainly one can fake this in proj/QGIS by telling QGIS that the data
is ITRF2014.  When I do this (label the gpx with ITRF2014 as ITRF2014,
and the RTK/NAD83(2011) gpx as NAD83(2011)), everything lines up.

I am using NAD83(2011) UTM as my project CRS, to avoid reprojecting the
good imagery.

I noticed that the gpx with ITRF when I added it was treated as WGS84
(which is how gpx is defined) and given a null transform to NAD83.  That
was easy to fix by labeling it ITRF2014.

However, the iamgery that is in TMS ("WGS84") is I believe also not
transformed to NAD83, on the theory that a null transform is valid from
"WGS84" to NAD83(2011).  This is definitely a bug -- but it's hard to
say exactly where.

It also seems wrong that if I set project CRS to NAD83(2011) one thing
happens (null transform from WGS84) but if I set it to ITRF2014 another
(proper transfrom from NAD83 and a now-correct null transform from WGS84
to ITRF2014).

One theory is that it's a bug that TMS is defined in a datum ensemble,
rather then being defined to be in the latest WGS84.  But that seems
entirely unfixable.

My preferred theory is that while NAD83 and WGS84, whentreated as
ensembles, can be said to have a null transform (in that the oldest
versions of each can be said to match), that is not a reasoable
approach, and that while one should not ascribe high accuracy to a
transform with ensembles, the best choice oftransform is the one between
the most recent member of each ensemble.

This basically would result in treating WGS84 web mercator as probably
being WGS84(G1762) and transforming it as if it was.  This reduces the
error in the case when people are being careful/modern, and puts the
error on the cases when the data is actually in WGS84(TRANSIT) in which
case it already has a lot of fuzz.

Without this interpretation, I don't see how anyone can publish imagery
as TMS and expect users to be able to line anything up with it, without
meter-level errors or getting lucky about project CRS.

With this "choose best" approach, I don't see who is harmed.

This is sort of related to Nyall's question, and I thought the struggles
of someone who actually understands these issues and is still having
trouble might be useful.

Greg


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

signature.asc (199 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EPSG v10 update status

Even Rouault-2
In reply to this post by Nyall Dawson

Nyall,

 

For the record, I'm running now QGIS master against PROJ's epsg10_part2 branch and things seem to go fine (but I didn't stress QGIS much)

 

QGIS doesn't use proj_crs_get_datum() (which will return NULL in PROJ 8 / epsg10_part2 branch for a CRS based on WGS 84), so at first sight, I don't think any code change is required.

 

> Am I correct in my understanding that a ensemble is (at this stage) a

> "metadata only" concept, which indicates that the datum is only

> suitable for approximate spatial referencing? Or does a datum being

> flagged as an ensemble also influence the operations determined by

> PROJ and their order of precedence?

 

This should have no consequence on the order of precedence of operations returned by PROJ. At least for now since in PROJ, for convenience of code, in the createOperations() code paths, everytime a datum is needed, if the CRS intead uses a datumEnsemble it is internally converted to a datum object. The sorting logic of operations doesn't specifically take into account the presence of a datum ensemble (other than the fact that transformations from/to WGS 84 should normally have at least a >= 1m accuracy)

 

> How would you imagine a downstream project like QGIS should respond to

> this concept? Should we add a user-visible flag on any CRS definitions

> associated with a datum ensemble to say "Warning: ensemble datum, not

> for use in accurate spatial referencing"? What other user-facing

> changes do you think should be introduced?

 

That's a tough question. Depends if we want to stress users or not :-)

 

For example, when you open a dataset referenced to WGS84, I don't think we should put a warning. The user isn't responsible for the choice of the data producer.

 

With PROJ 8 / epsg10_part2, the WKT:2019 output of a CRS using WGS84 will show the ENSEMBLE[] and the 2m ensemble accuracy, so that's already a form of warning (but probably most people not aware of the issue won't realize what this means)

 

When a user saves a layer from a CRS that doesn't use a datumensemble to another one that uses one, perhaps a warning could be issued. But I'm not sure if we should do that. That also depends on the accuracy of the data itself. Reprojecting something with a 100m accuracy to WGS84 isn't really a problem. There are so many ways in which users can shoot themselves in the foot. Almost anything involving datum transformation introduces extra inaccuracy.

 

There's also the fact that there are none projected CRS available in EPSG based on any of the realizations of WGS84 or ETRS89... So users have no easy choice of a better alternative, if they want to stay in the 'family' of the datum ensemble.

 

And not all datum ensembles are the same. (well, there are just 2 geodetic datums in EPSG for now :-)). But the ensemble accuracy of ETRS89 is 0.1 m. Not the same story as the 2 m of WGS84. So for European users ETRS89 is quite a reasonable choice for a lot of use cases. I don't believe the use of a given realization of it is very frequent, at least in the GIS field. People would actually rather use a national datum when available (in France RGF93 which in its latest version is a realization of ETRF2000 at epoch 2009.0, similar story for CHTRF95 in Switzerland, etc.), mostly for legal reasons, than a generic pan-european ETRF realization.

 

That's just my current thoughts. I've no definitive opinion. Looks to me datum ensemble are more a band aid to reflect that the current situation is not ideal, but the ideal has not been drawn (yet?)

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: EPSG v10 update status

Even Rouault-2
In reply to this post by Nyall Dawson

Nyall,

 

> Is there any proj c api which can be used to determine whether or not

> a particular datum is dynamic? (i.e. to obtain this list without

> direct database querying).

 

proj_get_codes_from_database(

ctx, "EPSG", PJ_TYPE_DYNAMIC_GEODETIC_REFERENCE_FRAME, false);

 

... which didn't work before you raised the question. I've added commits to the PR first part to fix that (and rebased part 2 on top of it)

 

On a given object proj_get_type() will also return PJ_TYPE_DYNAMIC_GEODETIC_REFERENCE_FRAME when appropriate

 

>

> > for dynamic datum & CRS (like "WGS 84 (Gxxxx)", "ITRFxxxx"), ingest the

> > frame reference epoch from the database and emit it in WKT. No/little

> > backward compatibility issue foreseen.

>

> My interpretation of your PRs is that the answer is no, but just to

> confirm: does proj now have the capability to ingest coordinate

> metadata from a WKT string?

 

I assume you mean a construct like the below that associates a CRS and the coordinate epoch (2016.47), and also for understanding of other readers not familiar with it:

 

COORDINATEMETADATA[

GEOGCRS["WGS 84 (G1762)",

DYNAMIC[FRAMEEPOCH[2005.0]],

DATUM["World Geodetic System 1984 (G1762)",

ELLIPSOID["WGS 84",6378137,298.257223563,LENGTHUNIT["metre",1.0]]

],

CS[ellipsoidal,3],

AXIS["(lat)",north,ANGLEUNIT["degree",0.0174532925199433]],

AXIS["(lon)",east,ANGLEUNIT["degree",0.0174532925199433]],

AXIS["ellipsoidal height (h)",up,LENGTHUNIT["metre",1.0]]

],

EPOCH[2016.47]

]

 

The answer is no indeed. This is not something currently handled by PROJ.

 

I'm not clear if that construct is a solution for the need of storing a coordinate epoch. I don't think it would be legal for example to put it the gpkg_spatial_ref_sys table of a GeoPackage, which is to store CRS only, whereas we have here a tuple CRS + coordinate epoch (so there's no authority or code for the tuple itself). And that would be probably a bad design. For GeoPackage, I'd say that the gpkg_contents should have an addition column "coordinate_epoch" for that purpose, as this is fondamentally a property associated to the layer directly (assuming people don't need to store it per feature or per vertex !!!)

 

There would be interesting questions to how to deal with that WKT construct and the fact that a PROJ_COORD can also transmit a coordinate epoch... But the PROJ API is certainly not final regarding time-based transformation, as we don't have a proper way of asking "give me a tranformation from CRS A @ epoch T1 to CRS B @ epoch T2" (where CRS A == CRS B is a common case for "point motion operation"). I remember we discussed that a bit in a past thread.

 

> If so, is there any api in proj yet to

> retrieve the coordinate epoch from this metadata for a dynamic datum

> CRS?

 

In my updated pull request, for the sake of completness, I've added proj_dynamic_datum_get_frame_reference_epoch() that will return the 2005.0 of

the DYNAMIC[FRAMEEPOCH[2005.0]] in the above example, which is something that characterize the definition of the dynamic datum itself, but not the coordinate epoch itself. I'm not sure if there is any use of that. It could potentially be used internally by PROJ for doing time-based transformations, but I'm not even clear if that would be really needed: for example time dependent Helmert transformations have an explicit reference epoch in them.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: EPSG v10 update status

Chris Crook
In reply to this post by Jochem


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 <[hidden email]> on behalf of Lesparre, Jochem <[hidden email]>
Sent: 11 October 2020 05:41
To: Even Rouault <[hidden email]>; Greg Troxel <[hidden email]>
Cc: [hidden email] <[hidden email]>
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 <[hidden email]> On Behalf Of Even Rouault
Sent: zaterdag 10 oktober 2020 17:25
To: Greg Troxel <[hidden email]>
Cc: [hidden email]
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 [hidden email]) 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.

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: EPSG v10 update status

Nyall Dawson
In reply to this post by Even Rouault-2
On Mon, 12 Oct 2020 at 05:06, Even Rouault <[hidden email]> wrote:

> > Is there any proj c api which can be used to determine whether or not
>
> > a particular datum is dynamic? (i.e. to obtain this list without
>
> > direct database querying).
> proj_get_codes_from_database(
>
> ctx, "EPSG", PJ_TYPE_DYNAMIC_GEODETIC_REFERENCE_FRAME, false);
>
>
>
> ... which didn't work before you raised the question. I've added commits to the PR first part to fix that (and rebased part 2 on top of it)

Thanks!


> > My interpretation of your PRs is that the answer is no, but just to
>
> > confirm: does proj now have the capability to ingest coordinate
>
> > metadata from a WKT string?
>
>
>
> I assume you mean a construct like the below that associates a CRS and the coordinate epoch (2016.47), and also for understanding of other readers not familiar with it:
>
>
>
> COORDINATEMETADATA[
>
> GEOGCRS["WGS 84 (G1762)",
>
> DYNAMIC[FRAMEEPOCH[2005.0]],
>
> DATUM["World Geodetic System 1984 (G1762)",
>
> ELLIPSOID["WGS 84",6378137,298.257223563,LENGTHUNIT["metre",1.0]]
>
> ],
>
> CS[ellipsoidal,3],
>
> AXIS["(lat)",north,ANGLEUNIT["degree",0.0174532925199433]],
>
> AXIS["(lon)",east,ANGLEUNIT["degree",0.0174532925199433]],
>
> AXIS["ellipsoidal height (h)",up,LENGTHUNIT["metre",1.0]]
>
> ],
>
> EPOCH[2016.47]
>

That's correct.

> The answer is no indeed. This is not something currently handled by PROJ.

Ok - thanks for the confirmation.

> I'm not clear if that construct is a solution for the need of storing a coordinate epoch. I don't think it would be legal for example to put it the gpkg_spatial_ref_sys table of a GeoPackage, which is to store CRS only, whereas we have here a tuple CRS + coordinate epoch (so there's no authority or code for the tuple itself). And that would be probably a bad design. For GeoPackage, I'd say that the gpkg_contents should have an addition column "coordinate_epoch" for that purpose, as this is fondamentally a property associated to the layer directly (assuming people don't need to store it per feature or per vertex !!!)

I believe this will need to be handled differently on a
format-by-format basis, depending on the constraints of the various
formats and their underlying standards (if any). But I strongly
suspect that specifying the epoch through the coordinate metadata will
eventually be adopted as the approach for at least those formats which
natively store CRS definitions as WKT strings. Like you've pointed
out, those formats which rely on a database lookup using a numeric key
(such as postgis) will need some other way/metadata table to store the
per-dataset coordinate epoch.

But if we take a step backwards and don't even consider any spatial
data formats themselves, on a conceptual level it definitely sits
within proj's "area of responsibility" to be able to read these epochs
from CRS WKT and utilise it when constructing coordinate operations
involving dynamic datums. (Hopefully we see some of the relevant
authorities from countries who are moving toward dynamic CRSes step up
and sponsor this support!)

> > If so, is there any api in proj yet to
>
> > retrieve the coordinate epoch from this metadata for a dynamic datum
>
> > CRS?
>
>
>
> In my updated pull request, for the sake of completness, I've added proj_dynamic_datum_get_frame_reference_epoch() that will return the 2005.0 of
>
> the DYNAMIC[FRAMEEPOCH[2005.0]] in the above example, which is something that characterize the definition of the dynamic datum itself, but not the coordinate epoch itself. I'm not sure if there is any use of that. It could potentially be used internally by PROJ for doing time-based transformations, but I'm not even clear if that would be really needed: for example time dependent Helmert transformations have an explicit reference epoch in them.

Thanks again! I'm planning on exposing both the "is dynamic datum"
flag and the frame epoch information as part of a CRS'es metadata, so
that end users have a way to identify these without manually reading
the WKT strings...

Nyall



>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: EPSG v10 update status

Nyall Dawson
In reply to this post by Even Rouault-2
On Mon, 12 Oct 2020 at 03:16, Even Rouault <[hidden email]> wrote:

>
> > How would you imagine a downstream project like QGIS should respond to
>
> > this concept? Should we add a user-visible flag on any CRS definitions
>
> > associated with a datum ensemble to say "Warning: ensemble datum, not
>
> > for use in accurate spatial referencing"? What other user-facing
>
> > changes do you think should be introduced?
>
>
>
> That's a tough question. Depends if we want to stress users or not :-)
>
>
>
> For example, when you open a dataset referenced to WGS84, I don't think we should put a warning. The user isn't responsible for the choice of the data producer.

True, but they ARE responsible for correctly interpreting the accuracy
of the inputs to their analysis. I really think we need to be
aggressive about our messaging that EPSG:4326 isn't the "magical
golden ticket single answer" to the question "what CRS should I use
for my data/analysis". It's such an ingrained  default choice for the
vast majority of spatial data users, and so many of these users don't
even realise that there's any issue here.

> With PROJ 8 / epsg10_part2, the WKT:2019 output of a CRS using WGS84 will show the ENSEMBLE[] and the 2m ensemble accuracy, so that's already a form of warning (but probably most people not aware of the issue won't realize what this means)

Is the 2m accuracy for the ensemble correct here? I was of the
understanding that the inherent ambiguity in EPSG:4326 is in the order
of 10s of meters!

> When a user saves a layer from a CRS that doesn't use a datumensemble to another one that uses one, perhaps a warning could be issued. But I'm not sure if we should do that. That also depends on the accuracy of the data itself. Reprojecting something with a 100m accuracy to WGS84 isn't really a problem. There are so many ways in which users can shoot themselves in the foot. Almost anything involving datum transformation introduces extra inaccuracy.

Right -- but again, I think our responsiblity would be to just show a
warning to users so that they have ALL the information available to
make informed choices. The way I see it:

- no warning:
    - low accuracy data: no issue
    - high accuracy data: data is silently degraded and only informed
users will know that this has occurred
- with warning:
   - low accuracy data: a spurious "noisy" warning, annoys users.
(could potentially be avoided with a "[  ] Don't show this again"
option on the warning.)
   - high accuracy data: all users are informed that there's an issue,
they've got the choice to ignore the issue and degrade their data or
make a better choice and not taint their data

> There's also the fact that there are none projected CRS available in EPSG based on any of the realizations of WGS84 or ETRS89... So users have no easy choice of a better alternative, if they want to stay in the 'family' of the datum ensemble.

Still, that's THEIR choice. At least they've been made aware of the
consequences of their decision...

> And not all datum ensembles are the same. (well, there are just 2 geodetic datums in EPSG for now :-)). But the ensemble accuracy of ETRS89 is 0.1 m. Not the same story as the 2 m of WGS84. So for European users ETRS89 is quite a reasonable choice for a lot of use cases. I don't believe the use of a given realization of it is very frequent, at least in the GIS field. People would actually rather use a national datum when available (in France RGF93 which in its latest version is a realization of ETRF2000 at epoch 2009.0, similar story for CHTRF95 in Switzerland, etc.), mostly for legal reasons, than a generic pan-european ETRF realization.

So maybe we should include the ensemble accuracy in the warning. Something like

"Warning: saving this dataset to the xxxxx ensemble datum used by
EPSG:xxxx will result in a maximum positional accuracy of x.x meters.
If higher accuracy is required then an alternative CRS should be used.
(Please contact [hidden email] to ask which CRS he'd
recommend using for your particular circumstances.)" ;)

Nyall





>
>
>
> That's just my current thoughts. I've no definitive opinion. Looks to me datum ensemble are more a band aid to reflect that the current situation is not ideal, but the ideal has not been drawn (yet?)
>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: EPSG v10 update status

Greg Troxel-2

Nyall Dawson <[hidden email]> writes:

>> With PROJ 8 / epsg10_part2, the WKT:2019 output of a CRS using WGS84
>> will show the ENSEMBLE[] and the 2m ensemble accuracy, so that's
>> already a form of warning (but probably most people not aware of the
>> issue won't realize what this means)
>
> Is the 2m accuracy for the ensemble correct here? I was of the
> understanding that the inherent ambiguity in EPSG:4326 is in the order
> of 10s of meters!

2m sounds reasonable to me.  Really only WGS84(TRANSIT) is that far off
from the rest.  This link:
  https://confluence.qps.nl/qinsy/latest/en/world-geodetic-system-1984-wgs84-182618391.html

claims that the shifts between realizations are

  0.70m, 0.20m, 0.06m, 0.06m, 0.01m

and later gives WGS84/ITRF transforms.

I have never heard of 10s of meters ambiguity in WGS84.  (Certainly, use
of GPS to determine positions with L1-only equipment with SA resulted in
the order of 100m error, but that's a different matter.)

Given that WGS84(G730) was introduced on 1994-06-29, it seems unlikely
that there is much data actually in WGS84TRANSIT), and extremely
unlikely that any of that has accuracy better than 10s of meters.

So I think it's a disservice to users to tar all "WGS84" data with even
2m of datum ensemble fuzz.  As a theoretical accuracy estimate, that's
one thing, but it's not ok to skip transforms.  As things stand, the
incorrect null transforms will introduce more error than the actual
original errors.

So I think the world should consider WGS84', defined as some WGS84 >=
WGS84(G730) and thus not WGS84(TRANSIT), has having 20cm or so of
ensemble error, and assume that people who say WGS84 and don't know what
they are doing mean WGS84', and that any errors from that assumption are
tiny compared to intrincsic error in WGS84(TRANSIT).
 

Another approach is to pop up a bunch of checkboxes and ask people to
check all realzations that are used in the layer, and have a series of
ensembles for the ensemble they actually have.  This reduces in practice
to "no, I don't have any WGS84(TRANSIT) data".

>> There's also the fact that there are none projected CRS available in
>> EPSG based on any of the realizations of WGS84 or ETRS89... So users
>> have no easy choice of a better alternative, if they want to stay in
>> the 'family' of the datum ensemble.
>
> Still, that's THEIR choice. At least they've been made aware of the
> consequences of their decision...

The real problem, not really fixable by us is that data is labeled as
WGS84, when it should be labeled more carefully, becuase of the
deficiency in the EPSG data set.  Granted, some might not be more
careful, but right now when using TMS it's basically not possible.

Can anyone explain why there aren't codepoints in EPSG for the various
WGS84 realizations.  I get it that there has never been a high-accuracy
method to access WGS84 realizations, but still they are important
concepts and thus should have codepoints.  Or does the new dataset come
with those and this is now fixed?

>> And not all datum ensembles are the same. (well, there are just 2
>> geodetic datums in EPSG for now :-)). But the ensemble accuracy of
>> ETRS89 is 0.1 m. Not the same story as the 2 m of WGS84. So for
>> European users ETRS89 is quite a reasonable choice for a lot of use
>> cases. I don't believe the use of a given realization of it is very
>> frequent, at least in the GIS field. People would actually rather
>> use a national datum when available (in France RGF93 which in its
>> latest version is a realization of ETRF2000 at epoch 2009.0, similar
>> story for CHTRF95 in Switzerland, etc.), mostly for legal reasons,
>> than a generic pan-european ETRF realization.
FWIW, NAD83 obviously belongs as a datum ensemble, and should have
roughly 2m as the ensemble accuracy.  (I wonder if ETRS89 has better
accuracy due to using GPS positioning in the first realization?  0.1m
would be remarkable for classical methods.)

> So maybe we should include the ensemble accuracy in the warning. Something like
>
> "Warning: saving this dataset to the xxxxx ensemble datum used by
> EPSG:xxxx will result in a maximum positional accuracy of x.x meters.
> If higher accuracy is required then an alternative CRS should be used.
> (Please contact [hidden email] to ask which CRS he'd
> recommend using for your particular circumstances.)" ;)

Sounds good :-) Here, if someone is trying to save as WGS84, they should
perhaps be advised to save as WGS84(G1762).  But they can't do that now.
(They can use ITRF2014, but it takes more knowledge to see that as
reasonable.)


Another view is to say that data in a datum ensemble should be presumed
to be in the most recent realization of the ensemble, with the caveat
that data that actually was in older realizations will acquire errors
from that mislabeling.  That puts the errors on the data that is more
likely to have them, and avoids degrading recent data or data that
originated in a higher-accuracy datum and is simply being stored.


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

signature.asc (199 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[PROJ] Using latest realization of a datum ensemble ?

Even Rouault-2
In reply to this post by Greg Troxel-2

Hi,

 

For people not interested in my detailed analysis of Greg's experimentations but by the updated subject of this email, go directly at the bottom, after the REAL SUBJECT label.

 

> There are precise transforms from NAD83(2011) to WGS84(G1762),

 

$ projinfo -s "NAD83(2011)" -t "WGS84 (G1762)" --summary

Candidate operations found: 1

unknown id, Conversion from NAD83(2011) (geog2D) to NAD83(2011) (geocentric) + Inverse of ITRF2008 to NAD83(2011) (1) + Inverse of WGS 84 (G1762) to ITRF2008 (1) + Conversion from WGS 84 (G1762) (geocentric) to WGS 84 (G1762) (geog2D), 0.01 m

 

And the detail is a time-dependent Helmet transformation for the "ITRF2008 to NAD83(2011)" part (with central epoch at 1997.0), and a null transformation for "WGS 84 (G1762) to ITRF2008". So PROJ is already smart here, since there's no direct transformation between NAD83(2011) and WGS84 (G1762) in EPSG. It finds that the ITRF2008 intermediate is a likely intermediate since there are transformations registered between it and the 2 CRSs we are interested in

 

> I noticed that the gpx with ITRF when I added it was treated as WGS84

> (which is how gpx is defined) and given a null transform to NAD83. That

> was easy to fix by labeling it ITRF2014.

 

Actually, between plain old NAD83 (86) and generic WGS84, you've got many non-null transformations using NADCON4 grids (like one grid per state), or a null transformation "NAD83 to WGS 84 (1)" with a 4m accuracy:

 

$ projinfo -s "NAD83" -t "WGS84" --summary --spatial-test intersects

Candidate operations found: 53

[... snip ... ]

 

> It also seems wrong that if I set project CRS to NAD83(2011) one thing

> happens (null transform from WGS84)

 

> but if I set it to ITRF2014 another

> (proper transfrom from NAD83

 

You probably meant NAD83(2011) here ?

 

$ projinfo -s "NAD83 (2011)" -t "ITRF2014" --summary

Candidate operations found: 1

unknown id, Conversion from NAD83(2011) (geog2D) to NAD83(2011) (geocentric) + Inverse of ITRF2014 to NAD83(2011) (1) + Conversion from ITRF2014 (geocentric) to ITRF2014 (geog2D), 0 m

 

which is a time-dependent Helmert transformation with 2010.0 as central epoch

 

vs

 

$ projinfo -s "NAD83" -t "ITRF2014" --summary

Candidate operations found: 1

unknown id, Ballpark geographic offset from NAD83 to ITRF2014, unknown accuracy, World, has ballpark transformation

 

which is a null transformation synthetized by PROJ because it didn't find anything better.

 

> and a now-correct null transform from WGS84

> to ITRF2014).

 

Did you mean WGS84 or WGS84 (G1762) ?

 

Because

 

$ projinfo -s "WGS84 (G1762)" -t "ITRF2014" --summary

Candidate operations found: 1

unknown id, Conversion from WGS 84 (G1762) (geog2D) to WGS 84 (G1762) (geocentric) + WGS 84 (G1762) to ITRF2008 (1) + ITRF2008 to ITRF2014 (1) + Conversion from ITRF2014 (geocentric) to ITRF2014 (geog2D), 0.02 m, World

 

which is a non-null time-dependent transformation

 

vs

 

 

$ src/projinfo -s "WGS84" -t "ITRF2014" --summary

Candidate operations found: 1

Note: using '--spatial-test intersects' would bring more results (17)

unknown id, Ballpark geographic offset from WGS 84 to ITRF2014, unknown accuracy, World., has ballpark transformation

 

(if using --spatial-test intersects as suggested, PROJ infers complicated transformations around Gulf of Mexico, since EPSG has a complex NAD27 to ITRF2014 concatenated operation valid for GoM, and PROJ thus does WGS84 -> NAD27 and NAD27->ITRF2014, which is probably much too ""smart"" / incorrect)

 

>

> One theory is that it's a bug that TMS is defined in a datum ensemble,

> rather then being defined to be in the latest WGS84. But that seems

> entirely unfixable.

 

EPSG:3857 (TMS) uses EPSG:4326 (generic WGS84 geographic CRS based on the EPSG:6326 WGS84 datum ensemble). Actually I believe that a lot of imagery published in EPSG:3857 / TMS can be considered has being in a unknown datum, and if the souce imagery was in a GPS-era datum, it is probably labelled as WGS84 for TMS purposes without applying any shift.

 

 

> My preferred theory is that while NAD83 and WGS84, whentreated as

> ensembles, can be said to have a null transform (in that the oldest

> versions of each can be said to match), that is not a reasoable

> approach, and that while one should not ascribe high accuracy to a

> transform with ensembles, the best choice oftransform is the one between

> the most recent member of each ensemble.

 

Regarding NAD83 and ensembles, I guess one issue is that currently there is no different EPSG datum code to distinguish NAD83(86) and "NAD83 ensemble". So some decision would have to be taken if the current EPSG:6269 datum code should be only for NAD83(86), or if it would represent the NAD83 ensemble. But I'm definitely not the one that has a say about that.

 

============

REAL SUBJECT

============

 

What is tricky in the suggestion to 'promote' to the latest realization of a datum ensemble is that you might have both low accuracy transformations that exist like shown above for NAD83 -> WGS84 and high accuracy for NAD83(2011) -> WGS84 (G1762) (here I assume that NAD83 would be an enssemble, which it is not formally currently). Depending on the situation, one or the other might be relevant.

 

So there could be 2 options:

 

1) in addition to the lower resolution results, also consider the ones using the latest realization of the datum. and do that systematically

 

- Pro: more possibilities returned

- Con: more possibilities returned! (users might already be overwhelmed by current output which in some cases can offer of the order of 100 possibilities), and greater pipeline computation time (there are already optimizations/heuristics to avoid doing the advanced pipeline searchs, like using an intermediate CRS/datum, when direct ones are returned.)

- Pro or con: the default pipeline (that is the one used by cs2cs or proj_create_crs_to_crs() when the user has no say on the pipeline to use) would probably be in a lot of situation the high resolution one, which might be appropriate or not. The high accuracy pipelines also often need a coordinate epoch, so when it is not specified in the input coordinates provided to PROJ, the transformation will be done at the central epoch of the Helmert transformation.

 

In some circumstances, I imagine there might not be a transformation registered from/to the latest realization of a datum ensemble, but to an earlier realization.

 

2) or the same, but do that only on user request (projinfo switch, new function in C/C++ API).

 

- End users have to turn that on to benefit from the new capability

- Downstream software (like QGIS) has to make use of that new API, and possibly reflect that in its user interface.

 

 

I am a bit unconfortable about having PROJ being "too smart" by default with option 1. There are already known circumstances where it is too smart in a bad sense, such as in one of the above examples with WGS 84 to ITRF2014, using a NAD27 intermediate, or in https://github.com/OSGeo/PROJ/issues/2348

 

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
12