[Geopackage] Query on gpkg_tile_matrix - matrix_width and matrix_height
Pepijn Van Eeckhoudt
pepijn at vaneeckhoudt.net
Fri Jun 5 09:17:58 EDT 2015
> On 05 Jun 2015, at 14:32, Cochran, Jenifer <jenifer.cochran at rgi-corp.com> wrote:
>> I believe the fundamental difference we are discussing here is between relative tile numbering and absolute tile numbering. For example, let's say you have data at zoom level 1 but you only have the lower right tile (Tile bounds: (0, 0, 180, -85.0511287798066) (min_x, min_y, max_x, max_y)). In absolute tile numbering, like in the google web mercator tiling structure, you would number this tile (1,1) and your matrix_width and matrix_height would be 2 by 2. In relative tile numbering, like the spec requires (using the bounds (0, 0, 180, -85.0511287798066) as the MBR) ,you would number this tile (0,0) and a matrix_width and matrix_height 1 by 1.
And this is the essence of the problem. In your solution, how do you know the bounds of this tile is (0, 0, 180, -85.0511287798066)? There’s no way to derive that from the metadata.
Continuing on the google mercator example, the extent in gpkg_tile_matrix_set will be [-180,180] [-85.0511287798066, 85.0511287798066]. Combining that with tile row/column (0,0) and matrix_width/height (1,1), there’s no way to arrive at tile bounds [0,180][-85.0511287798066,0]. The missing bit of information here is what your anchor point (top-left corner in WMTS terms) is. In GeoPackage that’s always the top-left corner of the extent in gpkg_tile_matrix_set. There’s no way to let this vary per tile_matrix.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Geopackage