[Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height
even.rouault at spatialys.com
Fri Jun 5 09:59:10 EDT 2015
Le jeudi 04 juin 2015 22:21:58, Cochran, Jenifer a écrit :
> 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.
I guess the georeferencing would still be correct ?
But one thing that comes to mind is that if you rely on xmin,ymin,xmax,ymax of
gpkg_tile_matrix_set to define an area of interest, you'll have trouble in the
following situation. Imagine that you have a "absolute" GoogleMaps tiling
scheme with only tiles of a country filled at zoom level 20, and all overview
tiles computed up to zoom level 0. Then as you would have tile (0,0) at zoom
level 0, xmin=ymin=-20037508.3427892 and xmax=ymax=20037508.3427892
That would be a valid GeoPackage, even with the interpretation of MBR as
> Our customers will no longer be able to "snap" to where
> the tiles are without the code being changed.
This is normally what the extent in gpkg_contents is for (defining the area of
interest). In my above example, it would contain the MBR of tiles at zoom
> 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.
> -----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
> 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,
Spatialys - Geospatial professional services
More information about the Geopackage