[PROJ] Dynamic/static WGS84 datum problem with web-mapping and map misalignment

[Cameron Shorter]

Sharing email thread from Roger Lott and Joel Haasdyk on this topic, 
with permission. (changed to plain text to fit under email list size limit).

On 31/7/19 2:32 am, Roger Lott (EPSG) wrote:
Australia is not the only place with this problem – it is global. But 
because the Australian plate is moving faster than most, the problem is 
more acute for you. There are a number of issues here. Joel has 
summarised many of the geodetic aspects. But as I see it the real 
problems are (i) lack of publicity/education, (ii) software inadequacies 
(in part as a result of (i)).

·        First we have the issue of dynamic reference 
frames/datums/CRSs. The issue has been well understood for a long time 
in the geodetic community but not much outside that community. It is 
therefore an issue of education. It has become significant only 
recently, partially through improvements in real-time positioning 
technology and partially due to the time lapse since satellite 
technology was first used for defining national CRSs and the plate 
movement over that period since then. ISO and OGC standards for defining 
CRSs have recently been updated to emphasise the distinction between 
static and dynamic frames/datums. This update potentially provides a 
vehicle for some education.

·        The ISO/OGC data model includes a 'transformation accuracy' 
attribute. Joel cites that for the EPSG transformations from GDA to WGS 
84 which have an accuracy of 3m (agreed by Geoscience Australia geodesy 
division – talk to Dan Jaksa). But unfortunately very little if any 
software uses the information. The equality of two CRSs is only true 
within that accuracy. That is not widely understood and therefore is an 
issue of education. Deprecating these 'null' transformations as Joel 
suggests might alleviate the problem, but will not solve it. What 'null' 
means needs to be more generally understood.

·        GIS software typically uses a hub approach for transforming 
between two local datums/reference frames. Ideally, when a direct 
transformation such as GDA94 > GDA2020 is available, this should be 
used. Unfortunately much transformation software has been developed 
without that capability.. There is hope though. The Proj open source 
software library which underpins quite a lot of GIS software has 
recently been updated to proj.6 https://proj.org/ and this now chooses 
the direct route if available. Proj.6 is populated with EPSG data and 
will therefore choose one of the GDA94 to GDA2020 direct options 
(Helmert 7-parameter, NTv2 conformal or NTv2 conformal+ distortion), 
EPSG codes 8048, 8446 and 8447 respectively). (By default I imagine it 
will use the Helmert transformation, but I have cc'd this to Even 
Rouault who will be able to clarify this).

·        The hub approach has been emphasised through some extensions to 
well-known text definitions of CRSs that include a TOWGS84 attribute. 
The well-known text definition of CRSs was updated through so-called 
WKT2 deliberately omitted the TOWGS84 function, but phasing out of WKT1 
has been difficult. WKT2 has itself recently been updated to include the 
differentiation between static and dynamic CRSs and this perhaps is an 
opportunity to highlight the general issue. OGC's revised documentation 
is on the verge of publication, but is yet to be made. We should take 
the opportunity of using the OGS press release for that for highlighting 
this issue.

·        If a hub approach is to be used then the choice of the hub CRS 
may be critical. Using ETRS89 in Europe is a requirement of the INSPIRE 
Directives, but software rarely uses it, instead using WGS 84. The 
choice of WGS 84 has historic background, based on information available 
through the predecessor's of the US National Geospatial Agency and that 
agencies procurement requirements. 30 years ago it was a valid choice. 
Now it is less so. For two reasons:

o   Using a dynamic CRS as a hub will be problematic if no account is 
made of time dependency – an educational issue, but also a software 
problem in that there is little non-geodetic software currently 
implementing time-dependent transformation methods..

o    'WGS 84' is ambiguous. There have been six realizations of WGS 84, 
and this is not well known in the GIS community. This is about to be 
exposed as later this year IOGP will be changing its definition of 
EPSG::4326 to be based on a datum ensemble (currently only indicated by 
remarks in the datum definition, which nobody reads) and I am expecting 
an avalanche of uniformed comment on internet forums

o    The formal realizations of WGS 84 – Transit and all G realizations 
– are dynamic. Coordinates change with time. To be unambiguous 
coordinate metadata needs to include coordinate epoch.

o    WGS 84 as described through EPSG::4326 represents any or all of the 
formal realizations, without distinction. It is considered to be static, 
with a several metre uncertainty.

In populating the EPSG dataset with copies of transformations to WGS 84, 
IOGP has assisted the use of the hub transformation technique. We will 
be reviewing our policy for that in our October meeting, so if anyone 
has any views that they would like to be taken into consideration, let 
me know.

In association with that meeting in Houston we will be hosting an 
'industry day' conference devoted to the theme of dynamic CRSs. Although 
geared to the oil industry some of the material being prepared for it 
may have broader application.

For web mapping purposes, I believe that consideration is being given to 
updating the OGC WMS specification. If a revision of WMS is to happen, 
this is a huge opportunity to expose the issues discussed in this email 
trail to the geospatial software development community. But we have to 
remain cognoscente of the fact that anyone who is happy with spatial 
referencing no better than 2 or 3 metres accuracy has no interest in 
these complications. There is a balance to be struck in explaining that 
although of particular interest to geodesists chasing mm, it cannot be 
avoided for many 'normal' spatial referencing requirements. However it 
seems to me that a WMS spec revision is a huge opportunity to make WMS 
developers aware of the issues associated with dynamic CRSs and problems 
associated with the near-ubiquitous use of WGS 84.

Roger

---

From: Joel Haasdyk [mailto:joel.haasdyk at customerservice.nsw.gov.au]
Sent: 29 July 2019 21:32
To: Cameron Shorter; Roger Lott; Keith Ryden; Gobe Hobona
Cc: Cameron Shorter; Scott Simmons; Joseph Abhayaratna; Giudici, Michael 
(DPIPWE); Nicholas.Brown
Subject: RE: Dynamic/static WGS84 datum problem with web-mapping and map 
misalignment

Thanks Cameron, and Joe for this introduction,

If I were going to distil the immediate issue down to one page:

·       WGS84 ‘Web Mercator’, the defacto standard projection used for 
web-mapping, has simplified the datum on which it is based, of the same 
name, WGS84.

·       In practice, Web-Mercator ignores the fact that the true WGS84 
coordinates of a feature actually change over time to reflect the 
movement of the tectonic plates, and also that WGS84 itself has been 
redefined several times. WGS84 is ‘dynamic’.

·       Web-mapping based on Web-Mercator has generally implicitly 
chosen a time-stamp or ‘epoch’, usually based on the local national 
datum, at which to describe coordinates:
e.g. 01 Jan 1994 for the national ‘GDA94’ datum of Australia, and 01 Jan 
1989 for ETRS89 in Europe. WGS84 is treated as ‘static’ for web-mapping 
purposes.

·       Large amounts of data have historically been tiled and cached in 
WGS84 at this ‘local’ epoch.

·       As nations modernise datums, we will see new national datums 
defined, based on new modern epochs. For example, GDA2020 in Australia 
is a new static datum expressed at 01 Jan 2020. GDA94 ó GDA2020 
transformations describe the ~1.8 metre movement of the Australian 
tectonic plate over 26 years between epochs 1994.0 and 2020.0.

·       EPSG codes, which define how most software current define and 
transform between datums often include NULL transformations to WGS84. In 
Australia, this includes:

o   EPSG::1150 NULL transformation GDA94 ó WGS84 (nominal 3m accuracy)
o   EPSG::8450 NULL transformation GDA2020 ó WGS84 (nominal 3m accuracy)

·       Standard web-mapping applications apply these EPSG codes and 
transformations.  As a result, mapping data in both GDA94 and GDA2020, 
which represent Australian coordinates at different epochs, will result 
in misaligned datasets in WGS84 Web Mercator.

·       International collaboration is required to create and 
disseminate a solution to this issue before it affects an increasing 
number of regions who are modernising their datums;
e.g. Australia released GDA2020 in 2017; The U.S.A. plans to release new 
modernised datums in 2022.

·       The proposed solution is likely to be in two parts:

1)         Adopt a short term solution for the Australian context.
One proposal is to deprecate an existing EPSG code (e.g. the EPSG::8450 
WGS84 ó GDA2020 NULL transformation) and replace it with a 
transformation which brings all local data back into alignment at a 
conventional time-stamp.
The existing 1994.0 epoch, at which much WGS84 data already is tiled and 
stored, is a likely candidate, but the actual solution is currently up 
for debate.

2)         Pursue a longer-term solution for the global context.

For example, explicitly define a WGS84 version for web-mapping at 
conventional epoch. Perhaps even adopt a different epoch per region to 
reflect current practice in web-mapping..
Define a datum (or employ an existing datum such as ITRF) which more 
explicitly caters for time-dependent coordination, and update 
web-mapping applications to cater for the realities of tectonic plates, 
local deformation and coordinates that change over time.

Thanks,
Joel Haasdyk

<snipped the rest of the thread>

-- 
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254