Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
alexamici opened this issue Jun 13, 2016 · 10 comments
Closed

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

alexamici opened this issue Jun 13, 2016 · 10 comments
Milestone

Comments

@alexamici
Copy link

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:

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
Copy link
Contributor

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
Copy link
Author

@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
Copy link
Member

rouault commented Feb 28, 2017

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
Copy link
Member

kbevers commented Feb 28, 2017

@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
Copy link
Member

rouault commented Feb 28, 2017

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
Copy link
Member

kbevers commented Feb 28, 2017

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
Copy link
Member

kbevers commented Oct 28, 2018

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

@rouault
Copy link
Member

rouault commented Oct 28, 2018

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
Copy link
Member

kbevers commented Oct 29, 2018

yes.

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

@abhijitgujar86
Copy link

EPSG:4979 will play an important part in future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants