[Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height
Brachman, Micah
micah.brachman at rgi-corp.com
Fri May 29 14:00:24 EDT 2015
Brad,
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.
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
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?
More information about the Geopackage
mailing list