<br><br><div class="gmail_quote">On Thu, Jun 16, 2011 at 9:19 PM, dustymugs <span dir="ltr"><<a href="mailto:dustymugs@gmail.com">dustymugs@gmail.com</a>></span> wrote:<br><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;">
<blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">So in the end you have a very flexible Mapalgebra working on two rasters helping you to implement a bunch of other raster processes and optimized for the very useful case of doing Clips and Unions. In bonus you get some editing functions like ST_SetValues very usefull to implement who knows what...<br>
</blockquote></blockquote><div><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
</blockquote></div>
I'm thinking of taking incremental steps rather than jumping in all the way for a two raster ST_MapAlgebra, as I suspect that this will take significant amount of time to implement correctly.  I can see that ST_Clip, ST_Collect, ST_Union will all lead to ST_MapAlgebra but having milestones allows more functionality to be delivered and consumed in a shorter time-frame.<br>
</blockquote><div><br>I completely agree, and actually I think the structure of the available functions should reflect this. For instance, rather than have many thin wrappers over a single huge do-it-all function like MapAlgebra, I'd prefer to build a complex function (MapAlgebra) from simpler ones (ST_Intersection). <br>
<br>BTW: Bborie, I have been told that we may have some GDAL code lying around the building which could help out with ST_Clip (or ST_Intersection(raster, geometry)). <br></div></div>