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

[Mateusz Loskot]

Pierre Racine wrote: 
> >> This is why regular blocking is not as important for me as tiling.
> >> WKT Raster does not care if tiles are not all the same size. Agreed?
> >
> >One correction, WKT Raster can work in two modes:
> >1. By default, it does not care if tiles are of the same size or not.
> >2. If regular blocking enabled, WKT Raster does care.
> >
> >Agreed?
> 
> How does it care?
> Otherwise than setting regular_blocking to true?

Through constraints set by AddRasterBlocking.
It should work (not yet fully implemented) in similar way as PostGIS
and GEOMETRY_COLUMNS restrict geometries to have common srid.

> Raster functions do not have a clue about the global relative structure
> of a table of tile.

They don't need to. We have metadata. RT functions are just tools
used to enforce/assure some restrictions in some use cases.

> From my point of view, regular_blocking is just a flag telling
> applications "he! this table is almost perfect and structured that way
> (like a tiff file!), so you can take advantage of it... if you can..."

No, RB is not just a flag. It's a flag + db-side infrastructure
like metadata and constraints.

> Otherwise an application should load one tile at a time (using a proper
> SQL query) as it does for a vector feature table. It is still not clear
> to me how an application can really take advantage of regular blocking.
> The way you access tiles in a database is very different than the way
> you access tiles in a file.

Basic one is similar to why Web Mapping uses tiles, simpler and faster
rendering.

> >> Question: I did not try the -k option yet. It seems to load tiles as
> >> they are already defined in the file, right? I can't specify a new
> >> block size (this is what I call retiling)? e.g. -k 100x100
> >
> >Right, there is no way to specify size of tile.
> >
> >Simply, I'm a baby of Unix where I use number of scattered but very
> >specialized tools, instead of a few monolithic big applications.
> >Also, I don't like to reinvent the wheel :-) So, if I need to tile a
> >dataset according custom size, I just use GDAL utilities. Then I use
> >gdal2wktraster to load these tiles.
> >That's why I can't see any point to implement custom-size-tiling in
> >gdal2wktraster.
> 
> Then, wasn't adding the -k option a bit reinventing the wheel?

Yes, sort of, but the whole processing behind -k is based
properties deducible automatically, so there is no need for
user to input any parameters just -k.
IOW, the whole process is automated.

> You could have used gdal_retile.py to create a bunch of filesystem tiles
> and import them with the wilcard. This is what I did when I first
> imported my 3600 100x100 tiles three weeks ago.

Note, that -k uses size of "natural" block which is provided by GDAL.

> I was almost happy with
> this solution until you added -k. Then I also wanted it to work on
> multiple files.

Yes, I understand.

> To simplify everything we could also remove the -k
> option and tell our users "if you want this tile structure when
> importing your raster(s), use gdal_retile.py"... Is it really
> "simplifying" if we tell people to use an other tool?

Not exactly. My understanding is that regular blocking is
based on size of "natural" block:

http://gdal.org/classGDALRasterBand.html#f2ee6fa0f675d7d52bc19f826d161ad6

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