[Geopackage] Handling elevation - alternative to 3D SRS

Even Rouault even.rouault at spatialys.com
Fri Dec 4 05:47:12 EST 2015


Le vendredi 04 décembre 2015 10:54:26, Brad Hards a écrit :
> I think the proposed move to 3D SRS (as proposed at
> https://github.com/opengeospatial/geopackage-elevation/pull/17) is a bad
> idea.
> 
> The concerns stem from pretty poor support for doing any kind of
> reprojection using 3D SRS (e.g. GeoTools can't do that, impacts on
> GeoServer and some Java- based desktop applications, amongst others) and
> the lack of defined EPSG (or other standards body) codes for a 3D
> equivalent for a lot of 2D codes.
> 
> It was suggested that you can just create your own 3D SRS. Sure, but
> implementations will always be patchy in how well they interpret more
> "creative" WKT; and we'd also need to look at srs_auth namespacing and
> likely other unintended consequences. For example, that would break
> SpatiaLite geopackage support - it doesn't read the WKT.
> 
> None of that seems like a good idea for something that aims at mass-market
> adoption.

To give some feedback related to GDAL:
- It has currently no support at all for Geographical 3D SRS (like EPSG:4979).
- It has some support for COMPD_CS though, but this is far from being very well
supported (e.g. this is disabled by default in the geotiff reader as most consumers
wouldn't react properly when being fed with a COMPD_CS).

I agree with Brad that most data you'll get to process will rarely have a proper
Geographical 3D SRS or COMPD_CS attached to it, so you'll have to build a custom WKT.
And as far as I can see, there's no way to have a COMPD_CS made of a PROJCS and
a vertical datum that would be the ellipsoid height of WGS84, since WGS84 isn't registered as a
possible vertical datum for EPSG (an enlightning explanation is provided in 
https://osgeo-org.atlassian.net/browse/GEOT-401?focusedCommentId=13212&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13212)
And my quick digging in the EPSG database shows that there's no predefined projectedCRS based
on EPSG:4979 except the fictitious EPSG::5819  ("EPSG topocentric example A"). So
ellipsoid based elevations are a second class citizen in EPSG.

> 
> Instead, I'd like to discuss other options. I realise that there is a near
> term Interoperability Experiment, and I'd like it to have some chance to
> succeed.
> 
> So to get this started, lets go back to the idea of a 2D SRS plus an
> elevation reference that is not embedded in the WKT. Based on the DIGEST
> approach, I'd like to suggest that we support GEOD and MSL.
> 
> GEOD means "with respect to the ellipsoid" and MSL is mean sea level. You
> can have metres or feet as the unit of measure (1ft == 0.3048m).  Positive
> is always away from the centre of the ellipsoid (so increasing depth is
> more negative).
> 
> If you really need it, you can have "Not specified" where its an arbitrary
> local vertical datum.
> 
> To me, that seems a lot easier to implement in terms of creating data from
> existing sources, and not too difficult to handle on the reader side.
> 
> Brad

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the Geopackage mailing list