<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Pat,<div><br></div><div>Thanks for going through this in public, and I’d like to ask those watching:</div><div><br></div><div>“Can you provide some links to discussions of modern datums, ensembles, and the importance of maintenance of metadata around epoch of collection.”</div><div><br></div><div>I have read some very good ones over the years, but I cannot remember WHERE!</div><div><br></div><div>Anyways, WRT your proximate problem, I’d warn that even if you managed to find out a difference in configuration and trim away your 0.12 margin somehow, the fact that you are running your data through a pretty complex floating point transformation (coordinate reprojection) means that it is entirely possible you’ll still find small differences between your coordinates. I once found one that cropped up between x86_64 and ARM64, due to one of the architectures supporting a “merged add/multiply” operation, while the other did not (do not ask me which). </div><div><br></div><div>Basically, at a much higher level, if you’re going to be doing exact coordinate comparisons, it makes sense to define an expected minimum precision and enforce it, with something like <a href="https://postgis.net/docs/ST_ReducePrecision.html">https://postgis.net/docs/ST_ReducePrecision.html</a> </div><div><br></div><div>On your 0.12 directly, all evidence to me suggests that AWS has a different set of grid transforms on the two products, and one is being more clever than the other in applying an extra shift between spheroids. That is, one result is “better” or at least applying more magic to the process (but not, as Greg notes, actually better, since the input basis is unknown, and the transform is probably not rated to that precision anyways).</div><div><br></div><div>ATB,</div><div><br></div><div>P<br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Feb 18, 2025, at 8:49 AM, Pat Blair <pblair@geocomm.com> wrote:</div><br class="Apple-interchange-newline"><div><meta charset="UTF-8"><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: HelveticaNeue; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;">Thanks again, Greg. And thanks for your patience as I try to provide credible responses to some of your questions<span class="Apple-converted-space"> </span></span><span style="font-size: 11pt; font-family: "Apple Color Emoji";">😊</span><span style="font-size: 11pt;">…<o:p></o:p></span></div><div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div><div style="margin: 0in 0in 0in 0.5in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt; background: white;">You really need to ask AWS about AWS configuration, rather than asking</span><span style="font-size: 11pt;"><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: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;">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></div><div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;">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></div><div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div><div style="margin: 0in 0in 0in 0.5in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;">Is your data really in NAD83(1986)?<o:p></o:p></span></div><div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;">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></div><div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div><div style="margin: 0in 0in 0in 0.5in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;"> Do you really want to transform to an ensemble?<br> What do you think that means?<o:p></o:p></span></div><div style="margin: 0in 0in 0in 0.5in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;">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" style="color: blue; text-decoration: underline;">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></div><div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;">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></div><div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div><div style="margin: 0in 0in 0in 0.5in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;">Do you understand the dynamic datum issues, and the consequences of<br> the lack of epoch tagging?<o:p></o:p></span></div><div style="margin: 0in 0in 0in 0.5in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;">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></div><div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;">Many thanks once again! I believe this has given us some insights.<o:p></o:p></span></div><div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></span></div><div id="mail-editor-reference-message-container"><div><div><div style="border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) currentcolor currentcolor; border-image: none; padding: 3pt 0in 0in;"><p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 12pt; font-family: Aptos, sans-serif;"><b><span style="">From:<span class="Apple-converted-space"> </span></span></b><span style="">Greg Troxel <<a href="mailto:gdt@lexort.com" style="color: blue; text-decoration: underline;">gdt@lexort.com</a>><br><b>Date:<span class="Apple-converted-space"> </span></b>Tuesday, February 18, 2025 at 8:15</span><span style="font-family: Arial, sans-serif;"> </span><span style="">AM<br><b>To:<span class="Apple-converted-space"> </span></b>Pat Blair <<a href="mailto:pblair@geocomm.com" style="color: blue; text-decoration: underline;">pblair@geocomm.com</a>><br><b>Cc:<span class="Apple-converted-space"> </span></b>Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca" style="color: blue; text-decoration: underline;">pramsey@cleverelephant.ca</a>>,<span class="Apple-converted-space"> </span><a href="mailto:postgis-users@lists.osgeo.org" style="color: blue; text-decoration: underline;">postgis-users@lists.osgeo.org</a><<a href="mailto:postgis-users@lists.osgeo.org" style="color: blue; text-decoration: underline;">postgis-users@lists.osgeo.org</a>>, Ryan Thomas <<a href="mailto:rthomas@geocomm.com" style="color: blue; text-decoration: underline;">rthomas@geocomm.com</a>>, Forest Carter <<a href="mailto:fcarter@geocomm.com" style="color: blue; text-decoration: underline;">fcarter@geocomm.com</a>>, Neil Erickson <<a href="mailto:nerickson@geo-comm.com" style="color: blue; text-decoration: underline;">nerickson@geo-comm.com</a>>, Kellsey Schilly <<a href="mailto:kschilly@geocomm.com" style="color: blue; text-decoration: underline;">kschilly@geocomm.com</a>>, Colin Kelly <<a href="mailto:ckelly@geocomm.com" style="color: blue; text-decoration: underline;">ckelly@geocomm.com</a>>, Devin Escue <<a href="mailto:descue@geocomm.com" style="color: blue; text-decoration: underline;">descue@geocomm.com</a>><br><b>Subject:<span class="Apple-converted-space"> </span></b>Re: Different Projection Results in AWS Managed Services<o:p></o:p></span></p></div><div><div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;">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> <span class="Apple-converted-space"> </span><a href="https://github.com/OSGeo/PROJ/releases/tag/9.2.0" style="color: blue; text-decoration: underline;">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?</span></div></div></div></div></div></div></div></blockquote></div><br></div></body></html>