[gdal-dev] Map algebra
alex
alexhighviz at hotmail.com
Tue Apr 12 02:47:27 PDT 2016
>-----Original Message-----
>From: gdal-dev [mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of Ari
>Jolma
>Sent: 12 April 2016 07:10
>To: gdal-dev at lists.osgeo.org
>Subject: Re: [gdal-dev] Map algebra
>
>
>11.04.2016, 19:30, alex kirjoitti:
>>
>> The curse of dimensionality comes in at the point, where the above
>> function is called. The method callback is a template function and it
>> needs the datatype of each band that is given to it as an argument. (I
>> see now that I have made also the above function a template function,
>> which may not be needed).
>>
>> In the end, all you need to do that is type specific is to apply the function on
>the pixel (at least in many cases). Would it be an option to only make the pixel
>level function a template, rather than the block level function?
>
>The block-level function is repeated for all methods mainly because
>there are a couple of things that would cause an unnecessary overhead if
>called at each pixel. First, the method return value, if any, is
>initialized at the first call. Second, if the method needs to iterate
>over the whole band several times, that requires initialization etc.
>which is best done at block level (at the beginning of a first and at
>the end of a last block).
I wasn't trying to suggest to do away with the block level stuff, I can see how it makes your code efficient (and more efficient than the row-by-row iteration that I am using). However, I did notice that for many functions this part of the code is generic and does not rely on the template type.
>Also the pixel level operation should be as fast as possible and thus a
>function call in itself would cause overhead - however, using inline
>function might help.
Ok, if pixel-level functions are off the table then I give up. To me one of the major aims of a Map Algebra library would be to make it easy to apply pixel-level functions on raster data (along with other aims to support focal, zonal and global operations).
>Ari
>
More information about the gdal-dev
mailing list