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

[Stephen Marshall]

A number of folks have responded regarding tiling of PGRasters.   This 
seems like the biggest hot button issue, so I'd like to explore it a bit 
further.

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.  For example, one could collect a group of rasters to pass to 
pgr_merge_raster() using a query to find all the rasters in the table 
goes_satellite_images where channel = IR11 and valid_time = 
20061204T120000Z:

    select pgr_merge_raster(raster_array) as full_raster from (
        select pgr_raster_accum(raster) as raster_array
        from goes_satellite_images where channel = 'IR11' and valid_time 
= '20061204T120000Z'
    ) as subqry

NOTE: This implies an aggregate function for PGRaster similar to PostGIS 
accum() function for GEOMETRY objects. i.e pgr_raster_accum(PGRaster) 
which aggregates PGRasters from multiple records in a PGRaster array.  
Such a function should be added to the document.

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?

Steve

Patrick wrote:

>"Webb Sprague" <webb.sprague at gmail.com> wrote in message 
>news:b11ea23c0612051054o6f1d84c1g14d122604f1f471c at mail.gmail.com...
>  
>
>>(3) Tiling and views: It might be worthwhile to think about having
>>every raster be a set of 1 or more tiles (pgChip type?), probably of
>>an optimized size, and have the user level functions deal with views
>>of this set.  For example, a get_raster(raster_name, polygon_bound,
>>output_type=tiff) would automagically assemble the correct pieces from
>>the correct tiles and generate a single raster from a set of tiles
>>that are referenced by the single name "raster_name". An insert
>>statement would disaggregate into tiles and store metadata
>>appropriately.
>>
>>    
>>
>Hi Webb,
>
>I agree with your observations on tiling, but I would also like to emphasize 
>the usability of the tiles at the application level, rather than the 
>familiar file-based storage formats such as TIFF. In other words, there 
>should be a get_tile(raster, tile_index_x, tile_index_y) access method as 
>well. Similar to the support of WKT representation of geometries by 
>applications like we currently see in PostGIS-enabled applications, support 
>for direct use of tiles will come if the interface is provided. This will in 
>all likelihood be the most efficient access method.
>
>Cheers,
>Patrick 
>
>
>
>_______________________________________________
>postgis-users mailing list
>postgis-users at postgis.refractions.net
>http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>  
>