<div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 28, 2020 at 12:47 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sean,<br>
<br>
> I want to confirm if this change is intentional. <br>
<br>
Not really, but the previous behaviour wasn't fully intentional either.<br>
<br>
> I'm guessing that it is and that promoting 2D to 3D is not a simple problem.<br>
<br>
Any choice you make, using the same unit as the horizontal component or metre <br>
is somewhat arbitrary...<br>
<br>
> Nevertheless does<br>
> anyone have a workaround that infers the expected vertical units from the<br>
> 2D CRS most of the time?<br>
<br>
If you use PROJ C API, you can use proj_cs_get_axis_info() + <br>
proj_crs_promote_to_3D() + proj_crs_alter_cs_linear_unit() (in <br>
proj_experimental.h)<br>
<br>
If you want to integrate this with GDAL, you'll have to use an export / import <br>
from/to WKT.<br>
<br>
As you mention EPSG:2263, which relies on NAD83(86), I think I've read in some <br>
NOAA documentation that NAD83(86) is not well defined for ellipsoidal heights. <br>
At least, there is only a EPSG code for the NAD83 Geographic 2D CRS, but not <br>
for a corresponding Geographic 3D CRS. PROJ cannot find any non-ballpark <br>
transformation between NAD83 and WGS84 regarding the Z component, so the <br>
accuracy you'll get on it is likely to be greater than 1 metre<br>
<br>
Even<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</blockquote></div>