[Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height

Pepijn Van Eeckhoudt pepijn at vaneeckhoudt.net
Fri Jun 5 03:21:48 EDT 2015


Hi Jenifer,

I’m having a hard time understanding how you could use matrix_width/height in any other way then we’ve been discussing so far. There’s only a single extent at the tile_matrix_set level. That extent gets chopped up into matrix_width x matrix_height tiles (or pixel_x_size * tile_width, …). I don’t think there’s any ambiguity here.

I agree that if the extent in tile_matrix_set is not the MBR, then you can’t ‘snap’ directly to the data. You could use gpkg_contents’ extent instead for this or just accept that with this type of file the ‘snap to data’ doesn’t work snap as tightly as it could.

Suppose you have a WMTS and using the google web mercator tiling structure. Now take one path down the quad-tree down to the most detailed level and encode each tile along that path. This gives you a global overview tile at top level and a smaller area of more detailed data at each subsequent level. In the MBR interpretation, how would you encoded this?

Best regards,

Pepijn

> On 04 Jun 2015, at 22:21, Cochran, Jenifer <jenifer.cochran at rgi-corp.com> wrote:
> 
> Hi All,
> 
>    I know that many of you oppose the minimum bounding box that is mentioned in the specification in two different places but that is what the specification clearly says.  We even confirmed this detail with Paul Daisey  that the intention was clear, that the bounding box should represent the minimum bounds of the tile data that is in the pyramid user data table.  If there was disagreement on this implementation then there had been a window of opportunity to make changes and give input about 2 years ago before it was finalized and released.   If this is something that needs to be changed, I believe the best course of action is to make a new draft of the GeoPackage specification.  I truly understand the benefits of being able to specify a bounding box that is not the minimum bounds in order to use absolute tile numbering or be able to add additional tiles without re-numbering the tiles already there.  I would also not be opposed to this change for a future release of the specification. The problem with changing how the specification is worded now is that there are already a few implementations our company has launched that has a large user base which follows the specification as it is stated now. If the wording in the specification is ignored or changed then the GeoPackage's that do not adhere to the minimum bounds will not work correctly.  Our customers will no longer be able to "snap" to where the tiles are without the code being changed.  Unless there is a larger user base out there using an implementation of the specification without following the minimum bounds rule, there is not a valid reason to ignore or change the specification as it stands for GeoPackage 1.0.1. 
> 
> V/R,
> 
> Jenifer   
> 
> 
> -----Original Message-----
> From: Pepijn Van Eeckhoudt [mailto:pepijn at vaneeckhoudt.net] 
> Sent: Wednesday, June 03, 2015 3:59 AM
> To: Brad Hards
> Cc: geopackage at lists.opengeospatial.org; Cochran, Jenifer
> Subject: Re: [Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height
> 
> 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 t
> ile_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