<br><br><div class="gmail_quote">On Mon, Jun 13, 2011 at 7:33 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;">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?<br>
</blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<br>
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...<br></blockquote><div><br>Story of my life. I think backwards to most people, especially when I'm thinking into email. :) I took a stab at it here: <br>
<br><a href="https://collab.firelab.org/software/projects/modisfire/wiki/Spatial_Set_Operations_in_PostGIS_Raster">https://collab.firelab.org/software/projects/modisfire/wiki/Spatial_Set_Operations_in_PostGIS_Raster</a>  <br>
<br>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.<br>
<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">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.<br>
</blockquote><div><br>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.<br>
 </div></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
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?<br>
</blockquote><div><br>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.<br>
<br>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. :) <br><br>Bryce<br></div></div>