[postgis-devel] Regular raster blocking (was: Real extent feature lost after metadata as views)

Mateusz Loskot mateusz at loskot.net
Fri Dec 7 05:25:32 PST 2012


On 6 December 2012 18:32, Pierre Racine <Pierre.Racine at sbf.ulaval.ca> wrote:
>
> The regular_blocking constraint for a raster coverage (or raster table) is set to TRUE if and only if the following conditions are fulfilled:
>
> 1) All rasters (or tiles) have the same SRID, scale_x, scale_y, skew_x, skew_y, number of band and all the
> corresponding bands (having the same band number) have the same pixel types and nodata values.
>
> 2) All rasters (or tiles) have their upper left corners aligned on a grid defined by the upper left corner of the coverage (or table) global extent and the block sizes.
>
> 3) All rasters (or tiles) have their width equal to blocksize_x and their height equal to blocksize_y.

I agree with all the three points. (I snipped the details).

I would group the rules according to the following three topics:
1. Tile raster metadata
2. Tile raster location
3. Tile raster dimensions
with the details are as you proposed.

Perhaps some reference to the SQL functions would make it clearer to
comprehend the rules.
For example, for 1. it could be:

For all tiles in table, ST_MetaData must return the same values for
corresponding attributes, apart from the coordinates of upper left
corner.
For all tiles in table, ST_BandMetaData must return the same values
for attributes of corresponding bands.


> I think there is no need any more to ensure that "All tiles must be non-overlapping" or "There must be no gap"
> since both are ensured by the conjunction of the three conditions. Any counter example?

I agree.
Conjunction of 1. and 2.  and 3. is a sufficient guarantor here.

> This definition remove the constraint over rotated extents and is hence more general.

I'm fine with removing this constraint.

> Is there any reason why a regularly blocked coverage should not be rotated?

I see no reason.

> A rotated coverage is just a matter of raster georeference right?

Yes.

> A source raster should be loaded tiled as a set of rotated tiles and exported unioned as a big rotated raster no?

Yes.

> Let me know of any inconsistency of syntax error.

same_alignement -> same_alignment

Later, I'll do edits in SVN if necessary.

> I wish the definition would end up in this part of the doc:
>
> http://postgis.refractions.net/documentation/manual-svn/using_raster_dataman.html#RT_Loading_Rasters

Specification of regular blocking as a storage technique belongs to metadata
specification and it is currently in 5.2 Raster Catalogs, I guess,
I'm not sure what is the rationale behind current order of the sections,
but IMHO they should be reordered this way:

5.1. Raster Catalogs
5.1.1. Raster Columns Catalog   // regular_blocking is one-liner,
links to 5.1.3 for details
5.1.2. Raster Overviews
5.1.3. Regular Blocking Technique // here goes the updated spec
5.2. Loading and Creating Rasters
5.3. Building Custom Applications with PostGIS Raster

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net



More information about the postgis-devel mailing list