Pat, Thanks for going through this in public, and I’d like to ask those watching:
“Can you provide some links to discussions of modern datums, ensembles, and the importance of maintenance of metadata around epoch of collection.” I have read some very good ones over the years, but I cannot remember WHERE! 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). 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 https://postgis.net/docs/ST_ReducePrecision.html 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). ATB, P > On Feb 18, 2025, at 8:49 AM, Pat Blair <pbl...@geocomm.com> wrote: > > Thanks again, Greg. And thanks for your patience as I try to provide > credible responses to some of your questions 😊… > > You really need to ask AWS about AWS configuration, rather than asking > us to guess. You are getting all that cloud goodness which must be > perceived as valuable, and finding out what they are really doing is > part of the bargain. > > Yep. This makes sense. We’ll try to see what information we can get from > AWS and share what we find. > > 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). > > Is your data really in NAD83(1986)? > > 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. > > Do you really want to transform to an ensemble? > What do you think that means? > > 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. > (https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/nena-sta-006.2-2022_ng9-1-1_.pdf). > This isn’t a justification, of course, but to say that in this case we > didn’t make the rules. :D > > 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. > > Do you understand the dynamic datum issues, and the consequences of > the lack of epoch tagging? > > 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? > > Many thanks once again! I believe this has given us some insights. > > > From: Greg Troxel <g...@lexort.com <mailto:g...@lexort.com>> > Date: Tuesday, February 18, 2025 at 8:15 AM > To: Pat Blair <pbl...@geocomm.com <mailto:pbl...@geocomm.com>> > Cc: Paul Ramsey <pram...@cleverelephant.ca > <mailto:pram...@cleverelephant.ca>>, postgis-users@lists.osgeo.org > <mailto:postgis-users@lists.osgeo.org><postgis-users@lists.osgeo.org > <mailto:postgis-users@lists.osgeo.org>>, Ryan Thomas <rtho...@geocomm.com > <mailto:rtho...@geocomm.com>>, Forest Carter <fcar...@geocomm.com > <mailto:fcar...@geocomm.com>>, Neil Erickson <nerick...@geo-comm.com > <mailto:nerick...@geo-comm.com>>, Kellsey Schilly <kschi...@geocomm.com > <mailto:kschi...@geocomm.com>>, Colin Kelly <cke...@geocomm.com > <mailto:cke...@geocomm.com>>, Devin Escue <des...@geocomm.com > <mailto:des...@geocomm.com>> > Subject: Re: Different Projection Results in AWS Managed Services > > ALERT: This message originated outside of GeoComm. Use CAUTION when opening > links and attachments. > > proj over time has improvements, and these are usually viewed as > improvements and/or bug fixes. > > For example, 9.2.0 has more NADCON grids: > https://github.com/OSGeo/PROJ/releases/tag/9.2.0 > > To understand more, you're going to need to study release notes. > > You really need to ask AWS about AWS configuration, rather than asking > us to guess. You are getting all that cloud goodness which must be > perceived as valuable, and finding out what they are really doing is > part of the bargain. > > > The larger point is that getting upset about a small change in proj > output while not being at least 10x more upset about differences between > proj and NGS, and not having that being grounded in a thorough > understanding of the geodetic issues, just does not make any sense. > From your responses so far, it sounds like there are still a lot of > open, far more serious issues: > > Is your data really in NAD83(1986)? > > Do you really want to transform to an ensemble? > What do you think that means? > > Do you understand the dynamic datum issues, and the consequences of > the lack of epoch tagging?
