[Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height

Even Rouault even.rouault at spatialys.com
Fri May 29 14:16:03 EDT 2015


Micah,
> 
> 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
> 4035 Ridge Top Rd Suite 520, Fairfax, VA 22030
> 
> 703.272.3204 x2066
> 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
> 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 (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?
> 
> > > 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
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geopackage/attachments/20150529/333c3ce5/attachment-0001.html>


More information about the Geopackage mailing list