<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Evan, Cameron,</div><div class="gmail_default" style="font-size:small"><br></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">https://docs.opengeospatial.org/as/18-005r4/18-005r4.html#116</a> </blockquote><div class="gmail_default" style="font-size:small"><br></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></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> discussion about whether NAD83(2011) should be considered as a static or<br> dynamic CRS</blockquote><div class="gmail_default" style="font-size:small"><br></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></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> is that when transforming data that is originally in GDA94 or GDA2020 to<br> WGS84 or WebMercator (using WGS84), the recommended transformations in EPSG,<br> ESRI, etc... are null transformations, causign misalignments when mixing<br> sources from GDA94 and GDA2020.</blockquote><div class="gmail_default" style="font-size:small"><br></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></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> the national/regional/continental CRS in current use.</blockquote><div class="gmail_default" style="font-size:small"><br></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></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></div><div class="gmail_default" style="font-size:small">Regards,</div><div class="gmail_default" style="font-size:small">Nick.</div></div><br><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">cameron.shorter@gmail.com</a>> wrote:<br></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">
<p>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>You might be able to suggest who we should connect with? <br>
</p>
<p>Warm regards, Cameron<br>
</p>
<div class="gmail-m_-3177473677198818828moz-cite-prefix">On 24/6/19 11:30 pm, Newcomb, Doug
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Cameron,
<div> I just emailed someone working on this . He sent me the
links below. </div>
<div><br>
</div>
<div>
<div class="gmail-m_-3177473677198818828gmail-gE gmail-m_-3177473677198818828gmail-iv gmail-m_-3177473677198818828gmail-gt" style="padding:20px 0px 0px;font-size:0.875rem;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif">
<table class="gmail-m_-3177473677198818828gmail-cf gmail-m_-3177473677198818828gmail-gJ" 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">
</tbody>
</table>
</div>
<div class="gmail-m_-3177473677198818828gmail-" style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:medium">
<div id="gmail-m_-3177473677198818828gmail-:41m" class="gmail-m_-3177473677198818828gmail-ii gmail-m_-3177473677198818828gmail-gt 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">https://www.gps.gov/governance/advisory/</a><br>
<br>
<a href="https://www.gps.gov/governance/advisory/members/higgins/" rel="noreferrer" target="_blank">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>
</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>
<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">cameron.shorter@gmail.com</a>>
wrote:<br>
</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">
<div>Hi folks,<br>
<br>
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>
<br>
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>
1. Transforming from GDA94 to GDA2020 reflects Australia’s
tectonic movement of ~ 1.8 metres to the North East.<br>
2. GDA94 was defined as ‘equal to WGS84’ in 1994.<br>
3. GDA2020 was defined as ‘equal to WGS84’ in 2020.<br>
All three statements can’t be accurate. It results in
mis-aligned maps in WGS84<br>
<br>
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>
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>
<div>-- <br>
</div>
<div dir="ltr" class="gmail-m_-3177473677198818828gmail-m_-6873679771758165188gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>
<div><span style="font-size:12.8px">Cameron
Shorter</span><br>
</div>
<div>Technology Demystifier</div>
<div>Open Technologies and Geospatial
Consultant</div>
<div><br>
</div>
<div>M +61 (0) 419 142 254</div>
<div><br>
</div>
</div>
<div><br>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr" class="gmail-m_-3177473677198818828gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div>
<div>Doug Newcomb - Cartographer</div>
<div>USFWS</div>
<div>551F Pylon Dr</div>
<div>Raleigh, NC</div>
<div>919-856-4520 ext. 14 <a href="mailto:doug_newcomb@fws.gov" target="_blank">doug_newcomb@fws.gov</a></div>
<div>---------------------------------------------------------------------------------------------------------</div>
<div><br>
</div>
</div>
<div><b style="font-size:12.8px"><i><font color="#0000ff">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></span><br>
</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>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div>