[PROJ] WGS84 / Web Mercator discussion in Australia

[Cameron Shorter]

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 WGS84 at 1994.0 .   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