[PROJ] Ellipsoidal height VCRS in WKT/EPSG

[Even Rouault]

> I agree with you that the ellipsoidal height should refer to the proper
> geographical CRS. In this case, the "base one" for the projected CRS in the
> compound CRS. Something similar applies to other compound CRS combinations,
> where the geographical CRS reference should match the projected and the
> vertical, right?

Sorry, didn't get that.

> I would like to store those points in the projected CRS in a LAS file.
> If I just define the projected CRS (without vertical component) in the LAS,
> what should I expect to be the Z values?

I'm not sure. Something to check with people more LAS savy than me. I'd say that if there's 
no explicit vertical specification, Z values should be pretty undetermined... unless there are 
conventions in LAS about that.

> Having Projected 3D CRS in EPSG would be a solution... is there any plan
> for that? There were more than 7000 projected CRSs in EPSG. I hardly
> imagine that they duplicate that number.

I know they were considering what to do regarding that, but yes, they made likely the same 
observation that this would be overwhelming. I'm not aware of a short-term resolution for 
this, but you may check with IOGP.

> Related to this topic (I guess), if I run this "experiment",
> echo 40 -90     0 | cs2cs EPSG:4979 EPSG:8734 -f "%.6f" ==> 2343275.132900
> 1213912.862240 107.186796
> echo 40 -90 10000 | cs2cs EPSG:4979 EPSG:8734 -f "%.6f" ==> 2343275.132900
> 1213912.862240 32915.520130
> (EPSG:8734 = NAD83 / Illinois West (ftUS) + NAVD88 height (ftUS)
> <https://beta.epsg.org/crs_8734/NAD83-Illinois-West-ftUS-NAVD88-height-ftUS.
> html?sessionkey=23506x2d03> )

> I see there is no change in the x and y coordinates due to the change in z.
> If the altitude is not changing the horizontal projection, can I assume
> that the ellipsoidal height in EPSG:4979 is perpendicular to the projected
> CRS? (I know it is very unlikely).

PROJ synthesises the following pipeline for this transformation:

+proj=pipeline
	+step +proj=axisswap +order=2,1
	+step +proj=unitconvert +xy_in=deg +xy_out=rad
	+step +inv +proj=vgridshift +grids=us_noaa_geoid09_conus.tif +multiplier=1
	+step +proj=unitconvert +z_in=m +z_out=us-ft
   +step +inv +proj=hgridshift +grids=us_noaa_ilhpgn.tif
   +step +proj=tmerc +lat_0=36.6666666666667 +lon_0=-90.1666666666667
  	      +k=0.999941177 +x_0=699999.99998984 +y_0=0 +ellps=GRS80
   +step +proj=unitconvert +xy_in=m +xy_out=us-ft

So you can see that the vertical operations and horizontal ones are done independantly. 
Sometimes ago I raised on this ML the topic of using deflections of the vertical that 
accompanies some geoids, but this isn't implemented in PROJ and I'm not clear if that would 
be appropriate to use here. Basically what PROJ does follows EPSG guidelines for 
transformations, and they don't use that. So it is currently assumed that the normal to the 
ellipsoidal surface is the same as the vertical in NAVD88.

Side note: from past discussions with R. Lott, I understand that an issue with defining 
Projected 3D CRS was that the definition of the vertical direction for a Projected 3D CRS 
wasn't completely clear: should that be the one of the underlying Geographic 3D CRS, or 
something related to the projection surface that the projection method projects onto... PROJ 
more or less assumes this is the one of the underlying Geographic 3D CRS.
For a Compound CRS, there is no ambiguity: this is the one of the Vertical CRS

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20200901/1666e1b8/attachment.html>