[gdal-dev] Static/Dynamic datum problems

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

[gdal-dev] Static/Dynamic datum problems

Cameron Shorter
Hi folks,

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. It results in mis-aligned maps in WGS84

I believe this is a problem the whole world needs to address, given the upcoming modernsation of significant national datums including the U.S and we need to bring this topic into an international conversation, ASAP.
I'm interested to know if anyone here is looking into and/or has opinions on how it should be solved. I'd like to incorporate your ideas into the recommendations that we are putting foward.
-- 
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254




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

Re: Static/Dynamic datum problems

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

Re: Static/Dynamic datum problems

Cameron Shorter
I've switched this email thread to  [hidden email] as suggested.

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

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




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

Re: [EXTERNAL] Static/Dynamic datum problems

Newcomb, Doug
In reply to this post by Cameron Shorter
Cameron,
 I just emailed  someone working on this .  He sent me the links below.  


On Thu, Jun 20, 2019 at 5:15 PM Cameron Shorter <[hidden email]> wrote:
Hi folks,

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. It results in mis-aligned maps in WGS84

I believe this is a problem the whole world needs to address, given the upcoming modernsation of significant national datums including the U.S and we need to bring this topic into an international conversation, ASAP.
I'm interested to know if anyone here is looking into and/or has opinions on how it should be solved. I'd like to incorporate your ideas into the recommendations that we are putting foward.
-- 
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254





--
Doug Newcomb - Cartographer
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 [hidden email]
---------------------------------------------------------------------------------------------------------

NOTE: This email correspondence and any attachments to and from this sender is subject to the Freedom of Information Act (FOIA) and may be disclosed to third parties.

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

Re: [EXTERNAL] Static/Dynamic datum problems

Cameron Shorter

I'm switching this email thread to [hidden email] (which is where the conversation has moved)

On 24/6/19 11:30 pm, Newcomb, Doug wrote:
Cameron,
 I just emailed  someone working on this .  He sent me the links below.  



-- 
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev