[postgis-users] Re: Re: Proposed SQL interface for PGRaster

[Patrick]

"Stephen Marshall" <smarshall at wsi.com> wrote in message 
news:4575E46D.6040302 at wsi.com...
>
> My intention in the design was that PGRasters model the concept of a 
> single tile.  If one wants to combine several tiles to form a larger 
> raster, one can aggregate them using the pgr_merge_raster() function. 
> However, I did not design a "master" raster object that  has a 
> relationship to a group of tiles.  One would instead find these 
> relationships dynamically, i.e. find rasters that "belong" together by 
> doing queries based on other columns in a table containing a PGRaster 
> column.  [...]

Hi Stephen,

I'd say it is a question of logic. To me it doesn't make sense to have a 
large amount of data, cut it into pieces to fit the hardware/software 
environment and then aggregate it back when it is needed. The end-user 
having 60,000 rasters of 6 thematic information sources will perceive this 
as a jumble. Instead, the end-user would like to see 6 rasters, one for each 
thematic source, and not care (and know!) that each raster is made up of 
10,000 tiles.

> Is there anything about the concept of a tile that makes it different from 
> a general raster?  As far as I can tell the only differences are:
> 1. Tiles "know" that they are part of a larger (virtual) image with some 
> known structure
> 2. Several tiles may share some common metadata, such as a geographic 
> coordinate system.
>
> The first has consequences for optimization.  However, I'm not convinced 
> it is absolutely necessary to save tile-raster relationships to be able to 
> quickly merge raster together to form a larger raster.  The second may 
> save a small amount of storage, but is probably not very important, 
> particularly since coordinate system information is already stored by 
> reference (e.g. using an SRID).
>
> Am I missing something more fundamental that distinguishes a group of 
> tiles from a group of rasters that have the same type and resolution and 
> boundaries that line up with one another?
>

Yes, and firstly again the logic. Other than that, there are many properties 
of rasters (in my sense) that transcend (my) tiles. The most obvious are: 
resolution in x and y, data type, endianness, special values (missing, 
nodata), CRS, origin of the data. Then there are properties related to the 
actual data that do not make sense at the tile level such as histogram and 
statistical values (min, max, stdev, etc). Your design does not provide an 
elegant concept of related data (raster bands), such as spectral bands in a 
satellite image. And then there are meta-properties such as metadata, 
attributes of classified data, color maps, lineage, fitness-of-use, data 
production and quality, ownership, access, acceptable use. And so forth.

In short, there are IMHO too many properties of rasters that would not be 
economically stored at the tile level. More fundamentally, creating a 
hierarchy raster <= raster band <= tile provides the glue between the 
different components that make up a single data source that I could not 
discern in your design.

I would like to suggest that the community puts together some real designs, 
develop some use-cases, and then work out how the design affects the 
implementation of some basic operations.

Cheers,
Patrick

Cheers,
Patrick