Re: [gdal-dev] Static/Dynamic datum problems

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [gdal-dev] Static/Dynamic datum problems

Cameron Shorter
Thanks Evan, I'm switching this email to the proj email list as suggested.

In answer to Evan's question:
> Why ? I don't see a contradiction between those 3 statements, because as you 
> mentioned, WGS84 is dynamic.

I believe that the problem is that WGS84 is being used in webmapping situations as if it were a static datum, locked to a fixed epoch, and in other cases it is treated as if it were a dynamic datum.

This has led to the situation we have in Australia where:

WGS94 -transform-> WGS2020 (leads to a coordinate shift of ~ 1.8 metres)
WGS94 -null transform-> WGS84 (which was correct in 1994) 
WGS2020 -null transform-> WGS84 (which will be correct in 2020)

I can see that I will need to write this up more clearly, which I'm in the process of doing. I'll share when done (early next week).

Cheers, Cameron


On Fri, 21 Jun 2019 at 08:20, Even Rouault <[hidden email]> wrote:
Cameron,

This would be more a topic for [hidden email] .

>
> Our Australian spatial data users are about to face a systematic mismatch
> challenge when trying to use multiple static datums (GDA2020, GDA94) with
> the dynamic datum (WGS84). At the moment, it is government agencies
> grappling with the problem, but it is about to become a mainstream issue.
>
> Australia now has static datums for the years 1994 and 2020 and uses WGS84
> (a time-dependent datum!), for web-mapping and web-services.  We recognise:
> 1. Transforming from GDA94 to GDA2020 reflects Australia’s tectonic
> movement of ~ 1.8 metres to the North East.
> 2. GDA94 was defined as ‘equal to WGS84’ in 1994.
> 3. GDA2020  was defined as ‘equal to WGS84’ in 2020.
> All three statements can’t be accurate.

Why ? I don't see a contradiction between those 3 statements, because as you
mentionned, WGS84 is dynamic.

> I believe this is a problem the whole world needs to address,

I'm not sure to have understood what the problem you're facing to is exactly.
Is it when combining data sources from several of those 3 CRS ?

There are transformation paths between GDA94 and GDA2020 in the EPSG dataset,
with static Helmert-based or grid-based transformations.

With PROJ 6:
$ projinfo -s GDA94 -t GDA2020 --summary --spatial-test intersects
Candidate operations found: 5
EPSG:8048, GDA94 to GDA2020 (1), 0.01 m, Australia - GDA
EPSG:8447, GDA94 to GDA2020 (2), 0.05 m, Australia - onshore, at least one
grid missing
EPSG:8446, GDA94 to GDA2020 (3), 0.05 m, Australia - onshore, at least one
grid missing
EPSG:8445, GDA94 to GDA2020 (5), 0.05 m, Cocos (Keeling) Islands - onshore, at
least one grid missing
EPSG:8444, GDA94 to GDA2020 (4), 0.05 m, Christmas Island - onshore, at least
one grid missing

Mixing with data referenced to WGS84 is going to be more problematic, because
of its dynamic nature indeed. So typically you will need to know if
coordinates are expressed to one of the particular realizations of WGS84:
CRS EPSG:7816: WGS 84 (Transit)
CRS EPSG:7657: WGS 84 (G730)
CRS EPSG:7659: WGS 84 (G873)
CRS EPSG:7661: WGS 84 (G1150)
CRS EPSG:7663: WGS 84 (G1674)
CRS EPSG:7665: WGS 84 (G1762)

The EPSG datset contains coordinate operations between those WGS 84 or
equivalent ITRF realizations, and GDA94 or GDA2020

To/from GDA2020:
- EPSG:8049: "ITRF2014 to GDA2020 (1)'" (Time-dependent Coordinate Frame
rotation)
- EPSG:8448: "GDA2020 to WGS 84 (G1762)" (Time-dependent Coordinate Frame
rotation)

To/from GDA94:
- EPSG:6276: "ITRF2008 to GDA94 (1)" (Time-dependent Coordinate Frame
rotation)
- EPSG:6277: "ITRF2005 to GDA94 (1)" (Time-dependent Coordinate Frame
rotation)
- EPSG:6278: "ITRF2000 to GDA94 (2)" (Time-dependent Coordinate Frame
rotation)
- EPSG:6279: "ITRF97 to GDA94 (2)" (Time-dependent Coordinate Frame rotation)
- EPSG:6280: "ITRF96 to GDA94 (2)" (Time-dependent Coordinate Frame rotation)
- EPSG:6313: "ITRF96 to GDA94 (1)" (Time-dependent Coordinate Frame rotation)
- EPSG:6314: "ITRF97 to GDA94 (1)" (Time-dependent Coordinate Frame rotation)
- EPSG:6315: "ITRF2000 to GDA94 (1)" (Time-dependent Coordinate Frame
rotation)
- EPSG:6392: "ITRF97 to GDA94 (1)" (Time-dependent Coordinate Frame rotation)

So it seems to me that the needed operations are there. GDAL 3 and PROJ 6
should be able to use them. What is probably more difficult is to figure out
the WGS84 / ITRF realization and the epoch in which your coordinates are
expressed.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com


--
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254




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

Re: [gdal-dev] Static/Dynamic datum problems

Even Rouault-2
> I believe that the problem is that WGS84 is being used in webmapping
> situations as if it were a static datum, locked to a fixed epoch, and in
> other cases it is treated as if it were a dynamic datum.
>
> This has led to the situation we have in Australia where:
>
> WGS94 -transform-> WGS2020 (leads to a coordinate shift of ~ 1.8 metres)
> WGS94 -null transform-> WGS84 (which was correct in 1994)
> WGS2020 -null transform-> WGS84 (which will be correct in 2020)

You likely meant GDA94 (instead of WGS94) and GDA2020 (instead of WGS2020).

Yes, indeed if you look in the EPSG dataset, and transform between GDA94 and
EPSG:4326 (the "average" WGS84 CRS), you'll get a null transform, but
advertized with a 3m accuracy only, whereas direct transformation between
GDA94 and GDA2020 has 1 or 5cm accuracy depending on which method is taken.
And same for GDA2020. So there is no transitivity in chaining transformations.

The thing is that EPSG:4326 is really a not super accurate CRS, given that its
underlying datum is actually a "datum ensemble" in the modern geodetic
terminology:
http://docs.opengeospatial.org/as/18-005r4/18-005r4.html#53

If you look at the candidate for the new CRS WKT revised standard
https://portal.opengeospatial.org/files/81176
you' ll see this

        ENSEMBLE["WGS 84 ensemble",
          MEMBER["WGS 84 (TRANSIT)",ID["EPSG",1166]],
          MEMBER["WGS 84 (G730)",ID["EPSG",1152]],
          MEMBER["WGS 84 (G834)",ID["EPSG",1153]],
          MEMBER["WGS 84 (G1150)",ID["EPSG",1154]],
          MEMBER["WGS 84 (G1674)",ID["EPSG",1155]],
          MEMBER["WGS 84 (G1762)",ID["EPSG",1156]],
          ELLIPSOID["WGS 84",6378137,298.2572236,LENGTHUNIT["metre",1.0]],
          ENSEMBLEACCURACY[2]
        ]

And I've heard that EPSG might consider to revise their future dataset to use
that datum ensemble as the base for CRS EPSG:4326 to better reflect this
reality, instead of basing it on the datum EPSG:6326, which is not really well
defined.
So mapping to EPSG:4326 makes only sense if you don't need accuracy lower than
2 meters.

You might pick up one of the WGS 84 realization, and use the time-dependent
transformations I mentionned in my previous email to go from GDA94 or GDA2020
to that realization.

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: [gdal-dev] Static/Dynamic datum problems

Cameron Shorter
Thanks Even, I really appreciate your feedback.

I'm pretty sure we have a problem which needs to be addressed at an
international level - likely through the OGC.

I've drafted a one pager, in simple language, which incorporates
feedback from both Joel Haasdyk and Even Rouault. The aim is to provide
this doc to decision makers who are probably not technically across the
details.

https://docs.google.com/document/d/15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0/edit#heading=h.e745vpszg17c

I'm unclear on the exact definition of WGS 84 and whether I'm explaining
it correctly.

I'd also unclear on what URLs should be referred to from this type of
document to reference different EPSG codes and the like.

All, feel free to reply with suggestions via email, or add comments into
this document. (Please use your google login before doing so, so we can
see who has said what).

For the record, the version of the doc I've just edited is version 1.2,
and after Joel's prior review was 1.1.

Cheers, Cameron

On 21/6/19 7:26 pm, Even Rouault wrote:

>> I believe that the problem is that WGS84 is being used in webmapping
>> situations as if it were a static datum, locked to a fixed epoch, and in
>> other cases it is treated as if it were a dynamic datum.
>>
>> This has led to the situation we have in Australia where:
>>
>> WGS94 -transform-> WGS2020 (leads to a coordinate shift of ~ 1.8 metres)
>> WGS94 -null transform-> WGS84 (which was correct in 1994)
>> WGS2020 -null transform-> WGS84 (which will be correct in 2020)
> You likely meant GDA94 (instead of WGS94) and GDA2020 (instead of WGS2020).
>
> Yes, indeed if you look in the EPSG dataset, and transform between GDA94 and
> EPSG:4326 (the "average" WGS84 CRS), you'll get a null transform, but
> advertized with a 3m accuracy only, whereas direct transformation between
> GDA94 and GDA2020 has 1 or 5cm accuracy depending on which method is taken.
> And same for GDA2020. So there is no transitivity in chaining transformations.
>
> The thing is that EPSG:4326 is really a not super accurate CRS, given that its
> underlying datum is actually a "datum ensemble" in the modern geodetic
> terminology:
> http://docs.opengeospatial.org/as/18-005r4/18-005r4.html#53
>
> If you look at the candidate for the new CRS WKT revised standard
> https://portal.opengeospatial.org/files/81176
> you' ll see this
>
> ENSEMBLE["WGS 84 ensemble",
>  MEMBER["WGS 84 (TRANSIT)",ID["EPSG",1166]],
>  MEMBER["WGS 84 (G730)",ID["EPSG",1152]],
>  MEMBER["WGS 84 (G834)",ID["EPSG",1153]],
>  MEMBER["WGS 84 (G1150)",ID["EPSG",1154]],
>  MEMBER["WGS 84 (G1674)",ID["EPSG",1155]],
>  MEMBER["WGS 84 (G1762)",ID["EPSG",1156]],
>  ELLIPSOID["WGS 84",6378137,298.2572236,LENGTHUNIT["metre",1.0]],
>  ENSEMBLEACCURACY[2]
> ]
>
> And I've heard that EPSG might consider to revise their future dataset to use
> that datum ensemble as the base for CRS EPSG:4326 to better reflect this
> reality, instead of basing it on the datum EPSG:6326, which is not really well
> defined.
> So mapping to EPSG:4326 makes only sense if you don't need accuracy lower than
> 2 meters.
>
> You might pick up one of the WGS 84 realization, and use the time-dependent
> transformations I mentionned in my previous email to go from GDA94 or GDA2020
> to that realization.
>
> Even
>
--
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254

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

Re: [gdal-dev] Static/Dynamic datum problems

Duncan Agnew
All:

        As a geophysicist who studies crustal deformation, I'll weigh
in and say that the issue is not (I think) the dynamic nature of the
datum, but plate tectonics.

        Taking WGS84 (of various dates) to be matched to the various
releases of the ITRF, I'd say that the latter is as fixed as it is
possible to make it: origin at the Earth's center of mass, Z axis
to the Conventional International Origin, X axis defined so the X-Z
plane is parallel to the local vertical through Greenwich (to maintain
continuity of Universal Time). The ITRF deals with plate tectonics
by including a model of what the plate motions are, and then chooses
a variation of orientation that makes the these motions,
averaged over the Earth, zero: as close as we can get to "average
Earth motion". As the data series get longer and the coverage better,
there are new releases, but the differences between them are small.

        What isn't small is the plate motion relative to this system:
in it, a location on the Australian plate moves northeast at the rate
of of 1.8 m from 1994 to 2020. This isn't because of updates to the
datum, it is because the ITRF coordinate system is designed to be fixed
relative to the average Earth. That is, the datum, and the coordinate
system, is fixed, but the location of a point on the ground in that
system varies with time.

        The only way around this, so far as I know, is to include dates
with coordinates and have some code that will allow you to convert
measured coordinates between epochs. For Australia, Europe, and much
of North America this is just a time-dependent shift that is nearly the
same everywhere: on a plate boundary it is a lot more complicated, as
is shown by the NGS HTDP program, which has lots of grids and allowances
for earthquakes.

        In summary: the different releases of the WGS/ITRF are different,
but this doesn't make them "dynamic datums": they are fixed, to the
the Earth on average, but relative to that different parts of the Earth's
surface are moving. Not a new problem, but one that complicates things.

        Hope this clarifies rather than muddies.

Thanks
Duncan Agnew

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

Re: [gdal-dev] Static/Dynamic datum problems

Nick Mein
Hi Duncan, Cameron,

Interesting discussion. As far as terminology is concerned, refer to, eg Donnelly et. al Dynamic Datum Transformations in Australia and New Zealand:

The points being measured are attached to the surface of the Earth, which is continually moving due to crustal
dynamics and other localised deformations. Thus if a point is regularly re-measured, its coordinates will change to
reflect the reality that the point’s relationship to the centre of the Earth has changed due to crustal dynamics. A
reference frame or datum which enables this changing position to be tracked is referred to as ‘dynamic’. 

I believe that is common usage. A reference frame in which coordinates of points on the surface of the earth are more-or-less constant over time is referred to as being "static" or "plate fixed". An exemplar is GDA2020. A reference frame in which coordinates of points on the surface of the earth are time dependent is referred to as being "dynamic".

As Cameron points out, this is muddied by the fact that WGS-84 was originally considered to be a "static" datum, and is still treated as such by a lot of software. See Mike Craymer's Making Sense of Evolving Datums: WGS84 and NAD83 for a nice overview.

Cameron's proposed solution is:

To support web-mapping use cases, at centimetre level accuracy, we require an internationally accepted static datum (and accompanying projection). As WGS84 Web-Mercator has become the world’s defacto-standard, we propose that the international community select, and lock in a specific WGS84 epoch (date)

Actually, I suggest that the solution is more along the lines of making sure that any spatial data set is clearly tagged with the reference frame that it refers to. That gives us a chance of being able to combine data sets. For example, if you have a data set referring to GDA94, with a known accuracy, and you have a second data set referring to GDA2020, with a known accuracy, and you have a transformation GDA94 -> GDA2020, with known accuracy, then you can make a reasonable estimate of how well the two data sets will fit together. In practice, the reference frame for a cm level data set is going to be either one of the ITRF's (eg ITRF2014) or it is going to be a national datum (eg GDA2020). We need to reserve the term "WGS-84" to refer to positions based on broadcast GPS orbits - having an accuracy of a couple of meters.

Regards,
Nick.


On Sun, 23 Jun 2019 at 19:00, Duncan Agnew <[hidden email]> wrote:
All:

        As a geophysicist who studies crustal deformation, I'll weigh
in and say that the issue is not (I think) the dynamic nature of the
datum, but plate tectonics.

        Taking WGS84 (of various dates) to be matched to the various
releases of the ITRF, I'd say that the latter is as fixed as it is
possible to make it: origin at the Earth's center of mass, Z axis
to the Conventional International Origin, X axis defined so the X-Z
plane is parallel to the local vertical through Greenwich (to maintain
continuity of Universal Time). The ITRF deals with plate tectonics
by including a model of what the plate motions are, and then chooses
a variation of orientation that makes the these motions,
averaged over the Earth, zero: as close as we can get to "average
Earth motion". As the data series get longer and the coverage better,
there are new releases, but the differences between them are small.

        What isn't small is the plate motion relative to this system:
in it, a location on the Australian plate moves northeast at the rate
of of 1.8 m from 1994 to 2020. This isn't because of updates to the
datum, it is because the ITRF coordinate system is designed to be fixed
relative to the average Earth. That is, the datum, and the coordinate
system, is fixed, but the location of a point on the ground in that
system varies with time.

        The only way around this, so far as I know, is to include dates
with coordinates and have some code that will allow you to convert
measured coordinates between epochs. For Australia, Europe, and much
of North America this is just a time-dependent shift that is nearly the
same everywhere: on a plate boundary it is a lot more complicated, as
is shown by the NGS HTDP program, which has lots of grids and allowances
for earthquakes.

        In summary: the different releases of the WGS/ITRF are different,
but this doesn't make them "dynamic datums": they are fixed, to the
the Earth on average, but relative to that different parts of the Earth's
surface are moving. Not a new problem, but one that complicates things.

        Hope this clarifies rather than muddies.

Thanks
Duncan Agnew
_______________________________________________
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: [gdal-dev] Static/Dynamic datum problems

Even Rouault-2
In reply to this post by Duncan Agnew
>         In summary: the different releases of the WGS/ITRF are different,
> but this doesn't make them "dynamic datums": they are fixed, to the
> the Earth on average, but relative to that different parts of the Earth's
> surface are moving. Not a new problem, but one that complicates things.

I believe one hurdle in that area (at least for a non-geodesist / non-
geophysist professional like me) is that the terminology seems to be somewhat
fluctuating depending on speakers and a bit confusing in itself (not speaking
here about even more complex beasts like NZGD2000 "semi-dynamic" datum)

ITRF realizations are considered by the ISO TC211 / OGC CRS WG as Dynamic
reference frame.
See https://docs.opengeospatial.org/as/18-005r4/18-005r4.html#116
Given their definitions, my understanding is that any datum / CRS into which
you need to qualify coordinates with an epoch is considered as a dynamic datum
/ CRS.
The IOGP "Geomatics Guidance Note 25 – Dynamic versus static CRSs and use of
the ITRF" (
https://www.iogp.org/bookstore/product/geomatics-guidance-note-25-dynamic-versus-static-crss-and-use-of-the-itrf/ ) also classifies ITRF and WGS84 as
dyanmic reference frames.

At bottom of page 16 of this guidance note, there is even a quite funny
discussion about whether NAD83(2011) should be considered as a static or
dynamic CRS... The bottom line seems to be that it is in essence dynamic, but
in practice, it is recommended to always express coordinates at epoch 2010.00

~~~

But those terminology discussions don't solve Cameron's pratical problem which
is  that when transforming data that is originally in GDA94 or GDA2020 to
WGS84 or WebMercator (using WGS84), the recommended transformations in EPSG,
ESRI, etc... are null transformations, causign misalignments when mixing
sources from GDA94 and GDA2020.

Using "some" realization of WGS84 with coordinates expressed at "some" epoch  
is perhaps not the best solution, since there are not so many accurate
transformations published from fixed-plate datum to WGS84. Looking at a few
"modern" CRS, it seems they are snapshots of ITRF realizations, with published
transformations to ITRF realizations.
For example EPSG:8049 is "ITRF2014 to GDA2020 (1)" with an accuracy of 1mm,
but EPSG:8848 is "GDA2020 to WGS 84 (G1762) (1)" (which uses the same
parameters as EPSG:8049, at the sign difference excepted, due to the different
direction of the transformation), is advertized to have an accuracy of 20cm.
There is no transformation published from GDA94 to any WGS84 realization other
than the generic one.
ITRF being defined from many sources, including satelite positionning, I guess
we can assume it is inherently more accurately defined, right ?. Using
something ITRF based would also have the communication advantage to no longer
use the "WGS84" word for such a global CRS, and thus mark the break with the
current practice.

So one could:
- select a ITRF realization (currently ITRF2014), and a
more or less arbitrary coordinate epoch into which to express coordinates.
- ask all mapping agencies to publish official coordinate operations (possibly
concatenated operations when coming from older CRS) from the popular fixed-
plate CRS (or dynamic CRS if those are the one adopted!) to that ITRF
realization. The data might be already there. For example if that would
ITRF2014, for GDA2020, there is a GDA2020->ITRF2014 transformation. But for
GDA94, which path should be taken: GDA94->GDA2020->ITRF2014, or GDA94->
ITRF2005->ITRF2014 or GDA94->ITF2008->ITRF2014, or ... ? But as the epoch that
would be selected would never be the epoch at which all fixed-plate CRS are
related to ITRF, you need transformations that take into account at least
plate motion (15-parameter Helmert might be sufficient for that), but if you
need more accuracy, you might also need deformation models (grid based).
- that procedure should be repeated every 5 or 10 years, so as to minimize the
difference between up-to-date coordinates and the one of the CRS. So if you
decide for a 5 year cycle, then the coordinate epoch could be the middle date
of the cycle: for example for 2020-2025, use 2022.50, etc.

[[[[ (if you're a geodesit, make sure the ceiling is high enough :-)

Or... I've a completely crazy idea, likely unsound from a geodesic point of
view, but that might have some practical merits...

Let's define a "global mosaiced static CRS", that is the union / pachwork of
the national/regional/continental CRS in current use.
For example right now, we would use GDA2020 in Australia, ETRS89 in Europe
(*), NAD83(2011) for USA, NAD83(CSRS)v7 for Canada, JGD2011 for Japan, etc...
One issue in the definition of this global CRS is that some of those
constituent CRS are dynamic, so a coordinate epoch should also be selected for
those (not necessarily the same globally though. you might use 2010.0 for
NAD83(2011) and something else for NAD83(CSRS)v7.

Advantages :
- in most cases, no datum transformation needed if you operate with recent
enough data. (or a well-known one, like GDA94->GDA2020, NZGD49->NZGD2000,
etc...)
- the fact that there is no datum transformation is not only saving
computation time, but also solves the practical issue of getting
transformation parameters. Not all grids needed to do some accurate
transformations are available as open data, or easily available at all.
- coordinates in that CRS would have a legal validity in all considered areas,
if you've selected constituent CRS that have a legal value.

Drawbacks:
- inconsistencies at the border between those CRSs, let's say the USA - Canada
border, so seamless maps will show annoying discontinuities in those areas.
(but I'm thinking that even with the previous ITRF based approach, you would
also have discontinuities, as the transformation parameters might not be
consistent on each side of borders, but probably the shift would be one or two
order of magnitude lower than the gross approach of the global mosaiced
static CRS)
- related to that: distance measurements that span over several of those
countries/continents, etc will have an inaccuracy of possibly some metre
level, wheras measurements inside one of those region will be as good as the
original datum is !
- those effects can be minimized if it is possible to use constituent CRS that
are snapshots of close enough ITRF realization at a close enough same epoch...
- if a constituent CRS is a dynamic CRS, then you still have the complexity of
doing time-based transformations.

Like the ITRF-based solution, that process should be repeated every 5 or 10
years to take into account the adoption of new static regional CRS and define
a new version of this global mosaiced static CRS.
]]]]]

Anyway, I guess any solution based on a static global CRS will involve
repeating the definition process at regular interval (to avoid the current
mess with 'WGS84'), so that Earth-fixed positions measured today and the
corresponding ones on the static CRS don't diverge too much.

In both cases, you could still use the WebMercator projection parameters to
transform the geographic coordinates to projected ones. So that would not be
EPSG:3857, but something similar based on the global CRS. Actually, if you use
the ITRF-based approach, it would be rather good to adopt a 'real' Mercator
projection doing computation on the ellipsoid, like EPSG:3395 "WGS 84 / World
Mercator", instead of the botched Popular Visualisation Pseudo-Mercator method
of EPSG:3857 that has unpleasant cartographic properties (non-conformal, see
https://www.slideshare.net/NGA_GEOINT/ngas-position-on-webmercator)

Even

(*) But this is also tricky since ETRS89 is a system with multiple ETRFyy
realizations, linked to ITRFyy realizations. The latest is ETRF2014. Each
country may adopt a different ETRS89 realization. For example RGF93, the legal
system in France, happens to be ETRS89 by realization of ETRF2000 at epoch
2009.00 (in its v2. RGF93 v1 was ETRS89 by realization of ETRF93 @1993.00).

--
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: [gdal-dev] Static/Dynamic datum problems

Cameron Shorter

Thanks for all the feedback so far.

For those CCed who are not on the email list, I suggest joining here: https://lists.osgeo.org/mailman/listinfo/proj

You can see other's comments in the archives here: https://lists.osgeo.org/pipermail/proj/2019-June/thread.html

Nick Brown has provided significant feedback to my original version of the doc: https://docs.google.com/document/d/15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0/

* He has provided clarifications on terminology which is good. But the document is a bit of a mess now. I'll give others a few days to add comments, and then I will have another go a cleaning it up.

* Nick, you have raised concerns about "WGS84 Web Mercator" being a poor choice for accurate mapping. While this may be valid, I urge we treat that concern as a separate issue. Solving it will likely require significantly more inertia which has potential to derail the static/dynamic map alignment problems we have with GDA94/GDA2020/WGS84.

* Others, thanks for the feedback, ideas, and links to source material. I'm expecting we will have quite a bit more material to cover.


On 24/6/19 5:53 pm, Even Rouault wrote:
        In summary: the different releases of the WGS/ITRF are different,
but this doesn't make them "dynamic datums": they are fixed, to the
the Earth on average, but relative to that different parts of the Earth's
surface are moving. Not a new problem, but one that complicates things.
I believe one hurdle in that area (at least for a non-geodesist / non-
geophysist professional like me) is that the terminology seems to be somewhat 
fluctuating depending on speakers and a bit confusing in itself (not speaking 
here about even more complex beasts like NZGD2000 "semi-dynamic" datum)

ITRF realizations are considered by the ISO TC211 / OGC CRS WG as Dynamic 
reference frame.
See https://docs.opengeospatial.org/as/18-005r4/18-005r4.html#116
Given their definitions, my understanding is that any datum / CRS into which 
you need to qualify coordinates with an epoch is considered as a dynamic datum 
/ CRS.
The IOGP "Geomatics Guidance Note 25 – Dynamic versus static CRSs and use of 
the ITRF" (
https://www.iogp.org/bookstore/product/geomatics-guidance-note-25-dynamic-versus-static-crss-and-use-of-the-itrf/ ) also classifies ITRF and WGS84 as 
dyanmic reference frames.

At bottom of page 16 of this guidance note, there is even a quite funny 
discussion about whether NAD83(2011) should be considered as a static or 
dynamic CRS... The bottom line seems to be that it is in essence dynamic, but 
in practice, it is recommended to always express coordinates at epoch 2010.00

~~~

But those terminology discussions don't solve Cameron's pratical problem which 
is  that when transforming data that is originally in GDA94 or GDA2020 to 
WGS84 or WebMercator (using WGS84), the recommended transformations in EPSG, 
ESRI, etc... are null transformations, causign misalignments when mixing 
sources from GDA94 and GDA2020.

Using "some" realization of WGS84 with coordinates expressed at "some" epoch  
is perhaps not the best solution, since there are not so many accurate 
transformations published from fixed-plate datum to WGS84. Looking at a few 
"modern" CRS, it seems they are snapshots of ITRF realizations, with published 
transformations to ITRF realizations.
For example EPSG:8049 is "ITRF2014 to GDA2020 (1)" with an accuracy of 1mm, 
but EPSG:8848 is "GDA2020 to WGS 84 (G1762) (1)" (which uses the same 
parameters as EPSG:8049, at the sign difference excepted, due to the different 
direction of the transformation), is advertized to have an accuracy of 20cm. 
There is no transformation published from GDA94 to any WGS84 realization other 
than the generic one.
ITRF being defined from many sources, including satelite positionning, I guess 
we can assume it is inherently more accurately defined, right ?. Using 
something ITRF based would also have the communication advantage to no longer 
use the "WGS84" word for such a global CRS, and thus mark the break with the 
current practice.

So one could:
- select a ITRF realization (currently ITRF2014), and a
more or less arbitrary coordinate epoch into which to express coordinates. 
- ask all mapping agencies to publish official coordinate operations (possibly 
concatenated operations when coming from older CRS) from the popular fixed-
plate CRS (or dynamic CRS if those are the one adopted!) to that ITRF 
realization. The data might be already there. For example if that would 
ITRF2014, for GDA2020, there is a GDA2020->ITRF2014 transformation. But for 
GDA94, which path should be taken: GDA94->GDA2020->ITRF2014, or GDA94-> 
ITRF2005->ITRF2014 or GDA94->ITF2008->ITRF2014, or ... ? But as the epoch that 
would be selected would never be the epoch at which all fixed-plate CRS are 
related to ITRF, you need transformations that take into account at least 
plate motion (15-parameter Helmert might be sufficient for that), but if you 
need more accuracy, you might also need deformation models (grid based).
- that procedure should be repeated every 5 or 10 years, so as to minimize the 
difference between up-to-date coordinates and the one of the CRS. So if you 
decide for a 5 year cycle, then the coordinate epoch could be the middle date 
of the cycle: for example for 2020-2025, use 2022.50, etc.

[[[[ (if you're a geodesit, make sure the ceiling is high enough :-)

Or... I've a completely crazy idea, likely unsound from a geodesic point of 
view, but that might have some practical merits...

Let's define a "global mosaiced static CRS", that is the union / pachwork of 
the national/regional/continental CRS in current use.
For example right now, we would use GDA2020 in Australia, ETRS89 in Europe 
(*), NAD83(2011) for USA, NAD83(CSRS)v7 for Canada, JGD2011 for Japan, etc...
One issue in the definition of this global CRS is that some of those 
constituent CRS are dynamic, so a coordinate epoch should also be selected for 
those (not necessarily the same globally though. you might use 2010.0 for 
NAD83(2011) and something else for NAD83(CSRS)v7.

Advantages :
- in most cases, no datum transformation needed if you operate with recent 
enough data. (or a well-known one, like GDA94->GDA2020, NZGD49->NZGD2000, 
etc...)
- the fact that there is no datum transformation is not only saving 
computation time, but also solves the practical issue of getting 
transformation parameters. Not all grids needed to do some accurate 
transformations are available as open data, or easily available at all.
- coordinates in that CRS would have a legal validity in all considered areas, 
if you've selected constituent CRS that have a legal value.

Drawbacks:
- inconsistencies at the border between those CRSs, let's say the USA - Canada 
border, so seamless maps will show annoying discontinuities in those areas. 
(but I'm thinking that even with the previous ITRF based approach, you would 
also have discontinuities, as the transformation parameters might not be 
consistent on each side of borders, but probably the shift would be one or two 
order of magnitude lower than the gross approach of the global mosaiced 
static CRS)
- related to that: distance measurements that span over several of those 
countries/continents, etc will have an inaccuracy of possibly some metre 
level, wheras measurements inside one of those region will be as good as the 
original datum is !
- those effects can be minimized if it is possible to use constituent CRS that 
are snapshots of close enough ITRF realization at a close enough same epoch...
- if a constituent CRS is a dynamic CRS, then you still have the complexity of 
doing time-based transformations.

Like the ITRF-based solution, that process should be repeated every 5 or 10 
years to take into account the adoption of new static regional CRS and define 
a new version of this global mosaiced static CRS. 
]]]]]

Anyway, I guess any solution based on a static global CRS will involve 
repeating the definition process at regular interval (to avoid the current 
mess with 'WGS84'), so that Earth-fixed positions measured today and the 
corresponding ones on the static CRS don't diverge too much.

In both cases, you could still use the WebMercator projection parameters to 
transform the geographic coordinates to projected ones. So that would not be 
EPSG:3857, but something similar based on the global CRS. Actually, if you use 
the ITRF-based approach, it would be rather good to adopt a 'real' Mercator 
projection doing computation on the ellipsoid, like EPSG:3395 "WGS 84 / World 
Mercator", instead of the botched Popular Visualisation Pseudo-Mercator method 
of EPSG:3857 that has unpleasant cartographic properties (non-conformal, see
https://www.slideshare.net/NGA_GEOINT/ngas-position-on-webmercator)

Even

(*) But this is also tricky since ETRS89 is a system with multiple ETRFyy 
realizations, linked to ITRFyy realizations. The latest is ETRF2014. Each 
country may adopt a different ETRS89 realization. For example RGF93, the legal 
system in France, happens to be ETRS89 by realization of ETRF2000 at epoch 
2009.00 (in its v2. RGF93 v1 was ETRS89 by realization of ETRF93 @1993.00).

-- 
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254

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

Re: [gdal-dev] Static/Dynamic datum problems

Cameron Shorter
In reply to this post by Cameron Shorter

Hi proj folks, I'm sharing insights from Scott Simmons from the OGC, with his permission ...

On 25/6/19 5:02 pm, Scott Simmons wrote:
Hi Cameron,

I am glad that you are taking up this charge as well - this is a HUGE issue.

<snip>

A few data points to consider.

1. The OGC Abstract Specification Topic #2 Referencing by Coordinates (also ISO 19111:2019): http://docs.opengeospatial.org/as/18-005r4/18-005r4.html was specifically updated to address 4D coordinate reference systems (CRSs) earlier this year. This standard forms the foundation for how CRSs are used in other OGC and ISO standards.

2. Other OGC standards will automatically benefit from dynamic CRSs if they leverage Referencing by Coordinates. We also have a handful of temporal standards (like TimeseriesML). But many geometry standards won’t get much out of these changes if the data don’t include temporal information - huge issue!

3. We are in the midst of updating the Features and Geometries standard such that it will also subsume Simple Features. Now is a good time to ensure that time is adequately handled in this work.

4. We have both a CRS Domain and Standards Working Group (CRS DWG and CRS SWG). The CRS DWG would be a good forum to develop the requirements to push to other SWGs handling geometry standards. I’d be happy to help setup such a discussion at our next TC Meeting.

5. And speaking of the next TC Meeting (starting 9 September 2019 in Banff, Canada), we will have a keynote presentation and systems update from the US GPS team.

Best Regards,
Scott
<snip>
-- 
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254

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