[postgis-devel] gen2 raster iterator tutorial

[Bryce L Nordgren]

On Wed, Sep 28, 2011 at 9:49 AM, Pierre Racine
<Pierre.Racine at sbf.ulaval.ca>wrote:

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

Process, yes; return, no. The "iterator" in iterator iterates over the
returned grid cells. It is applicable to anything returning raster.


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

I really need to pry your mind away from the details of user level apis.
Here is what you're getting:

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.

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.

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.

 [api crap deleted]
>

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

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.

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.

Bryce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20110929/7ef7cb1a/attachment.html>