<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Aptos;
        panose-1:2 11 0 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:12.0pt;
        font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;
        mso-ligatures:none;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks again, Greg.  And thanks for your patience as I try to provide credible responses to some of your questions
</span><span style="font-size:11.0pt;font-family:"Apple Color Emoji"">😊</span><span style="font-size:11.0pt">…<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;color:black;background:white">You really need to ask AWS about AWS configuration, rather than asking</span><span style="font-size:11.0pt;color:black"><br>
<span style="background:white">us to guess.  You are getting all that cloud goodness which must be</span><br>
<span style="background:white">perceived as valuable, and finding out what they are really doing is</span><br>
<span style="background:white">part of the bargain.</span></span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Yep.  This makes sense.  We’ll try to see what information we can get from AWS and share what we find.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">By the way I committed a typo:  The source data is in EPSG:26850 (NAD83 / Minnesota Central (ftUS)), rather than ESPG:26860 NAD83(HARN) / Nebraska (ftUS).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt">Is your data really in NAD83(1986)?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I’m not sure how to answer this one.  I can provide the WKT that I get from ogrinfo, but I’m guessing that the question is more about how accurate we can expect the coordinates to be.  The data represents
 road centerlines and county boundaries.  I believe the vertices are, at best, accurate to within 1-2 meters.  That said, in our SQL example, we’re just transforming one point and looking at the results.  I’m assuming it doesn’t make sense to say in that case
 that the point is in “in NAD83(1986)”, but if I’m wrong about that I’m always keen to learn new things.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt">  Do you really want to transform to an ensemble?<br>
    What do you think that means?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">This is “public safety” data that the analysts maintain in a local projected coordinate system, but everything needs to be converted to lat/lon to be compliant with NENA specifications.  (<a href="https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/nena-sta-006.2-2022_ng9-1-1_.pdf">https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/nena-sta-006.2-2022_ng9-1-1_.pdf</a>).
 This isn’t a justification, of course, but to say that in this case we didn’t make the rules. :D  <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I think this means that the way we’re transforming coordinates, with ST_Transform(…, 4326) we aren’t exactly sure which member of the ensemble is used so aspects of the projection process are subject to variations.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt">Do you understand the dynamic datum issues, and the consequences of<br>
  the lack of epoch tagging?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I believe we’re talking about the fact that the Earth is a dynamic system, the surface shifts,  and that we should expect the relationship between a point on the ground and a lat/lon to change over time.  Unless
 we define times for the observations on the source geometries and the projection, we should expect some drift to occur.  Do I have that right?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Many thanks once again! I believe this has given us some insights.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="color:black">From:
</span></b><span style="color:black">Greg Troxel <gdt@lexort.com><br>
<b>Date: </b>Tuesday, February 18, 2025 at 8:15</span><span style="font-family:"Arial",sans-serif;color:black"> </span><span style="color:black">AM<br>
<b>To: </b>Pat Blair <pblair@geocomm.com><br>
<b>Cc: </b>Paul Ramsey <pramsey@cleverelephant.ca>, postgis-users@lists.osgeo.org <postgis-users@lists.osgeo.org>, Ryan Thomas <rthomas@geocomm.com>, Forest Carter <fcarter@geocomm.com>, Neil Erickson <nerickson@geo-comm.com>, Kellsey Schilly <kschilly@geocomm.com>,
 Colin Kelly <ckelly@geocomm.com>, Devin Escue <descue@geocomm.com><br>
<b>Subject: </b>Re: Different Projection Results in AWS Managed Services<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">ALERT: This message originated outside of GeoComm. Use CAUTION when opening links and attachments.<br>
<br>
proj over time has improvements, and these are usually viewed as<br>
improvements and/or bug fixes.<br>
<br>
For example, 9.2.0 has more NADCON grids:<br>
  <a href="https://github.com/OSGeo/PROJ/releases/tag/9.2.0">https://github.com/OSGeo/PROJ/releases/tag/9.2.0</a><br>
<br>
To understand more, you're going to need to study release notes.<br>
<br>
You really need to ask AWS about AWS configuration, rather than asking<br>
us to guess.  You are getting all that cloud goodness which must be<br>
perceived as valuable, and finding out what they are really doing is<br>
part of the bargain.<br>
<br>
<br>
The larger point is that getting upset about a small change in proj<br>
output while not being at least 10x more upset about differences between<br>
proj and NGS, and not having that being grounded in a thorough<br>
understanding of the geodetic issues, just does not make any sense.<br>
From your responses so far, it sounds like there are still a lot of<br>
open, far more serious issues:<br>
<br>
  Is your data really in NAD83(1986)?<br>
<br>
  Do you really want to transform to an ensemble?<br>
    What do you think that means?<br>
<br>
  Do you understand the dynamic datum issues, and the consequences of<br>
  the lack of epoch tagging?<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>