[gdal-dev] Map Algebra revisited

Tue Jan 23 03:23:14 PST 2018

Hi Ari,

Even if the development of the code for RFC62 has turned out to be more complex than initially envisioned, I think it remains a good diagnosis of functionality that is missing in GDAL. The use of multiprocessing in  Perl is very interesting, however I don't think it addresses the issues you originally raised in RFC62. If only, because it is not C++.

I think there is scope for a more abstract interface on top of GDALRasterBand that makes it easier to write algorithms on raster data in C++. It would benefit users of GDAL (I suppose especially research oriented users). It might also benefit GDAL itself, because the issues of data access and algorithm can be better separated. For instance, the implementation of the Euclidean distance transform in gdalproximity.cpp or the raster statistics computation in gdalrasterband.cpp could both benefit from such conceptual tidying up. Having a clearer separation of data access and algorithm might even illuminate the path towards parallel processing for those and other tasks.

Kind regards, Alex
--
Alex Hagen-Zanker
Blink Raster: https://github.com/ahhz/raster

From: gdal-dev [mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of Ari Jolma
Sent: 23 January 2018 08:25
To: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] Map Algebra revisited

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<mailto: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/41909e5c/attachment-0001.html>