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

[Mateusz Loskot]

Pierre Racine wrote: 
> Frank,
> 
> Type 4 is different than 1 and 2 in that:
> 
> -each image meets the regular contraints
> -each image is stored as one separate table

OK, but...question below

> This is the traditional GeoRaster way of storing images (e.g. landsat)
> in a database.
> 
> Types 1 and 2 correspond better to the notion of a coverage (much like
> a vector coverage):
> 
> -in type 1 the global extent is not necessarily rectangular (although
> we could have an option to "force" it to be rectangular by adding
> nodatavalue or empty tiles but this is from my point of view an
> overcomplicated artefact)

IMHO, shape of extent we can handle is important but it doesn't have
highest score. More important (usable) restrictions seem to be:

1. All tiles are of the same determined by size of "natural" block.

2. Tiles fit common grid grid defined by pixel size and
bounding box of global extent (not necessarily rectangular).

3. Tiles do not overlap.

Constraint on shape of extent seems to be optional.
This is how I understand regular blocking should work.

> -for both types, the source is composed of many raster files that most
> be retiled and stored into the same db table

Agreed. At the moment, gdal2wktraster supports single raster file source
in regular blocking. Although, I can't see any reason to not to support
multiple input files, tile them all according to a common
block (tile) size. There is just one factor that makes this operation
more complex, for regular blocking, all tiles being crunched must fit
belong to common grid.

> -another characteristic (which I did not mention) is that tiles might
> not be all of the same size. I could, for example, have many 6030pixels
> by 6030pixels images as source and want to store them as as many (3600
> tiles of 100pixels x 100pixels and the rest as 60 30pixels x 100pixels
> tiles,  60 100x30 tiles and one 30x30 tile).

OK, but then it's not regular blocking.

> I want to be able to import case 1 and 2 in the
> database without having to reconstruct a big raster using other tools.

You can do that.
Now, gdal2wktraster can do it for single file input.
It shouldn't be a problem to implement support for multiple input
raster datasets, if you need it.

> If an application threats each rows of a raster table as a single
> raster
> (as I have always try to sell WKT Raster "a tile is a raster and a
> raster is a tile, there is no distinction") then the application should
> not see any difference. As for a vector layer.

A raster might be a little ambiguous term, sometimes.
A raster is a single pixel (a sample) or it is a complete grid of pixels.
Let's assume a raster is a grid of pixels.
Since the beginning of my WKT raster adventure, I preferred to say:
1 table = 1 raster (raster coverage, raster overlay, just raster).

> I understand however that
> applications prefers to load big rectangular complete tiled rasters but
> this is very limitative and not very practical from an analytical point
> of view.

AFAIU, regular blocking is supposed to help to operate on a part of
big raster (a coverage), on a window of big raster.

> My classical example is storing the SRTM coverage of Canada.

Great, let's try to see what is missing now that prevents us from
loading it.

> It is not and I don't want it to be rectangular,

It doesn't have to.

> the (downloaded) source is composed of many files
> and I can't build a single raster from it
> because it's too big.

Understood.

> I want to be able to import it's many files, retiled to
> smallers tiles in a single table in a single loading command. With this
> I would be very happy (and I guess many of our users) and I could begin
> to do nice vector/raster analysis :-)

So, three questions:
1. Do all these files have the same size of pixel?
2. Can you tile them according to the same size of block (same size of tile)?
3. Are the tiles non-overlapping?

AFAIK, SRTM answers yes to all of these questions.
If this it's true, then we do support this use case!

Best regards,
--
Mateusz Loskot
Senior Programmer, Cadcorp
http://www.cadcorp.com