[postgis-devel] gen2 raster iterator tutorial

[Bryce L Nordgren]

On Mon, Sep 26, 2011 at 8:39 PM, Pierre Racine
<Pierre.Racine at sbf.ulaval.ca>wrote:

>
> Since you are proposing to use this iterator to replace some things which
> are already working pretty well (this is one reason for "such resistance")
> like ST_Intersection(geometry, raster) and the one raster version of
> ST_MapAlgebra(), or write functions which are planned to be written
> differently (ST_Intersection, ST_Difference, ST_Symdifference planned as
> wrappers around the two rasters mapalgebra), I would propose that you:
>


This exists:

SETOF geomval ST_Intersection(geometry, raster)

I am not proposing a replacement. I still do not see a:

raster ST_Intersection(geometry, raster)

or for that matter:

raster ST_Intersection(geometry, geometry)
raster ST_Intersection(raster, geometry)
raster ST_Intersection(raster, raster)

Could you please point any of these out to me? (Resistance is futile!)



> 5) Same for ST_Difference() and ST_Symdifference()
>

It does not seem as if there are a whole lot of options here. In fact, it
would be counterintuitive to do anything other than copy the value from the
only input which has a value.


> 6) Discuss the specs of ST_Union (which I planned as an aggregate).
>

Well, why would that need to change? Are you saying that ST_Union as an
aggregate function is incompatible with one which merely takes two inputs?

raster ST_Union(raster, raster) or
setof geomval ST_Union(raster, setof geomval) or
raster ST_Union(geomval, raster)

to perform the various two-input unions implied by that single statement.

I'll write up the specs for all the initial implementations when I make a
ticket for the gen2 iterator. They're going to be batched up, as I'm no
longer going to have the time to keep a bunch of codependent tickets aligned
with trunk. On the plus side, changing how any of these user-exposed
functions generate values is well-isolated and borders on the trivial. The
vast majority of the work was behind-the-scenes. That's one of the reasons
I'm none too concerned about the final user-visible specs. It doesn't really
matter what you want to return, as the return value doesn't affect the
design.

One bit of heinous revelation, however: the functions which perform these
spatial operations between two individual tiles are relatively
straightforward. However, just think for a second about trying to do an

image ST_Union(image1, image2)

where each of the "image"s is composed of multiple tiles. This is,
conceptually, what a table of tiles is; and it is, conceptually, what many
people (myself included) are going to want to be able to do. I'm currently
blocking all thoughts of this as best I can. Perhaps this is the role of the
aggregate function described above, but my spidey sense is tingling. I know
there's more to it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20110927/6498bcbb/attachment.html>