<br><br><div class="gmail_quote">On Wed, Sep 28, 2011 at 9:49 AM, 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;">
<div class="im">> This exists:<br>
><br>
> SETOF geomval ST_Intersection(geometry, raster)<br>
><br>
> I am not proposing a replacement.<br>
<br>
</div>I had in mind that the iterator could also process geometries...<br></blockquote><div><br>Process, yes; return, no. The "iterator" in iterator iterates over the returned grid cells. It is applicable to anything returning raster.<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;">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) ).<br>
</blockquote><div><br>I really need to pry your mind away from the details of user level apis. Here is what you're getting:<br><br>Porting ST_mapalgebra to C is nigh unto trivial because of the presense of the iterator.  ST_mapalgebra can reuse the iterator. It can reuse the projection code. It can reuse the code to wrap a raster input or it can reuse the code to wrap a geometry. But wait, there's more: for a limited time only, the one raster and two raster versions of st_mapalgebra can share all of this code. For the low low price of writing an (EVALUATOR *) implementation you can have a clean, maintainable, well designed C version of ST_mapalgebra. You can do this now, with the code on github. No imagination required. <br>
<br>Here's my problem: if I do it for you, you'll never catch on. There will never be an informed discussion of this contribution on the list because no one bothered to kick the tires on the framework. There will be only a myopic fixation on the stupid user level api examples I chose...and a completely false connotation that if the examples are not appealing, well there's certainly nothing worth salvaging, as it can clearly only produce disagreeable examples. <br>
<br>If I write a tutorial on the wiki which covers how to write an "EVALUATOR", will that be enough to get your mind out of the user level api rut?  While this may seem like I'm being needy, you'll never be able to make an informed decision about accepting/rejecting/suggesting-changes-to this framework if you resist becoming informed. Cowboy up.<br>
</div><div><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote"> [api crap deleted] <br></blockquote><br><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 what do you propose? No plan? No roadmap? No deal?<br></blockquote><br>If you define the design and implementation of a framework which can let you extend its functionality using plugins to implement whatever function signature you want (as long as it returns raster)  as "no plan, no roadmap", you really can't see the forest for all the trees. My revised proposal is on the wiki. It's in UML, and it has explanatory text. The implementation is on github. There's a tutorial on how to string together the pieces to implement a function. I'm running out of tools to communicate with you, because none of them have anything to do with a user-level sql api, and that's all you want to hear.<br>
<br>There is a time and a place for user level api details. We can separately discuss function signatures if you would like, as the framework is probably ready to be put to use. (The framework is written but I need to exercise it and test it.) But function signatures are quite a different animal.  Mixing that discussion in with this discussion isn't helping anyone.<br>
<br>Bryce<br><br><br><br></div></div>