Re: Different Projection Results in AWS Managed Services

Pat Blair <[email protected]> Tue, 18 Feb 2025 16:49:13 +0000
Newsgroups gmane.comp.gis.postgis
Message-ID <CO1PR17MB532237F6631EF65FF378F0A4D0FA2@CO1PR17MB5322.namprd17.prod.outlook.com>
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 <[email protected]>
Date: Tuesday, February 18, 2025 at 8:15 AM
To: Pat Blair <[email protected]>
Cc: Paul Ramsey <[email protected]>, [email protected] <[email protected]>, Ryan Thomas <[email protected]>, Forest Carter <[email protected]>, Neil Erickson <[email protected]>, Kellsey Schilly <[email protected]>, Colin Kelly <[email protected]>, Devin Escue <[email protected]>
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?