[Geopackage] Handling elevation - alternative to 3D SRS
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
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
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
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.
More information about the Geopackage