[Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height

Even Rouault even.rouault at spatialys.com
Fri May 29 16:21:37 EDT 2015


> Based on your comments,  we disagree on a fundamental aspect to the
> GeoPackage specification. 

Indeed. My comments were based on a previous discussion of a few months ago
where I mentionned 2 possible strategies :

And my understanding of the following message is that Pepijn confirmed that 
both were valid:

> It seems like your comments are geared towards
> a TMS structure and the GoogleMaps Web Mercator based design.

My understanding was that a possible use case for GPKG could be a storage 
backend for a WMTS server, in which case you could take the z/x/y coming from 
WMTS and extract the tile from the GPKG directly with those tile coordinates.

> 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 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.

> Therefore there should still be data at the minimal and maximal extents
> (meaning having a tile_row =0, tile column = 0, tile_row = matrix_height -1,
> tile_column = matrix_width -1). They do not need to be the same tile (it
> could be one or four different tiles) but they still have to exist (it could
> be at any zoom level).

Skimming quickly through the conformance test suite, I don't see a test that 
would enforce that.

Another consequence of your interpretation is that a tile pyramid user data 
table could not be empty, since Table 8 (Tile Matrix Set Table or View 
Definition) mentions that min_x, min_y, max_x, max_y can not be NULL. But note 
21 mentions "[...] Tile pyramid user data tables in a GeoPackage MAY be 
empty". So when tile pyramid user data tables are empty, which values would 
one put in min_x,min_y,max_x,max_y of gpkg_tile_matrix_set if they must be 
tied to actual tile presence ?

> I do want to mention that for the equation, the bounding box represented in
> the gpkg_tile_matrix_set can be different from the bounding box in the
> gpkg_contents table. 

I agree on that point.

> The gpkg_contents table can be simply informational
> whereas the gpkg_tile_matrix_set must be the exact minimum bounds.  For my
> equations I am using the bounding box defined in the gpkg_tile_matrix_set
> and not the gpkg_contents table.

I agree on that point.

> Hope this helps clarify, otherwise happy to discuss this further.

I think we need to have a referee on this ;-)


Spatialys - Geospatial professional services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geopackage/attachments/20150529/3b3183b9/attachment.html>

More information about the Geopackage mailing list