[Geopackage] Handling elevation - alternative to 3D SRS

Brad Hards bradh at frogmouth.net
Fri Dec 4 04:54:26 EST 2015


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.

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





More information about the Geopackage mailing list