<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div class="">
<div class="">This is a great discussion! I am happy to see that people outside of the</div>
<div class="">geodesy community is starting to realise that things can’t continue as they</div>
<div class="">have been. We’ve certainly done our fair share of the work here in PROJ</div>
<div class="">community but as Cameron points out there’s still some ways to go. From the</div>
<div class="">discussion it seems to me that everyone is converging towards a common</div>
<div class="">understanding of dynamic reference frames and what the challenges of them are.</div>
<div class="">I have worked quite extensively with the topic over the last couple of years</div>
<div class="">(see [0] for a summary) and there’s two important things that has not been</div>
<div class="">touched in this discussion yet:</div>
<div class=""><br class="">
</div>
<div class="">1. WGS84 is practically equivalent to ITRF2008 and ITRF2014</div>
<div class=""><br class="">
</div>
<div class="">The two frames coincide at the cm level [1] and hence there’s a</div>
<div class="">null-transformation between the two systems. This fact can be leveraged to</div>
<div class="">expand the number of direct transformation between WGS84 and regional/nation</div>
<div class="">frames. As Even pointed out often times the transformation between WGS84 and</div>
<div class="">national frame registered by the EPSG is a null transformation. Often times</div>
<div class="">there will be a transformation to a ITRFxxxx that offers better accuracy. This</div>
<div class="">of course requires that coordinates come with a timestamp, which brings me to</div>
<div class="">my next point:</div>
<div class=""><br class="">
</div>
<div class="">2. GIS software does not offer reliable ways to store the observation time of</div>
<div class="">coordinates</div>
<div class=""><br class="">
</div>
<div class="">To me this is the core of the problem in bringing dynamic reference frames into</div>
<div class="">practical use. Dynamic reference frames are inherently spatiotemporal - all</div>
<div class="">coordinates must consist of three spatial components and one temporal,</div>
<div class="">otherwise they simply are of no use. The timestamp of a coordinate has to be</div>
<div class="">the observation time of the coordinate and the timestamp must not be changed</div>
<div class="">during transformations (otherwise you can’t do the reverse transformation). If</div>
<div class="">those two criteria are met you can reliably transform between all reference</div>
<div class="">frames that are based on ITRFxxxx, for example between GDA94, WGS84 and GDA2020</div>
<div class="">as has been mentioned as currently being problematic in that regard.</div>
<div class=""><br class="">
</div>
<div class="">So, if you keep track of time, it’s not all that difficult to work with dynamic</div>
<div class="">reference frames. The problem is that it is impossible in practice since there</div>
<div class="">is no standard that describes how to do this. The OGC Simple Features standard</div>
<div class="">which most file formats are based on simply doesn’t include time as a</div>
<div class="">dimension. At best, we can store X, Y, Z and M, with the M value being a</div>
<div class="">“measure” of some kind. This could in principle be observation times of the</div>
<div class="">coordinate but how would you distinguish between a time measure and some other</div>
<div class="">type of measure (e.g. a velocity)?</div>
<div class=""><br class="">
</div>
<div class="">Cameron, if you want to take this up with the OGC, this is where you should</div>
<div class="">start. Most of what has been mentioned in this thread as problems are actually</div>
<div class="">solved in recent versions of PROJ and GDAL but we need GIS data formats that</div>
<div class="">can handle 4D coordinates before all those nice new features can be used to</div>
<div class="">their full extent. Most important is the Simple Features standard but I can</div>
<div class="">image that some minor tweaks will be needed in ISO19111 as well.</div>
<div class=""><br class="">
</div>
<div class="">/Kristian</div>
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">[0] <a href="http://www.geophysica.fi/pdf/geophysica_2019_54_kierulf.pdf" class="">http://www.geophysica.fi/pdf/geophysica_2019_54_kierulf.pdf</a></div>
<div class="">[1] <a href="ftp://itrf.ensg.ign.fr/pub/itrf/WGS84.TXT" class="">ftp://itrf.ensg.ign.fr/pub/itrf/WGS84.TXT</a> <br class="">
<div><br class="">
</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 25 Jun 2019, at 03:15, Nick Mein <<a href="mailto:nick_mein@trimble.com" class="">nick_mein@trimble.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="gmail_default" style="font-size:small">Hi Evan, Cameron,</div>
<div class="gmail_default" style="font-size:small"><br class="">
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
See <a href="https://docs.opengeospatial.org/as/18-005r4/18-005r4.html#116" rel="noreferrer" target="_blank" class="">https://docs.opengeospatial.org/as/18-005r4/18-005r4.html#116</a>  </blockquote>
<div class="gmail_default" style="font-size:small"><br class="">
</div>
<div class="gmail_default" style="font-size:small">That is a great document. Thanks for sharing!</div>
<div class="gmail_default" style="font-size:small"><br class="">
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
At bottom of page 16 of this guidance note, there is even a quite funny<br class="">
discussion about whether NAD83(2011) should be considered as a static or<br class="">
dynamic CRS</blockquote>
<div class="gmail_default" style="font-size:small"><br class="">
</div>
<div class="gmail_default" style="font-size:small">It really depends on where you are working. Over most of the continental US you can consider NAD83(2011) to be a static reference frame. (I.e. you can consider the velocity of points to be zero.) But that isn't
 true if you are working in California.</div>
<div class="gmail_default" style="font-size:small"><br class="">
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
But those terminology discussions don't solve Cameron's pratical problem which<br class="">
is  that when transforming data that is originally in GDA94 or GDA2020 to<br class="">
WGS84 or WebMercator (using WGS84), the recommended transformations in EPSG,<br class="">
ESRI, etc... are null transformations, causign misalignments when mixing<br class="">
sources from GDA94 and GDA2020.</blockquote>
<div class="gmail_default" style="font-size:small"><br class="">
</div>
<div class="gmail_default" style="font-size:small">Right. But there is a solution to Cameron's practical problem, which is to transform his GDA94 dataset(s) to GDA2020.</div>
<div class="gmail_default" style="font-size:small">In the longer term, we can all (practitioners, geospatial software providers) help clear up misunderstandings by being more precise with our terminology. Including pretending that there is such a thing as a
 precise WGS-84 coordinate, or that GDA, GDA2020, NAD83, etc are equivalent to "WGS-84". </div>
<div class="gmail_default" style="font-size:small"><br class="">
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
Let's define a "global mosaiced static CRS", that is the union / pachwork of<br class="">
the national/regional/continental CRS in current use.</blockquote>
<div class="gmail_default" style="font-size:small"><br class="">
</div>
<div class="gmail_default" style="font-size:small">I'm pretty sure that is what products such as Google Maps must do, though I'd love to get verification from someone that knows for sure.</div>
<div class="gmail_default" style="font-size:small"><br class="">
</div>
<div class="gmail_default" style="font-size:small">A key point is - how do you access whatever reference frame you are using? Traditionally you would do that by locating physical marks on the ground, and looking up their published coordinates. Today, you are
 likely to using a real time GNSS corrections network, or a post-processing service such as OPUS/AUSPOS/etc, or you are going to be using a precise point positioning service. The coordinates that you get are going to be either in a local/regional reference
 frame such as GDA/NAD83/ETRF, or they are going to be ITRF. For (large scale?) web mapping applications, munging together data sets from different reference frames is fine. But ultimately you need to be able to drill down to the original data.</div>
<div class="gmail_default" style="font-size:small"><br class="">
</div>
<div class="gmail_default" style="font-size:small">Regards,</div>
<div class="gmail_default" style="font-size:small">Nick.</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, 25 Jun 2019 at 05:04, Cameron Shorter <<a href="mailto:cameron.shorter@gmail.com" class="">cameron.shorter@gmail.com</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" class="">
<p class="">Thanks Doug, you have pointed me to Matt Higgins who is one of the Australians on this email's CC list. He has contributed toward identifying this problem. I believe we need to bring this conversation into an international forum, probably headed
 up by the OGC.</p>
<p class="">You might be able to suggest who we should connect with? <br class="">
</p>
<p class="">Warm regards, Cameron<br class="">
</p>
<div class="gmail-m_-3177473677198818828moz-cite-prefix">On 24/6/19 11:30 pm, Newcomb, Doug wrote:<br class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" class="">Cameron,
<div class=""> I just emailed  someone working on this .  He sent me the links below.  </div>
<div class=""><br class="">
</div>
<div class="">
<div class="gmail-m_-3177473677198818828gmail-iv gmail-m_-3177473677198818828gmail-gt gmail-m_-3177473677198818828gmail-gE" style="padding:20px 0px 0px;font-size:0.875rem;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif">
<table class="gmail-m_-3177473677198818828gmail-gJ gmail-m_-3177473677198818828gmail-cf" style="border-collapse:collapse;margin-top:0px;width:auto;font-size:0.875rem;letter-spacing:0.2px;display:block" cellpadding="0">
<tbody style="display:block" class="">
</tbody>
</table>
</div>
<div class="gmail-m_-3177473677198818828gmail-" style="font-family: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; font-size: inherit;">
<div id="gmail-m_-3177473677198818828gmail-:41m" class="gmail-m_-3177473677198818828gmail-gt gmail-m_-3177473677198818828gmail-ii gmail-m_-3177473677198818828gmail-adO" style="font-size:0.875rem;direction:ltr;margin:8px 0px 0px;padding:0px">
<div id="gmail-m_-3177473677198818828gmail-:41l" class="gmail-m_-3177473677198818828gmail-a3s gmail-m_-3177473677198818828gmail-aXjCH" style="overflow:hidden;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:small;line-height:1.5;font-family:Arial,Helvetica,sans-serif">
<a href="https://www.gps.gov/governance/advisory/" rel="noreferrer" target="_blank" class="">https://www.gps.gov/governance/advisory/</a><br class="">
<br class="">
<a href="https://www.gps.gov/governance/advisory/members/higgins/" rel="noreferrer" target="_blank" class="">https://www.gps.gov/governance/advisory/members/higgins/</a></div>
<div id="gmail-m_-3177473677198818828gmail-:41l" class="gmail-m_-3177473677198818828gmail-a3s gmail-m_-3177473677198818828gmail-aXjCH" style="overflow:hidden;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:small;line-height:1.5;font-family:Arial,Helvetica,sans-serif">
<br class="">
</div>
<div id="gmail-m_-3177473677198818828gmail-:41l" class="gmail-m_-3177473677198818828gmail-a3s gmail-m_-3177473677198818828gmail-aXjCH" style="overflow:hidden;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:small;line-height:1.5;font-family:Arial,Helvetica,sans-serif">
Doug</div>
</div>
</div>
</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Jun 20, 2019 at 5:15 PM Cameron Shorter <<a href="mailto:cameron.shorter@gmail.com" target="_blank" class="">cameron.shorter@gmail.com</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr" class="">
<div class="">Hi folks,<br class="">
<br class="">
Our Australian spatial data users are about to face a systematic mismatch challenge when trying to use multiple static datums (GDA2020, GDA94) with the dynamic datum (WGS84). At the moment, it is government agencies grappling with the problem, but it is about
 to become a mainstream issue.<br class="">
<br class="">
Australia now has static datums for the years 1994 and 2020 and uses WGS84 (a time-dependent datum!), for web-mapping and web-services.  We recognise:<br class="">
1. Transforming from GDA94 to GDA2020 reflects Australia’s tectonic movement of ~ 1.8 metres to the North East.<br class="">
2. GDA94 was defined as ‘equal to WGS84’ in 1994.<br class="">
3. GDA2020  was defined as ‘equal to WGS84’ in 2020.<br class="">
All three statements can’t be accurate. It results in mis-aligned maps in WGS84<br class="">
<br class="">
I believe this is a problem the whole world needs to address, given the upcoming modernsation of significant national datums including the U.S and we need to bring this topic into an international conversation, ASAP.<br class="">
I'm interested to know if anyone here is looking into and/or has opinions on how it should be solved. I'd like to incorporate your ideas into the recommendations that we are putting foward.<br class="">
<div class="">-- <br class="">
</div>
<div dir="ltr" class="gmail-m_-3177473677198818828gmail-m_-6873679771758165188gmail_signature">
<div dir="ltr" class="">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="">
<div class=""><span style="font-size:12.8px" class="">Cameron Shorter</span><br class="">
</div>
<div class="">Technology Demystifier</div>
<div class="">Open Technologies and Geospatial Consultant</div>
<div class=""><br class="">
</div>
<div class="">M +61 (0) 419 142 254</div>
<div class=""><br class="">
</div>
</div>
<div class=""><br class="">
<br class="">
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br clear="all" class="">
<div class=""><br class="">
</div>
-- <br class="">
<div dir="ltr" class="gmail-m_-3177473677198818828gmail_signature">
<div dir="ltr" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="">
<div class="">Doug Newcomb - Cartographer</div>
<div class="">USFWS</div>
<div class="">551F Pylon Dr</div>
<div class="">Raleigh, NC</div>
<div class="">919-856-4520 ext. 14 <a href="mailto:doug_newcomb@fws.gov" target="_blank" class="">
doug_newcomb@fws.gov</a></div>
<div class="">---------------------------------------------------------------------------------------------------------</div>
<div class=""><br class="">
</div>
</div>
<div class=""><b style="font-size:12.8px" class=""><i class=""><font color="#0000ff" class="">NOTE: This email correspondence and any attachments to and from this sender is subject to the Freedom of Information Act (FOIA) and may be disclosed to third parties.</font></i></b><span class="">​</span><br class="">
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<pre class="gmail-m_-3177473677198818828moz-signature" cols="72">-- 
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254</pre>
</div>
_______________________________________________<br class="">
PROJ mailing list<br class="">
<a href="mailto:PROJ@lists.osgeo.org" target="_blank" class="">PROJ@lists.osgeo.org</a><br class="">
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank" class="">https://lists.osgeo.org/mailman/listinfo/proj</a><br class="">
</blockquote>
</div>
_______________________________________________<br class="">
PROJ mailing list<br class="">
<a href="mailto:PROJ@lists.osgeo.org" class="">PROJ@lists.osgeo.org</a><br class="">
https://lists.osgeo.org/mailman/listinfo/proj<br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>