[PROJ] Best practices for converting 2D CRS to 3D CRS
Even Rouault
even.rouault at spatialys.com
Fri Feb 28 09:47:27 PST 2020
Sean,
> I want to confirm if this change is intentional.
Not really, but the previous behaviour wasn't fully intentional either.
> I'm guessing that it is and that promoting 2D to 3D is not a simple problem.
Any choice you make, using the same unit as the horizontal component or metre
is somewhat arbitrary...
> Nevertheless does
> anyone have a workaround that infers the expected vertical units from the
> 2D CRS most of the time?
If you use PROJ C API, you can use proj_cs_get_axis_info() +
proj_crs_promote_to_3D() + proj_crs_alter_cs_linear_unit() (in
proj_experimental.h)
If you want to integrate this with GDAL, you'll have to use an export / import
from/to WKT.
As you mention EPSG:2263, which relies on NAD83(86), I think I've read in some
NOAA documentation that NAD83(86) is not well defined for ellipsoidal heights.
At least, there is only a EPSG code for the NAD83 Geographic 2D CRS, but not
for a corresponding Geographic 3D CRS. PROJ cannot find any non-ballpark
transformation between NAD83 and WGS84 regarding the Z component, so the
accuracy you'll get on it is likely to be greater than 1 metre
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
More information about the PROJ
mailing list