<br><br><div class="gmail_quote">On Mon, Sep 26, 2011 at 8:39 PM, Pierre Racine <span dir="ltr"><<a href="mailto:Pierre.Racine@sbf.ulaval.ca">Pierre.Racine@sbf.ulaval.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
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:<br>
</blockquote><div><br><br>This exists: <br><br>SETOF geomval ST_Intersection(geometry, raster) <br><br>I am not proposing a replacement. I still do not see a:<br><br>raster ST_Intersection(geometry, raster)<br><br>or for that matter:<br>
<br>raster ST_Intersection(geometry, geometry)<br>raster ST_Intersection(raster, geometry)<br>raster ST_Intersection(raster, raster)<br><br>Could you please point any of these out to me? (Resistance is futile!)<br><br> </div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
5) Same for ST_Difference() and ST_Symdifference()<br></blockquote><div><br>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.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
6) Discuss the specs of ST_Union (which I planned as an aggregate).<br></blockquote><div><br>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? <br>
<br>raster ST_Union(raster, raster) or <br>setof geomval ST_Union(raster, setof geomval) or <br>raster ST_Union(geomval, raster)<br><br>to perform the various two-input unions implied by that single statement.<br><br>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.<br>
<br>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 <br><br>
image ST_Union(image1, image2)<br><br>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.<br>
</div></div>