[Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height
jenifer.cochran at rgi-corp.com
Tue Jun 2 21:00:47 EDT 2015
From: Brad Hards <bradh at frogmouth.net>
Sent: Tuesday, June 2, 2015 5:36 PM
To: geopackage at lists.opengeospatial.org
Cc: Cochran, Jenifer
Subject: Re: [Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height
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).
> 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)).
As Dave pointed out, that can't be true, otherwise you can't have a matrix
that (at 4 x 4) looks like:
This would hold true for this matrix. I believe this is an excellent example to clear up the misunderstanding.
this is column:0 there are three tiles here that have one of the minimal extents
XXX <--- this is row:0 there are three tiles here that have one of the minimal extents
XXX <-- this is row: 3 (matrix_height -1) there are also three tiles at one of the maximal extents
this is column: 3 (matrix_width -1) there are also three tiles at one of the maximal extents
I see where the confusion lies. I did not mean that there must exist a tile with the coordinate (0,0) but rather a coordinate with the value (0, X) and (x,0) for the minimal extents (maximal extents would be (matrix_width -1, X) and (X, matrix_height) ).
> 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.
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 believe that this should be cleared up by the statement above. (hopefully :) )
I think that was intended to be supported, because of the way the draft NSG
GeoPackage implementation profile is written:
* the Tile Matrix Extent extension in the NGA profile doesn't make any sense
(since it specifically allows for "missing" indicating that there are no tiles
present in the bounding box extent).
* the notes in nga_tile_pyramid_design (in combination).
> 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.
You're right, I made an error. Please replace the * with the / then it is true.
However that just redefines the problem into bounding box is "actual tiles in
the tiles table" or "potential tiles in the tiles table".
This was never a confusion before this discussion. We had spoken with Paul Daisey about this issue and was very adamant that it describes the actual tiles in the table. But again I was waiting to discuss these problems further until this is either re-confirmed or overturned.
> 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
I apologize for the confusion, it was never my intention. I have been reading the spec and It does specifically mention that the bounds must be the minimum bounds which is the essential factor to getting this part right for the spec.
BTW: Why is the ERDC sample in 3857 when the NGA prohibited that as a valid
More information about the Geopackage