[Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height
Pepijn Van Eeckhoudt
pepijn at vaneeckhoudt.net
Thu Jun 4 03:21:32 EDT 2015
> My conversation with Joan Masó has confirmed what I and a few others on this thread have said. The matrix_width and matrix_height elements in Table 9 of 188.8.131.52.1 describe the size of the tile matrix. It seems to be there for convenience purposes but I wonder whether it is actually useful. Since it is anchored to the top left, it can't reasonably describe an MBR. (As an aside, the reference to MBR in 2.2.6 is wrong  - a similar mistake was made in WMTS.)
It’s not just there for convenience. When you want to determine the set of potentially visible tiles given a spatial extent you need these values. Well actually, you need either matrix_width/height or pixel_x/y_size. I personally find the top down ‘divide tile matrix set dimensions in an integer number of parts’ more intuitive, but the results will be the same.
> We could have a way to describe the tiles that are present in a particular tile matrix but this capability is completely missing in GPKG today (short of doing an SQL query and counting). We are currently analyzing potential approaches. WMTS has TileSetLimits (Table 12 in 07-057r7) but they didn't get it right either - you can use it as an MBR but you can't have a set of them to describe a sparse tile set. The WMS SWG has agreed to look into this.
Paul Daisey, Roger Brackin and I (and perhaps you were involved as well) did some work related to this in the context of using OWS Context and GeoPackage together. Paul (or you) came up with an XML schema to describe ‘scanlines’ of tiles. Never tested in practice though, so I have my doubts how useful that would be in practice. For large tile sets this can end up being a pretty large chunk of XML.
I think the min/max SQL queries are fine. Perhaps some performance tests should be done on real world datasets to see how fast this query can be performed on a typical mobile device and desktop (will depend on presence or absence of indices on tile_row and tile_column of course).
If this query is fast enough in practice for real world data, then it’s probably not worth it to materialise that information in a table. This kind of materialised metadata has a tendency to get out-of-sync with the real data.
Making indices on tile_row/tile_column could also be made a best practice if that turns out to be necessary to make the query fast enough.
More information about the Geopackage