[Geopackage] Bounding boxes for tiles

Even Rouault even.rouault at mines-paris.org
Sat Jan 18 18:22:52 EST 2014


Le samedi 18 janvier 2014 17:19:01, Paul Daisey a écrit :
> Brad:
> 
>      I think it is the other way around.  The bbox in gpkg_contents is
> informative:
> 
> 1.1.3.1.1 "The bounding box (min_x, min_y, max_x, max_y) provides an
> informative bounding box (not necessarily minimum bounding box) of the
> content."
> 
> whereas the one in gpkg_tile_matrix_set is to be exact.
> 
> 2.3.6.1.2 "The minimum bounding box defined in the gpkg_tile_matrix_set
> table or view for a tile pyramid user data table SHALL be exact so that
> the bounding box coordinates for individual tiles in a tile pyramid MAY
> be calculated based on the column values for the user data table in the
> gpkg_tile_matrix table or view."

Paul,

reading the above, I believe that the text you quote doesn't necessarily 
contradicts Brad assumptions.

A reasonable content for the bounding box in gpkg_contents that provides an 
informative bounding box would be the bounding box at the highest zoom level 
(i.e. more detailed).

As far as gpkg_tile_matrix_set is concerned, it is a matter of strategy.  I 
can see 2 different strategies that could be used in practice and seem to be 
allowed by GeoPackage spec :
- one where you adjust closely to the current content of the raster table. 
i.e. you decide that (min_x, max_y) matches the coordinates of the upper-left 
corner of the raster at its highest zoom level. For lower zoom levels, padding 
will be found at the lower-right of those tiles. The inconvenient of that is 
that you cannot extend the raster table to the upper-left of the current 
content. Such a strategy would be what would be the easier to implement for a 
to-be-created "gdal_translate -of GPKG in.tif out.gpkg" and would enable 
tripping back to GeoTIFF to be exact (the pixel_x_size, pixel_y_size of the 
highest zoom level would be the pixel size of the base GeoTIFF)
- one global strategy (-180,90) for long/lat for exemple. similarly to the 
GlobalCRS84Pixel pre-defined tile matrix set of WMTS. This is what programs 
that compute tile sets would do. This potentially implies resampling of the 
base raster level. But overlaying layers of such rasters is then easier since 
they all share the same tile scheme.

Even

> 
> Paul
> 
> On 1/18/2014 6:33 AM, Brad Hards wrote:
> > I'm updating my old code for converting the output of gdal2tiles.py to
> > geopackage. A typical index file (tilemapresource.xml) looks like:
> > 
> > <?xml version="1.0" encoding="utf-8"?>
> > 
> >          <TileMap version="1.0.0"
> >          tilemapservice="http://tms.osgeo.org/1.0.0">
> >          
> >            <Title>pap.vrt</Title>
> >            <Abstract></Abstract>
> >            <SRS>EPSG:900913</SRS>
> >            <BoundingBox minx="18.39785146190368"
> >            miny="-72.43391470757965"
> > 
> > maxx="18.67206370360821" maxy="-72.18546427890816"/>
> > 
> >            <Origin x="18.39785146190368" y="-72.43391470757965"/>
> >            <TileFormat width="256" height="256" mime-type="image/png"
> > 
> > extension="png"/>
> > 
> >            <TileSets profile="mercator">
> >            
> >              <TileSet href="10" units-per-pixel="152.87405654296876"
> > 
> > order="10"/>
> > 
> >              <TileSet href="11" units-per-pixel="76.43702827148438"
> > 
> > order="11"/>
> > 
> >              <TileSet href="12" units-per-pixel="38.21851413574219"
> > 
> > order="12"/>
> > 
> >              <TileSet href="13" units-per-pixel="19.10925706787109"
> > 
> > order="13"/>
> > 
> >              <TileSet href="14" units-per-pixel="9.55462853393555"
> >              order="14"/> <TileSet href="15"
> >              units-per-pixel="4.77731426696777" order="15"/> <TileSet
> >              href="16" units-per-pixel="2.38865713348389" order="16"/>
> >            
> >            </TileSets>
> >          
> >          </TileMap>
> > 
> > In this case, there are four tiles at zoom level 10, where the actual
> > content is shown the bounding box above.
> > 
> > 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?
> > 
> > Brad

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html


More information about the Geopackage mailing list