[postgis-devel] gen2 raster iterator tutorial

[Bryce L Nordgren]

On Fri, Sep 30, 2011 at 7:29 AM, Pierre Racine
<Pierre.Racine at sbf.ulaval.ca>wrote:

> Ok Bryce. So I will invite people who have the need and time to implement
> new SQL functions to consider using your iterator. Hopefully they will have
> the time to understand it and they will have the faith that this is the way
> to go. I thought it was your responsibility to demonstrate its usefulness,
> not just in theory but also in practice but I understand that you have more
> important things to do. Unfortunately me too.
>

You seem to hear only what you want to hear. Yes I will discuss the APIs,
but separately. Usefulness in theory was demonstrated on the wiki page.
Usefulness in practice was demonstrated with the existing tutorial. And I
offered to write you another one on a different topic, which most people
would take as signs of a continuing interest. It's positively bizarre that
you interpreted that in the way that you did. I'm putting the brakes on
because you're not on the right wavelength yet.

It is my responsibility to make sure that you (project leader) understand at
least the intended function and the overall approach. If you want to know
the details, you can plunge in and I can point you towards whatever you're
interested in. I'm not so concerned that you have a mastery of all facets of
this, but you should have a good conceptual grasp of how this could affect
future choices about how to implement whatever function signature pops to
mind next month or two years from now.

Intended function: provide a framework which supports the development of
functions which return a raster
Approach: using best practices (encapsulation, separation of concerns, and
limited polymorphism), create many small islands of functionality which
perform common tasks (reprojection, expression evaluation, etc.), assembling
them into a variety of processing chains which accomplish the desired tasks
What does this replace: nothing.
How does this impact the user-visible API: it doesn't
What plans does this alter: implementing all raster returning functions by
calling one of two giant mapalgebra (1 raster and 2 raster) functions which
share no code, each of which contains all the functionality required by any
potential caller.
What benefits can be expected: faster development, easier maintenance, fewer
bugs, creation of new functions without the danger of breaking existing ones

Go ahead and ask me why I didn't just say that before. Watch my head
explode.

I can work with Bborie to create the two raster version of mapalgebra using
this framework if he likes. Maybe he can teach me about the strange looking
testing framework we've got here...(I've only used junit and pyunit, which
are essentially the same thing). For that matter, I'm also going to have to
learn how to query the database from server side C code. Thus far I eeeked
by using proj4, geos and gdal. This will be something new. I'm off at a
workshop most of next week, but after that I can work this in.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20110930/93192dbc/attachment.html>