[PROJ] [EXTERNAL] [gdal-dev] Static/Dynamic datum problems

[Nick Mein]

Hi Evan, Cameron,

See https://docs.opengeospatial.org/as/18-005r4/18-005r4.html#116


That is a great document. Thanks for sharing!

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


It really depends on where you are working. Over most of the continental US
you can consider NAD83(2011) to be a static reference frame. (I.e. you can
consider the velocity of points to be zero.) But that isn't true if you are
working in California.

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.


Right. But there is a solution to Cameron's practical problem, which is to
transform his GDA94 dataset(s) to GDA2020.
In the longer term, we can all (practitioners, geospatial software
providers) help clear up misunderstandings by being more precise with our
terminology. Including pretending that there is such a thing as a precise
WGS-84 coordinate, or that GDA, GDA2020, NAD83, etc are equivalent to
"WGS-84".

Let's define a "global mosaiced static CRS", that is the union / pachwork of
> the national/regional/continental CRS in current use.


I'm pretty sure that is what products such as Google Maps must do, though
I'd love to get verification from someone that knows for sure.

A key point is - how do you access whatever reference frame you are using?
Traditionally you would do that by locating physical marks on the ground,
and looking up their published coordinates. Today, you are likely to using
a real time GNSS corrections network, or a post-processing service such as
OPUS/AUSPOS/etc, or you are going to be using a precise point positioning
service. The coordinates that you get are going to be either in a
local/regional reference frame such as GDA/NAD83/ETRF, or they are going to
be ITRF. For (large scale?) web mapping applications, munging together data
sets from different reference frames is fine. But ultimately you need to be
able to drill down to the original data.

Regards,
Nick.

On Tue, 25 Jun 2019 at 05:04, Cameron Shorter <cameron.shorter at gmail.com>
wrote:

> Thanks Doug, you have pointed me to Matt Higgins who is one of the
> Australians on this email's CC list. He has contributed toward identifying
> this problem. I believe we need to bring this conversation into an
> international forum, probably headed up by the OGC.
>
> You might be able to suggest who we should connect with?
>
> Warm regards, Cameron
> On 24/6/19 11:30 pm, Newcomb, Doug wrote:
>
> Cameron,
>  I just emailed  someone working on this .  He sent me the links below.
>
> https://www.gps.gov/governance/advisory/
>
> https://www.gps.gov/governance/advisory/members/higgins/
>
> Doug
>
> On Thu, Jun 20, 2019 at 5:15 PM Cameron Shorter <cameron.shorter at gmail.com>
> 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 doug_newcomb at fws.gov
>
> ---------------------------------------------------------------------------------------------------------
>
> *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.*​
>
> --
> Cameron Shorter
> Technology Demystifier
> Open Technologies and Geospatial Consultant
>
> M +61 (0) 419 142 254
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20190625/1d2c4923/attachment.html>