[PROJ] [gdal-dev] Static/Dynamic datum problems

[Cameron Shorter]

Thanks for all the feedback so far.

For those CCed who are not on the email list, I suggest joining here: 
https://lists.osgeo.org/mailman/listinfo/proj

You can see other's comments in the archives here: 
https://lists.osgeo.org/pipermail/proj/2019-June/thread.html

Nick Brown has provided significant feedback to my original version of 
the doc: 
https://docs.google.com/document/d/15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0/ 
<https://docs.google.com/document/d/15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0/edit#>

* 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.

* 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.

* Others, thanks for the feedback, ideas, and links to source material. 
I'm expecting we will have quite a bit more material to cover.


On 24/6/19 5:53 pm, Even Rouault wrote:
>>          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.
> 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 https://docs.opengeospatial.org/as/18-005r4/18-005r4.html#116
> 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" (
> https://www.iogp.org/bookstore/product/geomatics-guidance-note-25-dynamic-versus-static-crss-and-use-of-the-itrf/ ) 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
> https://www.slideshare.net/NGA_GEOINT/ngas-position-on-webmercator)
>
> 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).
>
-- 
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20190624/4ceb5307/attachment-0001.html>