[gdal-dev] Re: VRT Derived Bands from Python?

[Antonio Valentino]

Hi Knut-Frode,

Il giorno Fri, 13 May 2011 10:37:25 +0200
Knut-Frode Dagestad <knutfrodesoppel at hotmail.com> ha scritto:

> Hi Even and Antonio,
> 
> Thank you Even for explaining how to make the impossible possible!
> I will explore this option.
>

If you think it is useful I can attach the fake-driver code to the
#3367.
 
>
> The suggestion of Antonio to include a default set of PixelFunctions
> is an excellent idea, as it lowers the threshold for newcomers, like
> me. The proposed standard functions (#3367) should also serve many
> basic needs, and in fact, most of mine.

A relevant thread about this topic is 

http://lists.osgeo.org/pipermail/gdal-dev/2010-January/023262.html
http://lists.osgeo.org/pipermail/gdal-dev/2010-February/023336.html

but probably you have already read it.

It would be interesting to know which function you would like to be
added to the base set.
In the above mentioned thread a user asked for a "abs(a-b)"
pixel-function. Maybe there are other function it worths adding the
basic set.


> On the other hand, I do not see any apparent limitation to how 
> sophisticated the PixelFunctions can be. I am not sure if it is a
> good idea, but I consider the option to put in relatively complex
> algorithms with loops, iterations and inversions. I.e. things that
> are better done in C than in Python.

IMHO the main limitation is the impossibility to pass additional
parameters for pixel functions, see

http://lists.osgeo.org/pipermail/gdal-dev/2009-July/021137.html


Finally I think it would be very nice to have a function like

http://www.pytables.org/docs/manual/ch04.html#ExprClassDescr

in the GDAL python API and/or connected to the VRT format.

Basically PyTables provides a general purpose expression evaluator
that is disk aware and very efficient (using optimized and
threaded numexpr kernels).

Best regards

-- 
Antonio Valentino