[Geopackage] Describing sparse tile sets
jeffy at imagemattersllc.com
Thu Jun 4 08:52:31 EDT 2015
On Thu, Jun 4, 2015 at 3:19 AM, <geopackage-request at lists.opengeospatial.org
> Date: Thu, 4 Jun 2015 09:21:32 +0200
> From: Pepijn Van Eeckhoudt <pepijn at vaneeckhoudt.net>
> To: geopackage at lists.opengeospatial.org
> Subject: Re: [Geopackage] Query on gpkg_tile_matrix - matrix_width and
> Message-ID: <C91EBB06-CE00-41F8-A269-FA537687744D at vaneeckhoudt.net>
> Content-Type: text/plain; charset=utf-8
> Hi Jeff,
> > We could have a way to describe the tiles that are present in a
> particular tile matrix but this capability is completely missing in GPKG
> today (short of doing an SQL query and counting). We are currently
> analyzing potential approaches. WMTS has TileSetLimits (Table 12 in
> 07-057r7) but they didn't get it right either - you can use it as an MBR
> but you can't have a set of them to describe a sparse tile set. The WMS SWG
> has agreed to look into this.
> Paul Daisey, Roger Brackin and I (and perhaps you were involved as well)
> did some work related to this in the context of using OWS Context and
> GeoPackage together. Paul (or you) came up with an XML schema to describe
> ?scanlines? of tiles. Never tested in practice though, so I have my doubts
> how useful that would be in practice. For large tile sets this can end up
> being a pretty large chunk of XML.
Since you brought this up, we decided to go in a different direction and
describe the contents of the tile matrix with a set of rectangular patches
(instead of scanlines) based on WMTS TileMatrixLimits (note I typed the
wrong thing above). For many scenarios this is more efficient than
scanlines but of course for a long diagonal it would still be lousy.
> I think the min/max SQL queries are fine. Perhaps some performance tests
> should be done on real world datasets to see how fast this query can be
> performed on a typical mobile device and desktop (will depend on presence
> or absence of indices on tile_row and tile_column of course).
> If this query is fast enough in practice for real world data, then it?s
> probably not worth it to materialise that information in a table. This kind
> of materialised metadata has a tendency to get out-of-sync with the real
In a standalone application the capability probably isn't needed. It does
matter when you want to be able to synchronize your GeoPackage with new
tiles (for example if you are moving into an adjacent area). To support
this, we want some way to express to an outside process what tiles we
already have. I'm leaning towards not expressing this information directly
in a table and instead putting it in the metadata via an OWS Context. The
context would describe the GeoPackage's contents (a manifest). A broker
could submit the manifest and an area of interest to a server and the
server could return a set of new tiles to be inserted into the GeoPackage.
If we get this working we would document it as a best practice.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Geopackage