[postgis-devel] [WKT Raster] Regular blocking in gdal2wktraster.py
Pierre.Racine at sbf.ulaval.ca
Thu Mar 19 07:54:33 PDT 2009
I can see two major user cases that gdal2wktraster.py needs to fulfill:
1) Some users want to store big rasters (overlapping or not, e.g. landsat images) as many tables. In this case 1 raster = 1 row in the raster_column table and hence many tile tables in the database. (100 landsat = 100 files = 100 tables) Some people might want to store only one file, other might want to batch load many.
2) Many users will want to upload coverage already tiled (generally not overlapping, e.g. SRTM elevation data) as a single table. In this case 1 raster = 1 row in the raster_columns table and only one tile table in the database.
a) They might want that to store them tiled as they already are. This is already possible with wildcards.
b) They might want to retile them (in batch) as smaller tiles (similar to case 1 but all in the same table).
Some people might want to store only one raster as a one row tile table. This is identical to scenario 2a but without using wilcards (and only one -r option).
We'll have to make sure all these scenarios are possible. Now only 2a is possible.
For all scenarios, it should be possible to store in-db or out-db. Out-db means the importer should copy the tile files in a determined folder (case 1 and b2). In case 2a the folder already exist.
We can also see a big raster as a single coverage and in this case case 1 and 2b are very similar except for the fact that there is only one file in case 1 and many in case 2. It might be sometime impossible to produce a raster big enough to cover a large extent so that scenario 1 would not be an option but 2b would.
In a best practice documentation section (that I plan to write someday) I would recommand to users scenario 2a or 2b since this is the storage method that will benefit the most from storing raster in the database.
>From: postgis-devel-bounces at postgis.refractions.net [mailto:postgis-devel-
>bounces at postgis.refractions.net] On Behalf Of Mateusz Loskot
>Sent: 19 mars 2009 07:37
>To: PostGIS Development Discussion
>Subject: [postgis-devel] [WKT Raster] Regular blocking in gdal2wktraster.py
>I'm going to add regular blocking support to gdal2wktraster.py loader.
>It means, I'm going to refactor current implementation of the loader,
>so it supports also tiling by block size and I'll add new options.
>Pierre, in particular, if you're going to submit some substantial
>changes to options layout or "wkblify" functions, please be aware
>that we may mess things up if we both do it at the same time.
>Generally, in regular blocking mode, it will be possible to load
>only one raster file which is tiled according to size of block
>reported by loved-by-everyone-and-precious GDAL library.
>The loader will fill RASTER_COLUMNS table with all required meta data,
>as they are reported by GDAL.
>I think that spatial index (option -I, --index) should be generated
>by default, if regular blocking requested.
>For the sake of simplicity, I will stick to the following additional assumptions:
>- single input raster file (as mentioned above)
>- only create or drop-and-create mode possible, but no append to table
>- no out-db tiles supported
>- if filename column requested (option -F, --filename), dummy
>file names will be generated, like basename-RxC where R and C are
>indexes of row and column of particular tile - or something similar.
>If anyone would have comments or suggestions on how regular blocking
>support should work in gdal2wktraster.py, please don't hesitate to
>share them now.
>Senior Programmer, Cadcorp
More information about the postgis-devel