<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;
mso-fareast-language:EN-US;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;
mso-fareast-language:EN-US;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;
mso-fareast-language:EN-GB;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;
mso-fareast-language:EN-US;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-GB" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Hi Ari,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">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++.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Kind regards, Alex<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">--<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Alex Hagen-Zanker<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Blink Raster: <a href="https://github.com/ahhz/raster">
https://github.com/ahhz/raster</a> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="color:windowtext;mso-fareast-language:EN-GB">From:</span></b><span lang="EN-US" style="color:windowtext;mso-fareast-language:EN-GB"> gdal-dev [mailto:gdal-dev-bounces@lists.osgeo.org]
<b>On Behalf Of </b>Ari Jolma<br>
<b>Sent:</b> 23 January 2018 08:25<br>
<b>To:</b> gdal-dev@lists.osgeo.org<br>
<b>Subject:</b> Re: [gdal-dev] Map Algebra revisited<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>Alex,<span style="font-size:12.0pt;mso-fareast-language:EN-GB"><o:p></o:p></span></p>
<p>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).<o:p></o:p></p>
<p>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.<o:p></o:p></p>
<p>Best,<o:p></o:p></p>
<p>Ari<o:p></o:p></p>
<p>1) <a href="https://gist.github.com/marioroy">https://gist.github.com/marioroy</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Alex HighViz kirjoitti 22.01.2018 klo 17:40:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoPlainText">Dear all, <o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">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 (<a href="https://trac.osgeo.org/gdal/wiki/rfc62_raster_algebra">https://trac.osgeo.org/gdal/wiki/rfc62_raster_algebra</a>).<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">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 (<a href="https://github.com/ahhz/raster">https://github.com/ahhz/raster</a>
). Note that there is already quite some documentation, including main concepts, functions and examples.
<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">Blink Raster meets the requirements specified in RFC62:<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">> "The implementation should be data type aware. This may mean code written with templates. "<o:p></o:p></p>
<p class="MsoPlainText">The main expected use of the library is where the user knows the datatype, and specifies it in a template.<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">> "The implementation should be parallel processing friendly. "<o:p></o:p></p>
<p class="MsoPlainText">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.<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">> " The implementation should allow a relatively easy to use C++ / C API. This may mean interface, which does not use templates. "<o:p></o:p></p>
<p class="MsoPlainText">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.<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">> "The implementation should allow arbitrary functions on cell values. I.e., be extensible by the user."<o:p></o:p></p>
<p class="MsoPlainText">The implementation allows arbitrary functions on cell values<o:p></o:p></p>
<p class="MsoPlainText">> "The implementation should allow focal methods. I.e., methods, where the value of a cell depends on its neighborhood."
<o:p></o:p></p>
<p class="MsoPlainText">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.<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">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.
<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">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.
<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">With kind regards, Alex<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">p.s. I had to resend this email from a second email address, due to the following: <a href="https://trac.osgeo.org/osgeo/ticket/2087">https://trac.osgeo.org/osgeo/ticket/2087</a><o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">--<o:p></o:p></p>
<p class="MsoPlainText">Alex Hagen-Zanker<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;mso-fareast-language:EN-GB"><br>
<br>
<br>
<o:p></o:p></span></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>gdal-dev mailing list<o:p></o:p></pre>
<pre><a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><o:p></o:p></pre>
<pre><a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;mso-fareast-language:EN-GB"><o:p> </o:p></span></p>
</div>
</body>
</html>