[postgis-devel] [raster] Regular blocking refinement
mateusz at loskot.net
Wed Dec 1 04:53:05 PST 2010
At the FOSS4G 2010 in Barcelona, I talked with Pierre about
refinement of the idea of regular blocking configuration.
It seems to be still unclear if the regular blocking should define a
complete grid of tiles with no tiles missing. The picture attached
presents two tile coverages:
- blue is regular thus complete
- red is irregular (or rather incomplete regular coverage?, see below)
I understand Pierre's reasoning and I tend to agree with Pierre
that both cases should be supported.
I tried to understand how the popular tiling schemes deal with similar
configurations and I posted some questions to the tiling ml:
The very first question is if both, the blue and red configurations,
are/should be kosher.
It seems we do allow it in the specification:
"It is permissible to for regular_blocking rasters to omit some
blocks/tiles (sparse rasters) in which case the missing tiles
should be assumed to be all NODATA or zero valued."
However, what the "assumed to be all NODATA or zero valued" means?
Does it mean we actually want to store those tiles in database
or generate them on fly?
Or, is this just an indication for clients: if a tile is missing in
query result, cope with it on your own by generating NODATA tiles?
IMHO, this matter is unclear and it is important to specify behaviour
on SQL level first. For example, SQL query against in coverage
configured as regular blocking, returns no tuples for missing tiles.
It is important to clarify the "regular blocking" refers to virtual grid
used as frame reference to place tiles, but empty cells in this grid are
I think the "no tuples for missing tiles" approach is better,
because it does not imply any particular raster value: NODATA tile,
zero'ed tile or transparent tile or anything else.
Clients can cope with missing tiles as they like.
Comments are welcome.
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.orgirregular
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 23714 bytes
Desc: not available
More information about the postgis-devel