[gdal-dev] VRT derived band pixel functions written in Python

[Even Rouault]

Le lundi 12 septembre 2016 23:38:41, James Ramm a écrit :
> Incredible!!!!
> Really cool initiative.
> 
> I had a play around and wanted a way to be able to write the pixel function
> in a 'stand alone' python module and generate the VRT from it. This would
> allow independent testing and easier maintenance of the python code. It is
> fairly easy using lxml to build up the VRT dynamically:
> 
> https://github.com/JamesRamm/gdal_pixel_functions
> 
> In the example I more-or-less recreate the hillshade example Even posted,
> although there is a lot of functionality missing from the VRT-builder
> still, so some nodes are not present.
> It would be quite easy therefore, to expand this to a sort of GDAL
> 'algorithms library' (I think it can wholesale replace what I had tried
> here: https://github.com/JamesRamm/GeoAlg).

a "-of VRT" option in current gdal_calc.py could also be cool (at least for 
simple one line operations)

Programmatic creation of VRT derived band, with the previous scope (ie calling 
a native registered pixel function), already existed. See 
https://github.com/OSGeo/gdal/blob/trunk/autotest/gdrivers/vrtderived.py#L175
I didn't extend for now the VRTDataset::AddBand implementation to set the new 
elements needed for the Python stuff, but that would certainly be doable.

> 
> One thing I would note (if I understand correctly) is that you have
> specified any "import" statement as unsafe except numpy/math and numba? It
> might be better to either allow imports or not allow them at all (unless
> the config option is set) as I don't see why those libraries would be any
> more or any less 'safe' than another library...e.g. another standard
> library module.

Well, the idea was that those modules should only do math stuff and not 
interact with the rest of the system (contrary to 'os', 'system' and the like) 
But is in the numpy case, it is not actually true since it has I/O methods, 
hence my naive attempt to blacklist those by names.

> 
> I would agree with Sean and remove 'IF_SAFE' and leave it entirely to the
> users discretion. 

That's what I've done (see previous message)

> Many users who are working with their own local data will
> likely have no problems about just setting it to 'YES' and I imagine users
> for whom it would be a probably might already have their own rules on what
> constitutes 'safe'?
> 
> On a sidenote - does this new functionality overlap considerably with the
> gdal map algebra project?

Indeed. I think there might be several incarnations of such capability and I'm 
not sure we can come up with a single one that will satisfy all needs and 
constraints. The VRT way has some use cases where it shines (on-the-fly 
computation of a region of interest. easy integration with upper levels in the 
stack: QGIS, MapServer, etc...), whereas you could imagine something else 
efficient in doing whole raster processing with parallelism etc... 

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com