[Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height
Pepijn Van Eeckhoudt
pepijn at vaneeckhoudt.net
Wed Jun 3 03:58:39 EDT 2015
Hi Brad, all,
> On 02 Jun 2015, at 23:36, Brad Hards <bradh at frogmouth.net> wrote:
>
> 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).
Yes, that’s the intended usage. gpkg_tile_matrix_set and gpkg_tile_matrix define the grid/matrix/areas where tiles are located. This is orthogonal to presence of data in the user data table.
The misleading part in the spec is the use of the word ‘minimum bounding rectangle’. That should probably be removed, but that’s something for the SWG to tackle.
If you need to determine the MBR for actually present data you should do a SQL query to select minimum and maximum tile_row and tile_column from the user data table.
Note that this is identical to WMTS. gpkg_tile_matrix_set and gpkg_tile_matrix are equivalent to TileMatrixSet and TileMatrix in WMTS.
In WMTS you would use TileMatrixLimits to indicate a sub region of the entire tile structure that actually contains data. GeoPackage doesn’t have this, but you can achieve a similar effect using the SQL query above or the extent in gpkg_contents.
> 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:
Yes this is/was indeed an intended use case. It allows easy extraction of subsets of larger data sets without having to retile.
>> 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.
To be honest I don’t really understand what the confusion is about. Think about this from a georeferencing perspective. Where is a tile (z, c, r) located? The equations for that are
tile_matrix_set_width = tile_matrix_set.max_x - tile_matrix_set.min_x
tile_matrix_set_height = tile_matrix_set.max_y - tile_matrix_set.min_y
tile_upper_left_x = tile_matrix_set.min_x + c * tile_matrix_set_width / tile_matrix(z).matrix_width
tile_upper_left_y = tile_matrix_set.max_y - r * tile_matrix_set_height / tile_matrix(z).matrix_height
There’s still an infinite (well not really infinite, but you know what I mean) number of combinations of tile_matrix_set/tile_matrix combinations that you can use to get your tiles georeferenced correctly, but there are no ‘multiple combinations’ that readers need to handle differently. If the formulas above result in tiles being georeferenced correctly, then the metadata is incorrect.
>> 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”.
I think the right equation has already been posted.
For each zoom level the following must hold
tile_matrix_set_width = tile_matrix(z).pixel_x_size * tile_matrix(z).tile_width * tile_matrix(z).matrix_width
tile_matrix_set_height = tile_matrix(z).pixel_y_size * tile_matrix(z).tile_height * tile_matrix(z).matrix_height
From that it’s clear the gpkg_tile_matrix has one set of redundant variables. I seem to remember discussing this at one point, but I can’t remember why the redundant information was retained.
Best regards,
Pepijn
More information about the Geopackage
mailing list