Re: WGS84 / Web Mercator discussion in Australia

I'm following the discussions on the PROJ list with great interest.  New Zealand also has a history of grappling with a dynamic datum and with complex deformation, so this question as well as those around dynamic/static datums are of great interest.  While I've not had the time to respond at length on the NZ experience I very much appreciate this discussion so thank you.

However FWIW Nic Donnelly did some work a while ago summarising the relationship of WGS84 realisations which is present in  https://www.linz.govt.nz/system/files_force/media/file-attachments/donnelly-development-of-modern-geodetic-system-in-nz.ppt?download=1

We also had long discussions with our Australian colleagues around terminology, especially dynamic/static.  In the end these seemed too ambiguous (relative to what), and too imprecise (there are more than two options).  Instead we found it more useful to use terms such as "earth-fixed", "plate-fixed".  However it is hard to break these habits.

Chris Crook
________________________________________
From: PROJ [[email protected]] on behalf of Cameron Shorter [[email protected]]
Sent: Saturday, 3 August 2019 8:32 a.m.
To: [email protected]
Cc: Joel Haasdyk; Gordon Sumerling; Kevin M. Kelly; HIGGINS Matt
Subject: [PROJ] WGS84 / Web Mercator discussion in Australia

proj list,

I'm sharing a few email snippets from this week, with permission. (One
contributor is missing as they have been sick, and I haven't gain their
permission to share yet.)

On 25/7/19 3:31 pm, Kevin M. Kelly (ESRI) wrote:
 > Geodetically, the proposed solution makes much more sense than
equating GDA2020 with WGS84. It also maintains the equivalence of GDA94
and WGS84. Below are a few fine points of clarification. I am certain
this will be confusing, but it’s the new normal in geodetic datum
management.
 > GDA94 is aligned to ITRF92 at epoch 1994.0 and GDA2020 is aligned to
ITRF2014 at epoch 2020.0. In the WGS84 series of realizations, GDA94 is
most closely aligned with WGS84(G730), which is itself aligned to ITRF91
at epoch 1994.0.

On 31/7/19 3:16 am, Kevin M. Kelly (ESRI) wrote:
 > Thank you immensely Matt and Joel for your comments/answers to
Cameron’s questions. You have made my task to provide those answers
pretty much non-existent. Matt is spot on in all his responses and I
have little more relevant information to add. Note, I am not the best to
ask about recommendations on EPSG codes. Melita Kennedy is our the
authority on that and I’ll defer to her to comment on Esri
implementation of EPSG codes.
 > I have only some general comments that support what’s already been
said by Matt and Joel. Unfortunately, the generic WGS84 Web Mercator
debacle is too deeply entrenched to muddy it up with modifications at
this stage. I agree with Matt, leave it alone. For those with data
referenced to a mixture of WGS84 realizations (and perhaps other
frames), there is no accurate way to homogenize the data to a common
frame and epoch. I’ll qualify that to say that you may be able to
homogenize and maintain much of the accuracy of your data if they all
have epochs associated with them and it is known to which WGS84
realization (or other frame) they refer. Then there may be a chance to
transform them to a common frame and epoch, but this would likely be a
cost-prohibitive task, especially for large databases. And moreover, few
data in Web mapping applications carry these metadata. So, moot point!
 > What I can say is, if you’re lucky enough to have the opportunity to
design a web-mapping application from scratch, and you expect to store
and display accurately positioned data (e.g. high-accuracy GNSS): (1)
don’t use Web Mercator base maps and (2) make sure to carry/store the
reference frame (datum), its realization if applicable, and epoch
metadata with every single feature! Sorry, if it that’s no consolation
to those with existing Web Mercator type web map implementations that
lack these metadata.
 > Just an FYI, I am currently co-authoring a paper on the relationship
between the various realizations of WGS84 and between them and ITRF. The
paper is, in part, a response to the generic WGS84 debacle and the lack
of awareness among geospatial professionals, especially in the GIS
arena, of this problem. The paper is primarily educational but will also
provide some approximate solutions. We intend to publish the paper not
in a geodesy journal, but in some GIS or surveying journal (not sure
which one yet) because that is the audience we’d like to reach.

On 25/7/19 5:02 pm, Joel Haasdyk (GDA2020 Implementation Program Manager
(NSW)) wrote:
 > 1)      Gordon (ESRI Australia) comment of 19/07/2019: “Further, as
of writing today, Esri have not implemented GDA2020 to WGS84 Web
Mercator as a null transformation. I am working with them to see if we
can get this included. No timeline as yet.”
 > Joel Hassdyk: This strikes me as something ESRI should be reticent to
change before these conversations are concluded.
 > Joel Hassdyk: I feel that ESRI has successfully implemented a
practical solution to this Web Mercator problem.  I would be reticent to
change that now:
 > Joel Hassdyk: 1)      WGS84 <=> GDA2020 NULL Tf not currently
implemented.
 > Joel Hassdyk: 2)      WGS84 = GDA94 ó GDA2020 ‘two-step’ or
‘concatenated’ process implemented (e.g. ArcGIS Pro 2.1)

 > External comment 25/07/2019: “but there are many applications that
need to use Web Mercator and GDA2020 data together. If the datasets in
each CRS are low resolution (e.g. a GDA2020 koala habitat polygon on a
Google map) then overlaying with 8450 as a null transformation is fine.”
 > Joel Hassdyk: Is there any harm in NOT offering any TF (force user to
assume equivalence? Confusing?), or in fact using the concatenated Tf,
in these instances?
 > Joel Hassdyk: 2)      Adopting a 1994.0 epoch  (vs 2020.0 epoch) for
ongoing WGS84-based web-mapping as the short term solution for the
Australian issue.
 > Joel Hassdyk: WGS84 to implicitly adopt 2020.0 epoch:  GDA94 ó [WGS84
= GDA2020] (to ‘replace’ EPSG 1150)          has been recently suggested
in M.Giudici’s proposal.
 > Joel Hassdyk: WGS84 to implicitly adopt 1994.0 epoch: GDA2020 ó
[WGS84 = GDA94] (to ‘replace’ EPSG 8450)          is a similar solution.
 > Joel Hassdyk: I would lean towards the latter (WGS84 implicitly
adopting 1994.0 epoch for Australian purposes).
 > Joel Hassdyk: This is to cater for existing users who implicitly
employ WGS84 in the 1994.0 epoch, in the form of GDA94 datasets which
have been published and stored nominally as ‘WGS84’.
 > Joel Hassdyk:               It will be much easier (necessary?) in
the short term to bring new data to these users, rather than the old
data to the new epoch. [Cameron has previously argued this].

 > External comment 25/07/2019: “Also using the @1994 coincidence to
conclude that all use of WGS84 in Australia is WGS84(G730), is reading
too much into it. There would be lots of data in Australia on the
various realizations of WGS84 and at various epochs. If I gather GPS
data using the broadcast orbits today (anywhere in the world including
Australia) it is WGS84(G1762)@2019.5.”
 > Joel Hassdyk: I would think that the number of users with WGS84 truly
representing ‘epoch of observation’ would be small compared to users
with [email protected] .   Happy to be shown otherwise! Lets discuss.

 > Cameron Shorter comments of 24/07/2019:
 > “To address the epoch misalignment you mention, I’m proposing that we
define a new static “Web Datum” which mirrors current implementations”
 > Joel Haasdyk: This certainly addresses the issue that the current
WGS84(generic) usage is a mixed bag; Maybe we should call it what is it
actually is!.
 > Joel Haasdyk: However, I can’t see this as a short term solution.
Perhaps a medium term solution, that is, until the longer term
time-dependence issues are better addressed.
 > Joel Haasdyk: I’m just not sure what would / could motivate people to
change this this new definition, other than that is it more explicit
about the epoch(s) employed in various regions. [It would be a mess to
define well though].

--
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254

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

________________________________

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 [email protected]) 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
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj