[Tiling] compact tile format anyone

[Mateusz Loskot]

On 26/12/10 12:33, thomas bonfort wrote:
> * raster data is either stored uncompressed in the database itself,
> or as references to external files: with the actual spec we are
> either left with having to recompress data to png/jpeg on the fly
> which is incompatible with the high performance needs of a tiling
> server, or having to reference external files which does not solve
> the problem of a self contained compact tile format.

Thomas,

Yes, this may be an issue.

> could the spec be enhanced so that a wktraster row can contain a
> "blob" that's the actual compressed image?

Theoretically, it could be possible.
However, it would require serious work to support compressed
serialised data by SQL API.

> * no pyramids (reduced resolution coverages can be stored as a 
> separate layer): as a tileset is an actual pyramid, storing each
> tile resolution as a separate layer doesn't seem like a very elegant 
> solution.

There are pyramids. They are called overviews and managed by
RASTER_OVERVIEWS metadata table. Physically, each overview is stored as
a separate table and registered in RASTER_OVERVIEWS. The base level is
registered in RASTER_COLUMNS. The idea is that client has freedom about
how to render data. Client queries metadata of raster layer and
overviews and decides how to render it.

> * no multiple dimensions (eg. wms time): probably less important,
> but it would be nice if the format could take into account multiple 
> dimensions natively, as it is not an uncommon tiling requirement.

Good point.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org