[PROJ] Dynamic/static WGS84 datum problem with web-mapping and map misalignment
cameron.shorter at gmail.com
Tue Jul 30 22:23:53 PDT 2019
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
· 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
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.
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
Subject: RE: Dynamic/static WGS84 datum problem with web-mapping and map
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
· 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
· 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
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
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.
<snipped the rest of the thread>
Open Technologies and Geospatial Consultant
M +61 (0) 419 142 254
More information about the PROJ