[Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height

Cochran, Jenifer jenifer.cochran at rgi-corp.com
Mon Jun 1 08:21:03 EDT 2015


________________________________________
From: Brad Hards <bradh at frogmouth.net>
Sent: Friday, May 29, 2015 8:20 PM
To: Brachman, Micah
Cc: Even Rouault; geopackage at lists.opengeospatial.org; Cochran, Jenifer; Jeff Yutzler
Subject: Re: [Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height

On Fri, 29 May 2015 06:00:24 PM Brachman, Micah wrote:
> There must be an agreement between the tiles present, and the bounding box
> which will ultimately determine the matrix_height and matrix_width.   There
> 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)).  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.
That is contrary to the spec part that says the tiles don't need to be present
at any given zoom level.

~Actually it doesn't.  For instance, say you have tiles at zoom level 2 with tiles that have the minimal and maximal extent satisfying the requirement, then you could have no tiles at zoom level 3.  Just because you have a tile at the extents, doesn't mean there needs to be data below or above that tile. 

The bounding box could describe the potential locations for tiles (including
tiles that haven't been generated / populated yet).

> 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 right. Did you mean to divide at some point, or swap the pixel
and bounding box parts?

~You're right, thanks for the catch.  Replace * with /.   
 ~pixel_x_size = Bounding Box width  / matrix_width  / tile_width
 ~pixel_y_size = Bounding Box height / matrix_height / tile_height

Dear SWG: This is looking like a bug in the spec - whatever the real intent
is/was, it isn't apparent to implementers. Please come to some consensus and
publish a fix.

Brad



More information about the Geopackage mailing list