[Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height

Even Rouault even.rouault at spatialys.com
Fri May 29 10:17:23 EDT 2015


Le vendredi 29 mai 2015 08:15:36, Brad Hards a écrit :
> On Fri, 29 May 2015 12:54:17 AM you wrote:
> > Hi Brad,
> > 
> > > Geopackage spec (2.2.7.1.1) describes the gpkg_tile_matrix table.
> > > 
> > > matrix_width and matrix_height are described as >=1.
> > 
> > Well, Table 9 is a bit more verbose :
> > matrix_width Number of columns (>= 1) in tile matrix at this zoom level
> > matrix_height Number of rows (>= 1) in tile matrix at this zoom level
> > 
> > and then Table 10 and req 55 and 56 also give a hint of the meaning.
> 
> OK, so matrix_width / matrix_height doesn't represent the actual number of
> tiles present, but some notional upper bound on the number of tiles that
> might be present?

Yes, my understanding is that it represents the potential addressable extent.

> 
> > > The note below Requirement 44 says that there can be records for zoom
> > > levels that do not have any tiles populated.
> > > 
> > > However I can't find an authoritative reference that says what
> > > matrix_height and matrix_width are intended to describe. I assume that
> > > they're meant to be a describe the "framework" for the tiles. So if
> > > we're power of two, and the next higher matrix_width was 2, then this
> > > matrix_width will be 4 (irrespective of what tiles are actually
> > > populated).
> > 
> > Not being an authoritative voice, my understanding is that it is not
> > necessary.
> > For example if you're interested in North America, in GoogleMaps tile
> > matrix set, you could have in theory :
> > level 0 : matrix_width = matrix_height = 1 (world coverage)
> > level 1 : matrix_width = matrix_height = 1 (top-left quadrant coverage)
> > 
> > since you will never populate other quadrants.
> 
> So at some lower zoom level where there are a lot of tiles, if you add
> tiles to the left / upper of what is already present, you don't have to
> change matrix_width / matrix_height; but if you add tiles in the
> lower/right direction, you do have to change matrix_width / matrix_height.
> That seems pretty inconsistent.

I didn't mean you *had* to restrict matrix_width and matrix_height to the 
minimum possible value, but you *could* do it. In fact in WMTS, you also have 
the concept of TileMatrixSetLimits so as to be able to use the same 
TileMatrixSet for different layers that don't have the same extent but use the 
same tiling scheme. If ported to GPKG, it would define the min & max values of 
tile_column and tile_row of records in a tile pyramid user data table. This 
concept has not been ported to GPKG, which is not a bad thing, since WMTS has 
so many ways of restrincting the extent : ows:BoundingBox at layer level, 
and/or TileMatrixSetLimits at layer level and/or ows:BoundingBox at TileMatrix 
level !
In GeoPackage, you'd rather use the xmin,ymin,xmax,ymax of gpkg_contents to 
indicate the area of interest at the maximum zoom level (that's how I used it 
in the GDAL GPKG driver, and seems to be one of the intended way according to 
discussions that happened here those last monts), and set xmin,ymin,xmax,ymax 
in gpkg_tile_matrix_set to the maximum extent considering all zoom levels 
(which is typically the one of the minimum zoom level)

> 
> > As this was inspired from WMTS, the meaning of matrix_width and
> > matrix_height should be the same as WMTS MatrixWidth and MatrixHeight
> 
> OK, maybe some  easier questions:
> 
> 1. What is always true about matrix_width / matrix_height, except for it
> always being at least one?
> 
> 2. What is the intent of having them, for a reader?

I somehow see your point. I think that, except to avoid folks creating tiles 
with tile_column, tile_row that don't make sense, it could have been 
completely removed, considering there are other ways of figuring out the extent 
of a tile pyramid user table. The same holds true for WMTS by the way.


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the Geopackage mailing list