Mechanism for identifying an elevation dataset

[jyutzler]

How should we indicate whether a tile set contains elevation data as opposed to rasters (or possibly something else in the future)?

1. Create a new allowed value (e.g., "elevation-tiles") for the data-type column of gpkg-contents (see http://www.geopackage.org/spec/#_contents).
2. Leave gpkg-contents alone and add a new column to tile pyramid user data tables (see http://www.geopackage.org/spec/#tiles_user_tables) (e.g., tile-contents). This column may be null (indicating rasters) or it may have a value like "elevation". This would require a corresponding change to the table generation SQL (see http://www.geopackage.org/spec/#_sample_tile_pyramid_informative).

[pepijnve]

I discussed this briefly with Paul Daisey as well during the last call I attended. I think we were the only ones on the call then, so I'll archive what I remember from that discussion here.

I suggested elevation tiles were actually a specific case of quadrilateral grid coverages. It might be worthwhile to generalise from elevation to general quadrilateral grids to allow other types of grid sampled data to be stored in a geopackage as well. The use cases I had in mind at the time were weather data, multi-spectral images, etc. This starts getting into NetCDF territory of course. Maybe it makes things more complicated than necessary...

Even if you stick to just elevation, there also needs to be a standardised way to store metadata about the sample data. Things like unit of measure, measurement accuracy, sensor information, etc. I had proposed to use ISO 19115 in gpkg_metadata for this rather than trying to store all this information in SQL tables since that would lead a huge size increase in the gpkg SQL schema. This makes bits of pretty crucial metadata less easily accessible so it's not clear to me if this is a good idea or not.

[pepijnve]

Just remembered another reason why I had suggested this.

GeoPacakge RGB(A) image tiles are currently modeled to be useable as a local cache for WMTS. Generalising to coverages would allow GeoPackage coverage tiles to be used in the same way for tiled WCS. Not sure what the progress on tiled WCS is, but it might be a good idea to coordinate with what they're doing.

[jyutzler]

@pepijnve While I agree in principle that elevation tiles could be a specific case of any gridded coverage, that is out of scope for the current effort. What I like about elevation data is that you don't need much other than the SRS to use it. Other things like accuracy can be safely pushed into the metadata tables. For other types of multi-spectral data it isn't so easy to define what it is. Until SWG participants start expressing an interest in building this kind of capability, it will wait.

I will take a look at what WCTS is doing but I'm not putting much hope in that proposed standard's relevance. I know of no operational scenario where a client will want to pull individual tiles of elevation data from a server. I've only come up with the following scenarios:

• client hosts the data locally (GeoPackage or otherwise)
• client just wants to do visualization (WMS/WMTS or the 3D equivalent)
• client wants to perform an analysis operation (just put the analytics with the data and execute them via WPS)

Again if someone has a use case and wants to commit to producing an implementation, I'll listen.

[pepijnve]

Use case for pretiled wcs server side is the same as wmts. Reduce server load by serving precanned chunks instead of doing this on the fly for each request. This saves decode, extract and encode/transcode time and allows for much much better http level caching. Use case for tiled requests client side is to simplify paging of chunks of data, better caching etc. Visualisation sometimes has to happen client side. If you want to interactively change styling for instance (modify color mapping tables or functions for instance), WMS is just too slow (or at least I've never seen a fast (sub 16ms response) WMS server).

Pulling data over WCS for visualisation purposes is also sometimes useful if you want the actual sample values client side. This allows you to do readouts of the visualized data interactively which is not possible if the data has already been converted to RGB. You could do this via wms getfeatureinfo of course but that has a free form response so it's hard to make that work in general. Also too slow for interactive response rates.

But that being said, I agree with you that it's a much more exotic use case. I didn’t mean to say that multispectral tiles should be allowed just yet. I was thinking more along the lines of making the framework sufficiently generic to allow future extension, but restrict usage to elevation for the time being. So rather than saying ‘type = elevation' you do 'type = tiles, semantics = elevation’. That’s basically you’re option 2 right :)

Op 23-apr.-2015 om 22:23 heeft Jeff Yutzler <notifications@github.com mailto:notifications@github.com> het volgende geschreven:

@pepijnve https://github.com/pepijnve While I agree in principle that elevation tiles could be a specific case of any gridded coverage, that is out of scope for the current effort. What I like about elevation data is that you don't need much other than the SRS to use it. Other things like accuracy can be safely pushed into the metadata tables. For other types of multi-spectral data it isn't so easy to define what it is. Until SWG participants start expressing an interest in building this kind of capability, it will wait.

I will take a look at what WCTS is doing but I'm not putting much hope in that proposed standard's relevance. I know of no operational scenario where a client will want to pull individual tiles of elevation data from a server. I've only come up with the following scenarios:

client hosts the data locally (GeoPackage or otherwise) client just wants to do visualization (WMS/WMTS or the 3D equivalent) client wants to perform an analysis operation (just put the analytics with the data and execute them via WPS) Again if someone has a use case and wants to commit to producing an implementation, I'll listen.

— Reply to this email directly or view it on GitHub https://github.com/opengeospatial/geopackage/issues/90#issuecomment-95709632.

[jyutzler]

At today's SWG meeting we agreed on a hybrid of the approaches described above. Unfortunately elevation data is a bit too complicated to describe succinctly.

1. Value of 2D-gridded-coverage in the data-type column of gpkg-contents
2. Add additional columns to tile set description tables which key to an ancillary table as described in #93
3. ISO metadata (optional) to provide additional details beyond the structure of the data itself

[jyutzler]

Shall we have a single ancillary table for all elevation data content gpkg_elevation_ancillary? If there are other extensions for some other purpose then they would presumably have their own ancillary tables.

[jyutzler]

5/12 SWG: no objection to this approach. We will know more when we build it.

[jyutzler]

5/12 WCTS SWG: this approach would apply to many other types of coverages as well. Suggest calling the table 'gpkg_2D_gridded_scalar_coverage_ancillary' and the 'data_type' '2D_gridded_scalar_coverage'.