[Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height
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.
> 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
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 "22.214.171.124.2. 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...
More information about the Geopackage