[postgis-devel] [WKT Raster] Regular blocking in gdal2wktraster.py

[Pierre Racine]

>If the data you add afterward overlaps with the existing tiles, it
>should be written into those existing tiles. Whatever script you run to
>do this loading should have have options to specify if you only
>overwrite existing no-data values or if you should overwrite everything.
>This supports the use case of building a "big raster" out of a set of
>potentially overlapping, irregular input images - for example,
>mosaicking orthophotos or satellite imagery.

I think it is better to just let the users load their data in the DB, them being overlapping, regularly blocked, red, yellow or white and provide them with tools to work with their data however they are, as in any GIS software.

>I understand how geo-referencing works. But yes, we are really saying
>nothing here - if we allow irregularity, we will have irregularity - my
>argument is that allowing it does not simplify anything, and it
>definitely hurts performance.

We never said it would be simple. But definitely it will be usefull! As PostGIS is... There are millions of irregularities in vector coverages and still people use and love PostGIS. We'll try to make raster works the same way.

>> In WKT raster each row is an independent raster (contrary to Oracle GeoRaster). We support non-
>regular blocking (i.e. variable-size tiles) to efficiently rasterize geometry columns (one feature =
>one raster) and easily implement vector/raster operations. We also have constraints to ensure regular
>blocking in case users need it. We support both worlds because both worlds have pros and cons for
>specific applications.
>>
>Ok, I think I understand the issue now. You want to be able to treat the
>raster results of operations in the same way as any other raster (aka.
>tile). In this case it seems to me that you need to be able to allow
>overlapping tiles as well, as the results of "select
>rasterize(line_column) certainly have the possibility of overlapping -
>the result being that you don't have a single raster, you have a
>collection of them, one for each of the original features you had. If I
>want to overlay a collection of features onto my set of regular raster
>tiles, the result would still be regularly tiled.

Exactly.

>I guess I can't think of any operations that would result in a single
>raster with variable-size tiles, assuming you force all raster data to a
>regular tile-size on input.

But you could end with a very big raster almost only filled with nodatavalue. I prefer to shrink it to its minimal significan value extent.

>> From my point of view regular blocking is optional. It is a specific way of a more general way to
>store tiles. Does applications like Google Earth profit from regular blocking? Why is it better to
>query for regular blocked tiles in chunks than just querying for tiles with a proper SQL query and
>display them as independent raster forming a layer? This is the way vector layer works and nobody
>complains.
>>
>
>Google Earth absolutely benefits from regular blocking, because of how
>it simplifies data retrieval and caching. Locality of reference is the
>reason why it is better to request tiles as they are, rather than
>request the database resize/crop them to your request. A truth common to
>both mapping and analysis is that you are very likely to request the
>data nearby the data you just requested. Why ask for only half a tile,
>when if you knew that you were requesting half you would have asked for
>the whole thing - because your next request is for the other half of the
>same tile.

Be cautious here. It benefits from tiling, not from regular blocking which is an additional constraint. Tiling is the best invention in the world but regular blocking is too limitative.

Pierre