<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Thanks for all the feedback so far.</p>
<p>For those CCed who are not on the email list, I suggest joining
here: <a href="https://lists.osgeo.org/mailman/listinfo/proj">https://lists.osgeo.org/mailman/listinfo/proj</a></p>
<p>You can see other's comments in the archives here: <a
href="https://lists.osgeo.org/pipermail/proj/2019-June/thread.html">https://lists.osgeo.org/pipermail/proj/2019-June/thread.html</a></p>
<p>Nick Brown has provided significant feedback to my original
version of the doc: <a
href="https://docs.google.com/document/d/15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0/edit#">https://docs.google.com/document/d/15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0/</a></p>
<p>* He has provided clarifications on terminology which is good.
But the document is a bit of a mess now. I'll give others a few
days to add comments, and then I will have another go a cleaning
it up.</p>
<p>* Nick, you have raised concerns about "WGS84 Web Mercator" being
a poor choice for accurate mapping. While this may be valid, I
urge we treat that concern as a separate issue. Solving it will
likely require significantly more inertia which has potential to
derail the static/dynamic map alignment problems we have with
GDA94/GDA2020/WGS84. <br>
</p>
<p>* Others, thanks for the feedback, ideas, and links to source
material. I'm expecting we will have quite a bit more material to
cover.<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 24/6/19 5:53 pm, Even Rouault wrote:<br>
</div>
<blockquote type="cite" cite="mid:1869575.vOaMWDItcd@even-i700">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> In summary: the different releases of the WGS/ITRF are different,
but this doesn't make them "dynamic datums": they are fixed, to the
the Earth on average, but relative to that different parts of the Earth's
surface are moving. Not a new problem, but one that complicates things.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I believe one hurdle in that area (at least for a non-geodesist / non-
geophysist professional like me) is that the terminology seems to be somewhat
fluctuating depending on speakers and a bit confusing in itself (not speaking
here about even more complex beasts like NZGD2000 "semi-dynamic" datum)
ITRF realizations are considered by the ISO TC211 / OGC CRS WG as Dynamic
reference frame.
See <a class="moz-txt-link-freetext" href="https://docs.opengeospatial.org/as/18-005r4/18-005r4.html#116">https://docs.opengeospatial.org/as/18-005r4/18-005r4.html#116</a>
Given their definitions, my understanding is that any datum / CRS into which
you need to qualify coordinates with an epoch is considered as a dynamic datum
/ CRS.
The IOGP "Geomatics Guidance Note 25 – Dynamic versus static CRSs and use of
the ITRF" (
<a class="moz-txt-link-freetext" href="https://www.iogp.org/bookstore/product/geomatics-guidance-note-25-dynamic-versus-static-crss-and-use-of-the-itrf/">https://www.iogp.org/bookstore/product/geomatics-guidance-note-25-dynamic-versus-static-crss-and-use-of-the-itrf/</a> ) also classifies ITRF and WGS84 as
dyanmic reference frames.
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... The bottom line seems to be that it is in essence dynamic, but
in practice, it is recommended to always express coordinates at epoch 2010.00
~~~
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.
Using "some" realization of WGS84 with coordinates expressed at "some" epoch
is perhaps not the best solution, since there are not so many accurate
transformations published from fixed-plate datum to WGS84. Looking at a few
"modern" CRS, it seems they are snapshots of ITRF realizations, with published
transformations to ITRF realizations.
For example EPSG:8049 is "ITRF2014 to GDA2020 (1)" with an accuracy of 1mm,
but EPSG:8848 is "GDA2020 to WGS 84 (G1762) (1)" (which uses the same
parameters as EPSG:8049, at the sign difference excepted, due to the different
direction of the transformation), is advertized to have an accuracy of 20cm.
There is no transformation published from GDA94 to any WGS84 realization other
than the generic one.
ITRF being defined from many sources, including satelite positionning, I guess
we can assume it is inherently more accurately defined, right ?. Using
something ITRF based would also have the communication advantage to no longer
use the "WGS84" word for such a global CRS, and thus mark the break with the
current practice.
So one could:
- select a ITRF realization (currently ITRF2014), and a
more or less arbitrary coordinate epoch into which to express coordinates.
- ask all mapping agencies to publish official coordinate operations (possibly
concatenated operations when coming from older CRS) from the popular fixed-
plate CRS (or dynamic CRS if those are the one adopted!) to that ITRF
realization. The data might be already there. For example if that would
ITRF2014, for GDA2020, there is a GDA2020->ITRF2014 transformation. But for
GDA94, which path should be taken: GDA94->GDA2020->ITRF2014, or GDA94->
ITRF2005->ITRF2014 or GDA94->ITF2008->ITRF2014, or ... ? But as the epoch that
would be selected would never be the epoch at which all fixed-plate CRS are
related to ITRF, you need transformations that take into account at least
plate motion (15-parameter Helmert might be sufficient for that), but if you
need more accuracy, you might also need deformation models (grid based).
- that procedure should be repeated every 5 or 10 years, so as to minimize the
difference between up-to-date coordinates and the one of the CRS. So if you
decide for a 5 year cycle, then the coordinate epoch could be the middle date
of the cycle: for example for 2020-2025, use 2022.50, etc.
[[[[ (if you're a geodesit, make sure the ceiling is high enough :-)
Or... I've a completely crazy idea, likely unsound from a geodesic point of
view, but that might have some practical merits...
Let's define a "global mosaiced static CRS", that is the union / pachwork of
the national/regional/continental CRS in current use.
For example right now, we would use GDA2020 in Australia, ETRS89 in Europe
(*), NAD83(2011) for USA, NAD83(CSRS)v7 for Canada, JGD2011 for Japan, etc...
One issue in the definition of this global CRS is that some of those
constituent CRS are dynamic, so a coordinate epoch should also be selected for
those (not necessarily the same globally though. you might use 2010.0 for
NAD83(2011) and something else for NAD83(CSRS)v7.
Advantages :
- in most cases, no datum transformation needed if you operate with recent
enough data. (or a well-known one, like GDA94->GDA2020, NZGD49->NZGD2000,
etc...)
- the fact that there is no datum transformation is not only saving
computation time, but also solves the practical issue of getting
transformation parameters. Not all grids needed to do some accurate
transformations are available as open data, or easily available at all.
- coordinates in that CRS would have a legal validity in all considered areas,
if you've selected constituent CRS that have a legal value.
Drawbacks:
- inconsistencies at the border between those CRSs, let's say the USA - Canada
border, so seamless maps will show annoying discontinuities in those areas.
(but I'm thinking that even with the previous ITRF based approach, you would
also have discontinuities, as the transformation parameters might not be
consistent on each side of borders, but probably the shift would be one or two
order of magnitude lower than the gross approach of the global mosaiced
static CRS)
- related to that: distance measurements that span over several of those
countries/continents, etc will have an inaccuracy of possibly some metre
level, wheras measurements inside one of those region will be as good as the
original datum is !
- those effects can be minimized if it is possible to use constituent CRS that
are snapshots of close enough ITRF realization at a close enough same epoch...
- if a constituent CRS is a dynamic CRS, then you still have the complexity of
doing time-based transformations.
Like the ITRF-based solution, that process should be repeated every 5 or 10
years to take into account the adoption of new static regional CRS and define
a new version of this global mosaiced static CRS.
]]]]]
Anyway, I guess any solution based on a static global CRS will involve
repeating the definition process at regular interval (to avoid the current
mess with 'WGS84'), so that Earth-fixed positions measured today and the
corresponding ones on the static CRS don't diverge too much.
In both cases, you could still use the WebMercator projection parameters to
transform the geographic coordinates to projected ones. So that would not be
EPSG:3857, but something similar based on the global CRS. Actually, if you use
the ITRF-based approach, it would be rather good to adopt a 'real' Mercator
projection doing computation on the ellipsoid, like EPSG:3395 "WGS 84 / World
Mercator", instead of the botched Popular Visualisation Pseudo-Mercator method
of EPSG:3857 that has unpleasant cartographic properties (non-conformal, see
<a class="moz-txt-link-freetext" href="https://www.slideshare.net/NGA_GEOINT/ngas-position-on-webmercator">https://www.slideshare.net/NGA_GEOINT/ngas-position-on-webmercator</a>)
Even
(*) But this is also tricky since ETRS89 is a system with multiple ETRFyy
realizations, linked to ITRFyy realizations. The latest is ETRF2014. Each
country may adopt a different ETRS89 realization. For example RGF93, the legal
system in France, happens to be ETRS89 by realization of ETRF2000 at epoch
2009.00 (in its v2. RGF93 v1 was ETRS89 by realization of ETRF93 @1993.00).
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant
M +61 (0) 419 142 254</pre>
</body>
</html>