Le mardi 12 juillet 2016 16:39:34, James Ramm a écrit : > Hi Even, > > The difference I see with pixel functions is that, as far as I understand, > the pixel function is applied per pixel, so there is no possibility of e.g. > the pixel buffer when have the function apply to 'blocks'. > I may be way off, but many of the algorithms we deal with require some kind > of neighbourhood search - a polygonise algorithm or flow direction > algorithm being good examples. > I dont think VRT pixel functions allow this?
True, they don't. Although there's the KernelFilteredSource that is close > > So in that sense I'd see a VRT being 'just' another potential input data > source. > > Perhaps VRT pixel functions could be expanded to also allow 'window' > functions? Would make sense > > A downside is it requires creating a VRT even when you only want to apply a > such a function to a single dataset. Small effort, but still a bit more > than throwing in any GDALDataset to be processed. You could have an helper function to create the VRT dataset from the input dataset, the processing function and its parameters. A bit similarly to what Julien is doing in https://github.com/OSGeo/gdal/pull/142/files#diff-0c9bf560508edf2453cd2f776d72f905R121 -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev