[postgis-devel] [WKT Raster] Regular blocking in gdal2wktraster.py

[Chris Hodgson]

I think it is critical that one "coverage" aka collection of raster 
tiles cannot have overlaps. A coverage can only have one value per band 
per point in space. Otherwise there is no way to do analysis on the 
raster - which value do you use? I think the fact that there is overlaps 
is a clue that they should be defined as separate coverages.

The use case for overlapping rasters that comes to my mind is the case 
of dynamic mosaicking based on resolution or other parameters. In this 
case you have an 1-meter orthophoto which overlaps with a 10-meter 
satellite image. Which image gets used for the overlapping region is 
based on the resolution of the request, but for the non-overlapping 
parts it is simple. I think this use case would be two separate 
coverages, stored within the same table, and ideally using the same 
blocking (aligned).

I envision functions to merge multiple overlapping rasters such as this, 
based on some parameters, into a separate, new coverage - ie. building 
the mosaic. One day! :)

Chris

Pierre Racine wrote:
> I now better see your point: What if regular_blocking is set to false but still, tiles are not overlapping and are then proper for such an application?
>
> Good question.
>
> Probably we should split the regular_blocking flag in three:
>
> -same_size: tiles are all the same size and blocksize_x == blocksize_y
> -overlap: at least two tiles overlaps
> -firsttileupperleft: the tiles are ordered in the table as they should be ordered in a file. (I'm not sure this can be garanteed by a select statement)
>
> (Is this sufficient?)
>
> if same_size && ! overlap && firsttileupperleft then regular_blocking = true
>
> Really, I find this regular_blocking constraint, constraining :-( :-)
>
> Pierre
>
>   
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net [mailto:postgis-devel-
>> bounces at postgis.refractions.net] On Behalf Of Pierre Racine
>> Sent: 27 mars 2009 14:19
>> To: PostGIS Development Discussion
>> Subject: RE: [postgis-devel] [WKT Raster] Regular blocking in gdal2wktraster.py
>>
>> Well, if your application does not support display of overlapping objects then you should not store
>> overlapping tiles in your db... As if your application does not supports tiff then you should probably
>> not store your data in tiff... It is not because some applications do not supports fonctionalities
>> that we most stop developping functionalities. Overlapping rasters exist and they will always exist.
>> Most desktop applications are able to display overlapping rasters. Your application would take for
>> granted (checking first with SELECT regular_blocking FROM raster_columns WHERE name="mycoverage") that
>> tiles are not overlapping.
>>
>> Pierre
>>
>>     
>>> -----Original Message-----
>>> From: postgis-devel-bounces at postgis.refractions.net [mailto:postgis-devel-
>>> bounces at postgis.refractions.net] On Behalf Of Mateusz Loskot
>>> Sent: 27 mars 2009 14:03
>>> To: PostGIS Development Discussion
>>> Subject: RE: [postgis-devel] [WKT Raster] Regular blocking in gdal2wktraster.py
>>>
>>> Pierre Racine wrote:
>>>       
>>>> Does applications like Google Earth profit from regular blocking?
>>>> Why is it better to query for
>>>> regular blocked tiles in chunks than just querying for tiles with a
>>>> proper SQL query and display them as independent raster forming a
>>>> layer? This is the way vector layer works and nobody complains.
>>>>         
>>> There is coverage composed of two overlapping tiles
>>> (size of tiles does not matter now):
>>>
>>> +--------+
>>> |        |
>>> |  +-----|------+
>>> |  |     |      |
>>> |  |     |      |
>>> +--+-----+      |
>>>   |            |
>>>   +------------+
>>>
>>> (I hope my ASCII-art format is preserved)
>>>
>>> How do you render it in a basic client (desktop, web, whatever)?
>>>
>>> --
>>> Mateusz Loskot
>>> Senior Programmer, Cadcorp
>>> http://www.cadcorp.com
>>>       
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>