[postgis-devel] gen2 raster iterator tutorial

[Pierre Racine]

> This exists:
> 
> SETOF geomval ST_Intersection(geometry, raster)
> 
> I am not proposing a replacement. 

I had in mind that the iterator could also process geometries...

>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!)

Then raster ST_Intersection(geometry, raster) would be nice as a replacement for 1) but maybe a rewrite of the one raster version of ST_MapAlgebra would even be nicer (this is 2) ).

There are some specification already written for ST_Intersection(geometry, val, raster) ->raster if you want to discuss them. The approach is not geometry as a mask though but as a geomval.

> 
> 	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.

This is true for ST_Difference() and ST_Symdifference() but what about ST_Intersection(geometry, val, raster)? It is planned to return two bands (actually all the bands from the raster plus one for the geomval)...

I also planned an extra option to ST_Intersection(geometry, val, raster) to return only the with value extent. A way to "trim" out lots of generated nodata values. This could be nice with ST_Difference() and ST_Symdifference() also.

> 	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.

If the goal is to merge two mutually exclusive coverages then the right way to do it is using the UNION SQL clause between two SELECT statements:

SELECT * FROM cov1
UNION 
SLEECT * FROM cov2

If the two coverages are not mutually exclusive (they overlap) then you might want to use the UNION SQL clause to first make a single table and then to use ST_Union to blend everything together.

If the goal is to form a two band coverage from two single band ones, then I would instead use ST_AddBand().

ST_Union must be used only when you want to merge (or blend) tiles together (maybe only some) from a single table. In this case it must be an aggregate. If they don't overlap they just merge. If they overlap, they blend according to the expression rule passed. For me it is a kind of MapAlgebra acting on a stack of raster.

I don't think there is much use for the PostGIS two geometry ST_Union()... But who knows...

My concern about all those ST_Intersection(), ST_Difference(), ST_SymDifference(), ST_Union() is more if we want them to accept multiband rasters. For now they are planned to accept only one band, but if we make them accept many bands, what should the result be?

So in the end what do you propose? No plan? No roadmap? No deal?

Pierre