<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi,</p>
<p>Sorry for missing this last month due to holidays.</p>
<p>In fact in my approach I do not want to limit to single pixel
operations but support neighborhood operations too. That is
necessary for watershed analysis for example. Making sure that the
neighborhood is readily available for computations is probably
what is causing the biggest problem for the code. I also have a
callback support. See for example <a
class="moz-txt-link-freetext"
href="https://github.com/ajolma/gdal/blob/trunk/gdal/map_algebra/test.cpp">https://github.com/ajolma/gdal/blob/trunk/gdal/map_algebra/test.cpp</a>
where on the lines 5 to 12 is a callback function.</p>
<p>When I left the code for my extended holidays I was doing
profiling and intended to test another approach for caching. Now
the caching is based on the native GDAL blocks, which is efficient
for going through a single dataset. Since the block may be
different for different datasets this approach may not be the best
when there are more than one dataset. For example the raster
algebra in QGIS uses an approach where the block is the same for
all datasets. That simplifies the code and may be very efficient
as a whole.</p>
<p>I'll be at the code sprint in FOSS4G 2016 and that would be a
good place to discuss the RFC too.<br>
</p>
<p>Best,<br>
</p>
<p>Ari</p>
<br>
<div class="moz-cite-prefix">13.07.2016, 10:09, James Ramm
kirjoitti:<br>
</div>
<blockquote
cite="mid:CAEW=KS76Mk5kab9b7jYR=rh5U7jKVzxLzQoRWnOEm0Eym7exUQ@mail.gmail.com"
type="cite">
<div dir="ltr">Peter,
<div>I think 'Grid Algebra' would be what Ari Jolma is proposing
here: <a moz-do-not-send="true"
href="https://trac.osgeo.org/gdal/wiki/rfc62_raster_algebra"
rel="noreferrer" target="_blank" style="font-size:12.8px">https://trac.osgeo.org/gdal/wiki/rfc62_raster_algebra</a></div>
<div><br>
</div>
<div>As Even pointed out, there is some overlap, though my
proposal is technically very different. </div>
<div>The key differences I see are:</div>
<div><br>
</div>
<div>- Users can submit functions which operate on each sub
window of the raster, rather than an algebraic expression.
This potentially allows for much more complicated algorithms
to be used (e.g. I dont think it would be possible to run a
watershed segmentation with a raster algebra implementation,
or to have algorithms which behave differently depending on
the 'location' within the raster or the values of surrounding
pixels etc etc).</div>
<div><br>
</div>
<div>- Functions can be chained together for a complex
processing toolchain. Some overlap with VRT here, although
again this introduces a little more flexibility. </div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 12 July 2016 at 15:47, Peter Halls <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:p.halls@york.ac.uk" target="_blank">p.halls@york.ac.uk</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>James,<br>
<br>
</div>
in reality, are you not requesting an
implementation of Tomlin's 'Grid Algebra' in GDAL? That
defines the whole range of functions from whole raster
to pixel and has the distinct advantage of being both
published and extremely well known because of other
implementations ... which also provide ready-made
reference bases for the GDAL implementors ...<br>
<br>
</div>
Best wishes,<br>
Peter<br>
</div>
<div class="gmail_extra">
<div>
<div class="h5"><br>
<div class="gmail_quote">On 12 July 2016 at 15:39,
James Ramm <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:jamessramm@gmail.com"
target="_blank">jamessramm@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi Even,
<div><br>
</div>
<div>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'. </div>
<div>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. </div>
<div>I dont think VRT pixel functions allow
this? </div>
<div><br>
</div>
<div>So in that sense I'd see a VRT being 'just'
another potential input data source. </div>
<div><br>
</div>
<div>Perhaps VRT pixel functions could be
expanded to also allow 'window' functions?</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>I see the overlap with raster algebra,
although yes technically very different. </div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 12 July 2016 at
14:55, Even Rouault <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:even.rouault@spatialys.com"
target="_blank">even.rouault@spatialys.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">James,<br>
<br>
There's some intersection with Ari's
proposal :<br>
<a moz-do-not-send="true"
href="https://trac.osgeo.org/gdal/wiki/rfc62_raster_algebra"
rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/wiki/rfc62_raster_algebra</a>
. At least regarding the<br>
overall purposes, since technically this is
quite different.<br>
<br>
Actually what you propose is very close to
the existing VRT pixel functions of<br>
derived bands. See "Using Derived Bands" in<br>
<a moz-do-not-send="true"
href="http://www.gdal.org/gdal_vrttut.html"
rel="noreferrer" target="_blank">http://www.gdal.org/gdal_vrttut.html</a>
. In the last days, we've merged<br>
Antonio's work regarding a predefined set of
pixel functions.<br>
Perhaps some extension to allow passing user
parameters to the pixel func<br>
could be useful. It is possible to use pixel
functions from Python as shown in<br>
<a moz-do-not-send="true"
href="https://github.com/OSGeo/gdal/blob/trunk/autotest/gcore/testnonboundtoswig.py#L303"
rel="noreferrer" target="_blank">https://github.com/OSGeo/gdal/blob/trunk/autotest/gcore/testnonboundtoswig.py#L303</a><br>
although this is a bit ugly as it uses
ctypes and not SWIG. But should be<br>
possible through SWIG by introducing proper
types similarly to what is done<br>
for the progress functions or error handler
functions.<br>
<br>
Even<br>
<div>
<div><br>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>