[Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height

Brad Hards 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).

> 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)).
As Dave pointed out, that can't be true, otherwise you can't have a matrix 
that (at 4 x 4) looks like:
   XXX
XXXX
XXXX
XXX

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

Brad

BTW: Why is the ERDC sample in 3857 when the NGA prohibited that as a valid 
use?


More information about the Geopackage mailing list