[postgis-devel] WKTRaster & overviews

[Pierre Racine]

Hi Martin,

What are the pros of having a new table over simply adding:

overview_factor
or_table_catalog ("or_" for "original raster" or "br_" for "base raster"
or "pr_" for "parent raster" or "hrr_" for higher resolution raster)
or_table_schema
or_table_name
or_column

to the existing raster_columns table? This correspond better to 1 to
many relation (which is the case for overviews) while the table you
propose correspond to a many to many relation. For "original rasters",
overview_factor would be 0 and "or_" attributes would be empty.

An application could get the list of original raster with "SELECT * FROM
raster_columns WHERE overview_factor = 0" and get the first overview of
"myraster" with "SELECT * FROM raster_columns WHERE or_table_name =
'myraster'.

You could even remove the need for overview_factor if instead of
refering to the "original raster" you would refer to the "parent raster"
(the 1/4 overview being the overview of the 1/2 one) and assume that
"child raster" resolution is always twice the one of its "parent".

Pierre

>-----Original Message-----
>From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-
>bounces at postgis.refractions.net] On Behalf Of Martin Daly
>Sent: 13 mai 2009 07:49
>To: postgis-devel at postgis.refractions.net
>Subject: [postgis-devel] WKTRaster & overviews
>
>Frank's raster_columns metadata table is more-or-less implemented now,
>so I'd like to propose a further development.
>
>If the raster_columns "regular_blocking" value is true then "all blocks
>are equal sized, abutted and non-overlapping, started at top left
>origin", plus additional constraints.
>
>This regular blocking capability raises the possibility of having very
>large contiguous raster coverages (made up of many individual
>WKTRaster-s) which, in turn, raises potential performance problems.
>Other raster formats counter this by having overviews; a concept that
is
>already handled by GDAL.
>
>I would therefore like to propose an additional metadata table,
>raster_overviews, as follows:
>
>o_table_catalog
>o_table_schema
>o_table_name
>o_column - together define the column containing overview data
>r_table_catalog
>r_table_schema
>r_table_name
>r_column - together define the base raster coverage
>out_db - false if the overview uses internal tiles, true if the
overview
>tiles are references to files outside the database
>overview_factor - the integral factor of the overview, e.g. 2 means an
>overview is 1/2 resolution of the base raster coverage
>
>Restrictions are as follows:
>
>blocksize_x|y for the overview is the same as that of the original,
base
>raster coverage
>pixelsize_x|y for the overview is calculated from the original, base
>raster coverage pixelsize_x|y (using overview_factor)
>overviews should not be registered in raster_columns
>the raster_overviews table can have more than one entry for any given
>base raster coverage, but they must all have different overview_factor
>values, e.g. 2, 4, 8, 16, etc.
>
>No provision is provided, or suggested, for creating, updating, or
>deleting overviews. Mateusz will, however, change gdal2wktraster to
>create overview tables and populate the raster_overviews table (using
>GDAL-provided overviews) where relevant.
>
>Comments welcome.
>
>M
>_______________________________________________
>postgis-devel mailing list
>postgis-devel at postgis.refractions.net
>http://postgis.refractions.net/mailman/listinfo/postgis-devel