Different Projection Results in AWS Managed Services

[Greg Troxel]

Pat Blair <pblair at geocomm.com> writes:

Your client is not doing quoting correctly.  I've tried to patch it up
manually.  Please fix that :-)

>> 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.

Your data came from somewhere.  It is maintained by somebody, and
labeled.  You should talk to them and see what they say about where it
came from and the datum issues.  Or maybe they have a metadata page for
the layer and this is explained.  NAD83(1986) has been superceded for
such a long time (by NAD83(HARN) in the late 90s, I think), but one
could I suppose keep using marks with the 1986 coords for survey
control.  My point is that it is likely that this data is mislabeled.
Probably, the dataset contains various flavors of NAD83.  Perhaps it's
all 2011 and it's better than you think.

(Or, you could decide that your whole world has 2m of fuzz and not ask
questions of this list about 12 cm.  But if you are going to question 12
cm is not reasonable to ignore the other sources of error that are >= 12
cm.)

> 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.

I don't follow.  If the layer gives a CRS that has NAD83(1986) as a base
CRS, that's a declaration of how to interpret the coordinates.   You are
asking postgis (and hence proj) to treat it that way.

>>   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

That standard does call for WGS84, which is confused and surprising.
It's also contrary to federal (and almost certainly your state's) policy
which requires using the National Spatial Reference System.  But that
doesn't mean you need to transform to an ensemble.  You could transform
to a recent member, with a recent epoch such as 2025.0.  You should
probably do this, if people care about 12 cm.

And, it means that there is an intrinsic uncertainty of 2m, so it is
unreasonable to worry about 12 cm, when that's the least of your
troubles.  You are likely encounting an error of about 1m (that's the
shift in MA between modern NAD83 and modern WGS84) because proj equates
NAD83 to WGS84, due to the WGS84 ensemble containing WGS84(TRANSIT).

> 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.

It is not so much that you are unsure as that proj is ok with a null
transform if that seems adequate given ensemble fuzz.

>> 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?

Yes.  In a dynamic datum, that is not plate fixed, coordinates should
properly given with not just values, but velocities and a t_0.  Or at
least a t_0 since velocities can be inferred regionally.   In
NAD83(2011) epoch 2010.0, the coordinates of a particular point are
stable, assuming stable ground, which at the several cm level is
reasonable in most places.  Be glad you are not in California :-)