[Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height

Pepijn Van Eeckhoudt pepijn at vaneeckhoudt.net
Fri Jun 5 11:22:41 EDT 2015

> On 05 Jun 2015, at 16:19, Cochran, Jenifer <jenifer.cochran at rgi-corp.com> wrote:
> The bounds [0,180][-85.0511287798066,0] is the MBR in the gpkg_tile_matrix_set.  That tile is the top-left corner in WMTS terms, which is numbered (0,0). Let me extend the example further.  When you zoom in to level 2, then the numbering would continue from the same bounds of the data. The next level matrix_width and matrix_height would be 2 by 2 with numbered as follows:
> [0,0] [1,0]
> [0,1] [1,1]
> The bounds of these four tiles at zoom level 2 would be the MBR [0,180][-85.0511287798066,0].

Ok, that’s the other direction from my example. Suppose you were to omit tiles (0,0), (1,0) and (1,1) at level 2 from this example. The remaining tile would still be indexed (1,0) (this is the same as what Even was saying I think). So I think we’re all saying the same thing. :)

Again this has me wondering if there’s actually a problem in the first place. If I understand you correctly, your application currently assumes that there will be no empty border of tiles around the set of tiles that’s actually present in order to snap to the data. If an empty border is present, then the snapping won’t be as precise as you would like. I wouldn’t call this 'not working'; it’s just sub optimal.
In the case described above with only one tile at level 2, you would snap to a quarter of the world, even though the detailed data is only present somewhere around Australia. Again not perfect, but things still work.
For what it’s worth I think I implemented pretty much the same logic in the Luciad GeoPackage viewer app. IIRC it zooms to the extent from gpkg_contents (if present) and falls back to the extent from gpkg_tile_matrix_set.

I just reread the tiles requirements and test cases and there’s nothing in there that actually requires a tight fitting extent. The two paragraphs near the end of and the beginning of should probably be reworded though. I seem to remember a discussion during one of the SWG meetings about this bit of text. I might even have made the proposal for these paragraphs myself :) I don’t have access to those pages or the SWG mailing list archives anymore so I can’t dig this up for you I’m afraid.
Anyway, what I’m trying to say is that I’m pretty sure the intention was never to require this to be an MBR for the actually present content in a user data table. We discussed use cases like subsetting existing datasets and preparing empty geopackages with only the metadata populated that would get filled by some other application. The MBR requirement would have precluded both those use cases.

So in conclusion I still think that
Readers should not assume there is a direct relationship between the extent in gpkg_tile_matrix_set and tile presence in the data table.
An area of interest hint may be present in gpkg_contents, but again readers should not assume this is 100% accurate or that the field is populated
The only 100% accurate way to determine which data is present is to query that information from the database. I.e., run
SELECT min(tile_row),max(tile_row),min(tile_column),max(tile_column) from <user_data_table> group by zoom_level

Best regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geopackage/attachments/20150605/00fe2bf0/attachment.html>

More information about the Geopackage mailing list