[Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height
bradh at frogmouth.net
Tue Jun 2 17:36:35 EDT 2015
On Fri, 29 May 2015 01:35:11 PM Cochran, Jenifer wrote:
> There must be an agreement between the tiles present, and the bounding box
> which will ultimately determine the matrix_height and matrix_width.
I disagree. From my original involvement (which was cut off, so things could
have changed, hence my concern) and more recent work, I think the rows in
gpgk_tile_matrix_set and gpkg_tile_matrix are intended to describe the shape
of the matrix, not actual content (which you get by doing a query on the
specific tiles table).
> ought to be one tile in each of the minimal and maximal rows and
> columns(There must be a tile at row: 0, column: 0, row: (matrix_height -
> 1), and column: (matrix_width -1)).
As Dave pointed out, that can't be true, otherwise you can't have a matrix
that (at 4 x 4) looks like:
> This must hold true at any of the zoom
> levels. If this doesn't hold true then the bounding box doesn't represent
> the minimum bounds of the data.
Ignoring the (0,0) tile and (matrix_width - 1, matrix_height -1) tile part,
which might or might not be what you were really trying to say, this part
about the bounding box representing "tiles actually present" means that you
can't have variable level of detail (e.g. whole world at zoom levels 0-5, then
central america at 6-12, then haiti at 13-18).
I think that was intended to be supported, because of the way the draft NSG
GeoPackage implementation profile is written:
* the Tile Matrix Extent extension in the NGA profile doesn't make any sense
(since it specifically allows for "missing" indicating that there are no tiles
present in the bounding box extent).
* the notes in nga_tile_pyramid_design (in combination).
> The data must also comply with the following equations: pixel_x_size =
> Bounding Box width * matrix_width * tile_width
> pixel_y_size = Bounding Box height *
> matrix_height * tile_height
That can't be true. See earlier discussion on divide vs multiply.
However that just redefines the problem into bounding box is "actual tiles in
the tiles table" or "potential tiles in the tiles table".
> Hopefully this clears the confusion on what the matrix_width and
> matrix_height represent.
On the contrary. But we're rehashing old ground, not progressing. Either the
SWG sorts this out, or readers will have to deal with the various
BTW: Why is the ERDC sample in 3857 when the NGA prohibited that as a valid
More information about the Geopackage