[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