[gdal-dev] Map Algebra revisited

[Ari Jolma]

Alex,

Thanks for the information. I wrote the RFC and I wrote the C++ add-on 
that's linked to the RFC. However, in the end I run out of time with 
that code. Later also Mario Roy took up the challenge of multiprocessing 
raster operations with Perl GDAL and got good results(1).

Perhaps the appropriate thing would be to start a GDAL raster 
processing/algebra page on the GDAL Wiki and write there about 
solutions. The RFC should direct to that page.

Best,

Ari

1) https://gist.github.com/marioroy


Alex HighViz kirjoitti 22.01.2018 klo 17:40:
>
> 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
>
> p.s. I had to resend this email from a second email address, due to 
> the following: https://trac.osgeo.org/osgeo/ticket/2087
>
> --
>
> Alex Hagen-Zanker
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20180123/c15dc6dc/attachment.html>