Please add support for EPSG:4979, 3D version of EPSG:4326

[alexamici]

On Mac OS X, PROJ.4 version 4.9.2, EPSG:4979 is not a valid CRS identifier:

$ cs2cs +init=EPSG:4979
Using from definition: init=EPSG:4979 
Rel. 4.9.2, 08 September 2015
<cs2cs>: 
projection initialization failure
cause: no options found in 'init' file
program abnormally terminated

EPSG:4979 is cited in various RFC as the proper identifier of the 3D Geodetic WGS84, when using ellipsoid height on top of EPSG:4326, so I'd like to use the proper identifier in code handling ellipsoid heights.

For example:

• https://tools.ietf.org/html/rfc5870
• https://tools.ietf.org/html/rfc6225

This is full the definition on the EPSG registry:
http://www.epsg-registry.org/report.htm?type=selection&entity=urn:ogc:def:crs:EPSG::4979&reportDetail=long&title=WGS%2084&style=urn:uuid:report-style:default-with-code&style_name=OGP%20Default%20With%20Code

As a workaround I'm using the 2D definition "EPSG:4326" that appears to produce ellipsoid heights, but I'm not sure how stable this is.

[micahcochran]

I also noticed the lack of EPSG:4979 when I was translating GIGS tests 5201 and 5212. I also used the same EPSG:4236 workaround.

I'm not too sure I understand why the "stability" of height such is such a problem with the "geo: URI".

However with dynamically assigning an IP address based on what floor a device is on, I can understand why height stability could be an issue. There is a huge difference between the first floor and the 50 floor of a building. Smartphone and table GPS give only somewhat accurate points (atleast in the US, the EU may have a better situation).

I'm not quite sure how those applications related to the coordinates. If everything is already in the same coordinate system, you don't need PROJ.4. Unless you want to put it on a web map or cartographic map.

Transformation pipelines PR #388 are being experimented with and in the future may provide for 3d transformations.

[alexamici]

@micahcochran yes I'd like use the EPSG:4979 id to do coordinate transformation to other generic CRS, my concern about using the EPSG:4326 work-around is that I'm not sure it define height values to be ellipsoidal ones in every case.

My limited understanding of how PROJ.4 works is that since EPSG:4326 doesn't specify a vertical datum when transforming to a 3D CRS that has a defined vertical datum different from ellipsoid height PROJ.4 assumes input heights are in the same datum as the output.

[rouault]

Note: I started working on this in libgeotiff and GDAL, but stopped since I realized that the WKT v1 standard doesn't allow 3D GEOGCS. See https://trac.osgeo.org/gdal/ticket/6827

[kbevers]

@rouault Sort of unrelated, so please forgive me, but are there any plans for WKT v2 SRS descriptions in GDAL? Lately I've been involved in some work related to dynamic reference frames, and some of the features in WKT2 is key for success. WKT2 has support for temporal coordinates and datums, which is necesary once you allow your reference frame to move about.

[rouault]

any plans for WKT v2 SRS descriptions in GDAL

This is something I've in top of my mind (there's a GeoPackage extension wit WKT v2 SRS e.g.), but nothing concrete has popped up yet. Making it work together will all the vector&raster drivers that are bound to WKT v1 currently will be a challenge. One major drawback of WKT v2 though is that the convenient TOWGS84 is not there.

[kbevers]

One major drawback of WKT v2 though is that the convenient TOWGS84 is not there.

Yes, that's a bit difficult to work around. On the other hand TOWGS84 is not the ideal way to solve this, so moving away from that is good in my opinion. And with the new transformation pipeline features in PROJ.4 it can be done. Eventually.

Anyway, that was a bit off topic. Back to the issue at hand.

[kbevers]

@rouault This can be closed once the iso19111 branch is merged, yes?

[rouault]

This can be closed once the iso19111 branch is merged, yes?

yes.

$ PROJ_LIB=data src/projinfo EPSG:4979
PROJ string: 
+proj=pipeline +step +proj=longlat +ellps=WGS84 +step +proj=unitconvert +xy_in=rad +z_in=m +xy_out=deg +z_out=m +step +proj=axisswap +order=2,1

WKT2_2015 string: 
GEODCRS["WGS 84",
    DATUM["World Geodetic System 1984",
        ELLIPSOID["WGS 84",6378137,298.257223563,
            LENGTHUNIT["metre",1]]],
    PRIMEM["Greenwich",0,
        ANGLEUNIT["degree",0.0174532925199433]],
    CS[ellipsoidal,3],
        AXIS["geodetic latitude (Lat)",north,
            ORDER[1],
            ANGLEUNIT["degree",0.0174532925199433]],
        AXIS["geodetic longitude (Lon)",east,
            ORDER[2],
            ANGLEUNIT["degree",0.0174532925199433]],
        AXIS["ellipsoidal height (h)",up,
            ORDER[3],
            LENGTHUNIT["metre",1]],
    AREA["World (by country)"],
    BBOX[-90,-180,90,180],
    ID["EPSG",4979]]

[kbevers]

yes.

Awesome. I've edited your iso19111 PR so that it closes this when merged.

[abhijitgujar86]

EPSG:4979 will play an important part in future.