[PROJ] Best practices for converting 2D CRS to 3D CRS

[Sean Lilley]

Thanks Even. It's good to hear the unit selection is arbitrary instead of
plain out wrong. I noticed cs2cs was doing the legacy behavior too.

On Fri, Feb 28, 2020 at 12:47 PM Even Rouault <even.rouault at spatialys.com>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20200302/560ce193/attachment.html>