[Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height

Cochran, Jenifer jenifer.cochran at rgi-corp.com
Fri May 29 15:01:09 EDT 2015

Hi Even,

Based on your comments,  we disagree on a fundamental aspect to the GeoPackage specification.  It seems like your comments are geared towards a TMS structure and the GoogleMaps Web Mercator based design.   The fundamental difference is that the bounding box should describe only the data contained in the pyramid user data table rather than the bounds of the world.  The bounding box should only be the entire world if the data in the pyramid user data table contains data for the entire world.

GeoPackages must always report the minimum bounds of the data in the pyramid user data table.  As stated  "The gpkg_tile_matrix_set table or updateable view defines the minimum bounding box (min_x, min_y, max_x, max_y) and spatial reference system (srs_id) for all content in a tile pyramid user data table" (below Table 8 Tile Matrix Set Table or View Definition).

The GeoPackage Spec does allow sparse tile matrices as you mentioned but if you continue reading within the same place you quoted it also states, "This means that a tile matrix set can be sparse, i.e. not contain a tile for any particular position at a certain tile zoom level. [19] This does not affect the informative spatial extent stated by the min/max x/y columns values in the gpkg_contents record for the same table_name, the exact spatial extent stated by the min/max x/y columns values in the gpkg_tile_matrix_set record for the same table name, or the tile matrix width and height at that level. [20]" (below Requirement 52).  This is stating that you may have a sparse data but it must still define the minimum bounds of the data inside the pyramid user data table.  Therefore there should still be data at the minimal and maximal extents (meaning having a tile_row =0, tile column = 0, tile_row = matrix_height -1, tile_column = matrix_width -1). They do not need to be the same tile (it could be one or four different tiles) but they still have to exist (it could be at any zoom level).

I do want to mention that for the equation, the bounding box represented in the gpkg_tile_matrix_set can be different from the bounding box in the gpkg_contents table.  The gpkg_contents table can be simply informational whereas the gpkg_tile_matrix_set must be the exact minimum bounds.  For my equations I am using the bounding box defined in the gpkg_tile_matrix_set and not the gpkg_contents table.

Hope this helps clarify, otherwise happy to discuss this further.


Jenifer Cochran
Software Engineer
Reinventing Geospatial, Inc
4035 Ridge Top Road, Suite 520
Fairfax, VA 22030
Office:  703.272.3204x2067
Jenifer.Cochran at rgi-corp.com<mailto:Jenifer.Cochran at rgi-corp.com>

From: Even Rouault [mailto:even.rouault at spatialys.com]
Sent: Friday, May 29, 2015 2:16 PM
To: Brachman, Micah
Cc: Brad Hards; geopackage at lists.opengeospatial.org; Cochran, Jenifer; Jeff Yutzler
Subject: Re: [Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height



> I've been chatting with some of the software engineers here at RGi about

> your question -- hopefully the information below will help you out.


> First, the WhiteHorse GeoPackage on the OGC website is out of date and the

> matrix_width and matrix_height are incorrect. Here is a link to the

> updated WhiteHorse GeoPackage with the correct matrix_width and

> matrix_height:


> https://drive.google.com/open?id=0ByvLbbvwoxUjREhlbGZyWVpNeG8&authuser=0



> There must be an agreement between the tiles present, and the bounding box

> which will ultimately determine the matrix_height and matrix_width.

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

I don't agree with this (in the general case). The GeoPackage spec explicitely allows sparse tile matrices : "Tiles MAY or MAY NOT be provided for level 0 or any other particular zoom level. This means that a tile matrix set can be sparse, i.e. not contain a tile for any particular position at a certain tile zoom level" and "The gpkg_tile_matrix table or view MAY contain row records for zoom levels in a tile pyramid user data table that do not contain tiles."

I think the intent is that you can use a GoogleMapsCompatible tiling scheme with the origin at minx=-20037508.34, maxy=20037508.34 (and maxx=20037508.34 miny=-20037508.34) (speaking here about the bounds in gpkg_tile_matrix_set), even when dealing with data that has not global coverage.


> 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

You probably meant

Bounding Box width = pixel_x_size * matrix_width * tile_width

Bounding Box heigh = pixel_y_size * matrix_height * tile_height

But this is only true in your hypothesis, which is a very particular case.


> Hopefully this clears the confusion on what the matrix_width and

> matrix_height represent. Thanks



> Micah



> ---------------------------------------------------------------

> Micah Brachman, PhD | Geospatial Scientist

> Reinventing Geospatial | www.rgi-corp.com<http://www.rgi-corp.com>

> 4035 Ridge Top Rd Suite 520, Fairfax, VA 22030


> 703.272.3204 x2066

> micah.brachman at rgi-corp.com<mailto:micah.brachman at rgi-corp.com>







> -----Original Message-----

> From: Geopackage [mailto:geopackage-bounces at lists.opengeospatial.org] On

> Behalf Of Brad Hards Sent: Friday, May 29, 2015 2:16 AM

> To: Even Rouault; geopackage at lists.opengeospatial.org<mailto:geopackage at lists.opengeospatial.org>

> Subject: Re: [Geopackage] Query on gpkg_tile_matrix - matrix_width and

> matrix_height


> On Fri, 29 May 2015 12:54:17 AM you wrote:

> > Hi Brad,

> >

> > > Geopackage spec ( 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?


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


> > 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?


Spatialys - Geospatial professional services

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geopackage/attachments/20150529/a0f74403/attachment-0001.html>

More information about the Geopackage mailing list