[PROJ] Ellipsoidal height VCRS in WKT/EPSG

[Javier Jimenez Shaw]

Thanks Even and Greg.

My problem is more oriented to *projected* CRS. Now I see that I have not
mentioned this term before.

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?

My problem is locating points from a point cloud initially with GPS
coordinates. It is possible to convert from GPS coordinates in WGS84 - 3D
(EPSG:4979) to any State Plane (projected) + NAVD88. Is it possible also to
convert from WGS84 - 3D to the State Plane without any vertical CRS.

This is contrary to a gravity-based height, where if someone gives you just
the elevation at 2 points, you can for example know from which point
towards which one water would flow.

I need the elevation to note the point in a 3D space, not to show the
gravity-based height. In that case, of course, I need a gravity-based model.

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?

For projected CRS, yes, since there is currently no Projected 3D CRS in EPSG

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.

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).

Thanks
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Tue, 1 Sep 2020 at 15:25, Even Rouault <even.rouault at spatialys.com>
wrote:

> Javier,
>
>
>
> > Does exist any EPSG or WKT for a Vertical CRS that means "ellipsoidal
>
> > height"?
>
>
>
> No, and this is by design. Ellipsoidal height doesn't make sense, from a
> referencing point of view, if the longitude,latitude of the point where you
> measure it is not specified as well, hence the need for a Geographic3D CRS.
> This is contrary to a gravity-based height, where if someone gives you just
> the the elevation at 2 points, you can for example know from which point
> towards which one water would flow.
>
>
>
> See http://docs.opengeospatial.org/is/18-010r7/18-010r7.html
>
> """
>
> 3.1.19 ellipsoidal height
>
>
>
> distance of a point from the reference ellipsoid along the perpendicular
> from the reference ellipsoid to this point, positive if upwards or outside
> of the reference ellipsoid
>
>
>
> Note 1 to entry: Only used as part of a three-dimensional ellipsoidal
> coordinate system or as part of a three-dimensional Cartesian coordinate
> system in a three-dimensional projected coordinate reference system, but
> never on its own.
>
> """
>
>
>
> Very early versions of the EPSG dataset (like 10 years ago or more) add
> codes for vertical CRS with ellipsoidal height, but this was removed in
> later versions. Some remains of that are still found in the GeoTIFF 1.0
> specification that hard-coded such dataset, but they have disappeared
> since, and are no longer allowed in GeoTIFF 1.1. I've seen recently also
> some WKT-1 string for LAS files that were using a ellipsoidal vertical CRS
> as part of a compound CRS, but this is no longer considered as
> geodetic-savy practice.
>
>
>
> > I don't want to "promoteTo3D" the 2D CRS adding the third axis, because
> it
>
> > removes the authority.
>
>
>
> For projected CRS, yes, since there is currently no Projected 3D CRS in
> EPSG
>
> For geographic CRS, to the extent where there's a 3D version of the one
> you promote to 2D registered, promoteTo3D should attach the code of the 3D
> CRS:
>
>
>
>
>
> $ projinfo EPSG:4326 --3d
>
> [....snip ...]
>
> ID["EPSG",4979]]
>
>
>
> 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/0f1537f4/attachment-0001.html>