[postgis-devel] gen2 raster iterator tutorial

Pierre Racine Pierre.Racine at sbf.ulaval.ca
Fri Sep 30 06:29:52 PDT 2011


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.

Bborie is going to work on the two rasters version of MapAlgebra very soon, we will see what he choose.

Pierre

> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net [mailto:postgis-devel-
> bounces at postgis.refractions.net] On Behalf Of Bryce L Nordgren
> Sent: Thursday, September 29, 2011 10:08 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] gen2 raster iterator tutorial
> 
> 
> 
> 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
> 
> 
> 




More information about the postgis-devel mailing list