[postgis-devel] Raster philosophy in a vector world

[Bryce L Nordgren]

On Mon, Jun 13, 2011 at 7:33 PM, Pierre Racine
<Pierre.Racine at sbf.ulaval.ca>wrote:

> This is effectively one adaptation of ST_Collect()  to the raster world
> that we could decide. What do you do if tiles are actually not regularly
> blocked and disjoint?
>

ST_Collect is supposed to be simple and fast. I'd say just let it error out
if it is used inappropriately. Let a more complicated function like
mapalgebra handle it.


>
> For the rest I must say I have hard time following you... Hard to know when
> you are referring to ST_Union or to ST_Intersection. I would need drawings
> and examples...
>

Story of my life. I think backwards to most people, especially when I'm
thinking into email. :) I took a stab at it here:

https://collab.firelab.org/software/projects/modisfire/wiki/Spatial_Set_Operations_in_PostGIS_Raster


It's a little rough, but I tried to distill the parts that are common to all
the set operations. The example (with pics) is of an intersection operation,
tho. I would have put it on the PostGIS wiki instead of my own, but  I can't
write there.

I realize that the spec I wrote in the wiki are very different from what I
> envisioned two years ago (see my original presentation). Originally I was
> planning that the result of "ST_Intersection(raster, geometry) -> raster"
> would be a one band raster but the spec says that it should return a two
> bands raster. Now I'm a bit lost. Was that just a mistake or was there a
> good reason? I don't remember.
>

Take a look at my wiki page. :)  I can see a one-band raster as a mask, but
if you're populating the resultant raster with values from the source
raster, I don't think a two band raster makes sense. Particularly if it's a
color image with three or four bands. I'd vote for copying all bands into
the result unless the user specifies a particular subset of interesting
bands.


>
> I think the answer for "ST_Intersection(raster, geometry) -> raster" comes
> from "ST_Intersection(raster, raster) -> raster". In this last case you have
> no other choice than returning a two band raster. (Or maybe a set of two
> band mask rasters sharing a common value?) Does this imply that the first
> one should also return two bands?
>

I think the focus of these spatial set operations should be spatial
information, not how to compute values from more than one raster input. When
there's only one raster participating in the operation, we can copy values
from it to the destination, but two-raster operations are going to be a
different story. It will be complex enough to just decide on what the grid
definition of the result should be if the two raster inputs have different
resolutions, are rotated, or (heaven forbid) are in different projections.
Computing values beyond a simple mask (grid cell is included or excluded
from the spatial result) needs to be somewhere else.

Even if we start simple, the complexity of computing grid cell values will
explode, and that complexity shouldn't be in the spatial set operation. :)

Bryce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20110615/a11cf099/attachment.html>