Dear all, I would like to re-open an older discussion. At several points in the last year there has been a discussion of raster algebra / map algebra functionality on this list. There still is an associated RFC by Ari Jolma (https://trac.osgeo.org/gdal/wiki/rfc62_raster_algebra).
The reason to re-open the discussion is that I have recently submitted a C++ library called Blink Raster to OSGeo to be considered as a Community project. The project is hosted on Github (https://github.com/ahhz/raster ). Note that there is already quite some documentation, including main concepts, functions and examples. Blink Raster meets the requirements specified in RFC62: > "The implementation should be data type aware. This may mean code written > with templates. " The main expected use of the library is where the user knows the datatype, and specifies it in a template. > "The implementation should be parallel processing friendly. " The implementation uses expression templates to specify operations on rasters that are lazily evaluated. The interface facilitates evaluating the expression templates only for subrasters. It is therefore a solution that should works well with the split-and-merge approach to parallel processing. > " The implementation should allow a relatively easy to use C++ / C API. This > may mean interface, which does not use templates. " The interface with templates is pretty simple. However, at a performance cost, it is also possible to apply map algebra operations without specifying the data type. > "The implementation should allow arbitrary functions on cell values. I.e., be > extensible by the user." The implementation allows arbitrary functions on cell values > "The implementation should allow focal methods. I.e., methods, where the > value of a cell depends on its neighborhood." The implementation offers square and circular moving window methods for neighbourhoods of pixels and edges (adjacent pixel pairs). This is also extendable by the user and it is relatively straightforward to write your own statistic to be applied in a moving window. This was my original motivation for this library: to be able to easily write efficient moving window based indicators of landscape patterns. With apologies for re-opening a discussion that is only sideways related to GDAL as well as the self-promotion. Since in the end this is about a C++ geo-data abstraction library, I felt it was appropriate. I would appreciate any feedback and ideas for the library. I would also be interested to hear if you think this library addresses a GDAL need. With kind regards, Alex -- Alex Hagen-Zanker _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
