[Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height

Pepijn Van Eeckhoudt pepijn at vaneeckhoudt.net
Mon Jun 1 04:52:48 EDT 2015

Hi Even,

> > The
> > fundamental difference is that the bounding box should describe only the
> > data contained in the pyramid user data table rather than the bounds of
> > the world.  The bounding box should only be the entire world if the data
> > in the pyramid user data table contains data for the entire world.
> > 
> > GeoPackages must always report the minimum bounds of the data in the
> > pyramid user data table.  As stated  "The gpkg_tile_matrix_set table or
> > updateable view defines the minimum bounding box (min_x, min_y, max_x,
> > max_y) and spatial reference system (srs_id) for all content in a tile
> > pyramid user data table" (below Table 8 Tile Matrix Set Table or View
> > Definition).
> Hum, indeed the "minimum" in "minimum bounding box" would confirm your interpretation. So the question is : is the word "minimum" really intended or is it an error of the spec ?
> Or perhaps there's a missing "potential" word in "for all content" --> "for all (potential) content", potential meaning here addressable within the limits defined by matrix_width and matrix_height.
> My understanding of the following paragraph " <> Table Data Values" was that only min_x and max_y in gpkg_tile_matrix_set were really significant and essential to compute the extent of each tile, so I don't see any technical reason for them to be strictly adjusted to the tiles that are present.
> """
> The minimum bounding box defined in the gpkg_tile_matrix_set table or view for a tile pyramid user data table SHALL be exact so that the bounding box coordinates for individual tiles in a tile pyramid MAY be calculated based on the column values for the user data table in the gpkg_tile_matrix table or view. For example, because GeoPackages use the upper left tile origin convention defined in clause Table Data Values <http://www.geopackage.org/spec/#clause_tile_matrix_table_data_values> below, the gpkg_tile_matrix_set (min_x, max_y) ordinate is the upper-left corner of tile (0,0) for all zoom levels in a table_name tile pyramid user data table.
> “""

I might be missing some context here, but I’ve tried to extrapolating from the above I take it the point of debate is what the restrictions are on values you put in min/max_x/y in gpkg_tile_matrix_set, if any. I don’t seem to remember any real discussions about this topic. I would’t read too much into the use of ‘minimum bounding box’ in the spec. I don’t think this paragraph was worded with the intention of it actually having to be the tightest fitting bounding box for the data. Perhaps it would be best remove the ‘minimum’ from the spec.

The way I see it, the only thing that matters is that the metadata you put in is internally consistent. min/max_x/y defines a spatial extent. That extent gets chopped up into matrix_width x matrix_height equal area tiles at each zoom level. Implicitly this defines the extent of each individual tile. That information simply needs to be ‘correct’ for the data you’re storing. Otherwise georeferencing of the tiles will be incorrect.

Whether the extent specified in gpkg_tile_matrix_set is tight fitting around the data or not doesn’t make any difference from a georeferencing perspective. The biggest impact this has is that if it is tight fitting, then it is much more difficult to extend the data set post creation. Changing minx/max changes the position of tile (0,0) which means you have to change the tile_column/row values of all existing tiles in your dataset. This is just a design decision you have to make when creating a database. If the data is entirely static and will never be extended, then a tight fitting extent is fine. If on the other hand you’re using a geopackage as, for instance, a cache for a WMTS layer with global coverage, then the extent will most likely be the entire world, and tiles you’ll add tiles to the geopackage as they’re loaded from the WMTS. Both are correct usages.

One thing that was omitted in geopackage that is present in WMTS is TileMatrixLimits. I remember arguing that there were already two ways to approximate this and that TileMatrixLimits in a geopackage would be redundant information. You can either
Encode an area of interest in gpkg_contents. The bounds in gpkg_contents are informative. They should of course overlap with the actual data to be useful, but they don’t need to coincide exactly with the bounds from gpkg_tile_matrix_set. You could for instance have a global extent in gpkg_tile_matrix_set and then have a small AOI in gpkg_contents to indicate where the relevant data actually is.
Query min/max(tile_row/tile_column) from the database to figure out where tiles are actually available. If you put an index on tile_row and tile_column this should be a pretty cheap query.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geopackage/attachments/20150601/5ee3c8cc/attachment-0001.html>

More information about the Geopackage mailing list