[postgis-users] ST_Transform Z heights between ODN and WSG
Greg Troxel
gdt at lexort.com
Wed Feb 1 17:33:58 PST 2023
Paul Ramsey <pramsey at cleverelephant.ca> writes:
> The problem *is* in fact at the proj level... you cannot do
> grid-shifted adjustments (like horiztonal and vertical datum shifts)
> if you do not have the grid shift files available. You cannot have the
> grid shift files available (in modern proj) without allowing network
> access to the grid CDN. To have access to the CDN you have to flip the
> PROJ_NETWORK environment to ON, so this:
As I understand it, this is not quite true. Mostly it is as you say,
but:
1) It is possible to obtain and store the shift files yourself, rather
than letting proj do network operations. See projsync(1).
2) Some transforms are in proj (helmert) and do not use grid files.
An example is 'NAD83(2011) epoch 2010.0' to 'ITRF2014'. But grids
are needed for many horizontal transforms (especially older
datums) and (all?) ellipsoidal to orthometric transforms.
In pkgsrc we have a proj-data package, which (slightly out of date)
clocks in at 587 MB. Installing that is equivalent to downloading the
entire CDN as of its release.
The OP may find this illuminating:
projinfo -s 'EPSG:7405' -t 'EPSG:4979'
which shows the pipelines proj considers. The projinfo man page has
some discussion of network vs not and present vs missing grid files.
Also, 4979 is "WGS84", which is an ensemble, and there exist
low-accuracy members of that ensemble (specifically, WGS84(TRANSIT) or
some other name for the original version). There are two problems
arising:
proj doesn't deal well with ensembles, as it can decide that a null
transform is ok from NAD83 to WGS84 because (more or less) each has a
particular member and those members are equivalent. However, the
modern versions of NAD83 and WGS84 are both high-quality datums and
are decidedly not equivalent.
Data being in an ensemble means that it is in a CRS that is a member
of the ensemble and you don't know which one. That's a bad siutation
and it's best to go back and see if better labeling is possible.
Transforming *to* an ensemble doesn't really make sense. Instead,
choose a member, or an equivalent datum, and transform to that. If
you have to relabel it WGS84 because someone (who doesn't understand
why transforming to ensembles is problematic) insists you give them
WGS84, then transform the real datum to WGS84 -- which will be a null
transform. Good choices are WGS84(G2139) and ITRF2014.
Also, when using ITRF-family frames, it may become necessary to think
about epoch if you care about centimeters.
More information about the postgis-users
mailing list