[Geopackage] Bounding boxes for tiles

Pepijn Van Eeckhoudt pepijn.vaneeckhoudt at luciad.com
Mon Jan 20 04:38:30 EST 2014

On 18-01-14 12:33, Brad Hards wrote:
> My reading of the current (OK, r9) spec text is that the bounds in
> gpkg_tile_matrix_set must reflect the full world (-180.0 to 180.0, and
> something like -85 or -90 to 90 or 85, depending on how the tiles are build /
> transformed), so that you can:
> 1. Add more tiles
> 2. calculate where the tiles go.
> However for gpkg_contents, the bounds should reflect the actual content (i.e.
> should match BoundingBox in the XML above).
> Does anyone interpret it differently?
Regarding gpkg_tile_matrix_set, it doesn't necessarily have to be the 
entire world. This depends on what you're trying to achieve (as Even 
explained in his reply). The spatial extent defined in 
gpkg_tile_matrix_set must align with the tiling strucure because one of 
its intended uses is to compute the spatial extent of individual tiles.
If the tile matrix needs to be extensible, then the extent specified in 
gpkg_tile_matrix_set should cover a larger area (possibly the entire 
world) than the extent in which tiles are actually available.

The contents of gpkg_contents is purely informative. It doesn't impact 
the semantics of the data. You could put a tight fitting bounding box in 
here, the entire world or seomthing in between.

The equivalent of WMTS tile matrix limits can be derived in geopackage 
via the query

select zoom_level, min(tile_column), max(tile_column), min(tile_row), max(tile_row)
from <tile_pyramid_user_data_table>
group by zoom_level

Perhaps the specification should informatively state that this is how 
you can obtain this information.

The downside of this approach is that it requires a full table scan. The 
upside is that we're not duplicating information that is already 
implicity present. Perhaps we should check if the performance of this on 
a huge dataset is acceptable.
I did a quick explain plan check with SQLite 3.8.1. That version (based 
on the release notes this is since 3.7.15) the query is performed using 
a full table scane of the (zoom_level,tile_row,tile_column) unique 
index. Still a full table scan, but at least it's a smaller one than the 
entire tiles table.


More information about the Geopackage mailing list