[gdal-dev] Map algebra

[Ari Jolma]

02.04.2016, 16:08, Even Rouault kirjoitti:
> .
>>> - there seems to be a block cache mechanism. What is it for ? How does
>>> that work ?
>> In the block loop (looping through all blocks in a band) at each step
>> the cache is checked for block(s) that are needed (if focal distance is
>>
>>   > 0 then more than one block may be needed) and which are not needed.
>>
>> Then blocks are read and written/discarded.
> Isn't there some duplication with GDAL own's block cache ? Perhaps I'm just
> confusion by the proximity of the naming. I didn't study your code closely.

The GDAL RasterBlock class and block cache seems to me to be something 
different. In my code I simply use ReadBlock and WriteBlock methods of 
the RasterBand class to get access to the needed blocks and write them 
to the disk if a band is being modified. GDAL block cache operates below 
ReadBlock and WriteBlock methods.

The code is basically what is in the GDALRasterBand::ReadBlock 
documentation but extended for two bands and divided into a few 
functions plus syntactic sugar added with macros.

Ari


>
>>> - there is some overlap/connection with the pixel functions of VRT ( see
>>> "Using Derived Bands" of http://gdal.org/gdal_vrttut.html).
>> ok
>>
>> Thanks for the comments!
>>
>> Ari
>>
>>>> The C code is of course not this nice but it is not very far from this.
>>>> All the basic four method types I mention below are implemented and
>>>> adding new methods is not very difficult. The code makes heavy use of
>>>> templates and macros in an attempt for versatility (GDAL rasters can
>>>> have many datatypes) and easiness to write methods in a few lines of
>>>> code. The whole set of code is now ~2500 lines but it creates rather
>>>> large executables due to templates. The code is C++ but the API is C
>>>> like, I've so far done no changes to existing GDAL code because of this.
>>>>
>>>> As written below, the code works on two levels of x,y loops: the blocks
>>>> within a band, which is generic and cells within a block, which is
>>>> separate for each method. The methods work on line by line (no recursion
>>>> etc.) and thus for example the fill_depressions is not optimal but
>>>> instead very simple. Also, very large rasters can be processed.
>>>>
>>>> I think this may be somewhat similar thing in relation to GDAL as the
>>>> network support, so it could be a thing to add to the library if wished.
>>>>
>>>> I've added RFC 62 "raster algebra" to spark discussion.
>>>>
>>>> Ari
>>>>
>>>> 20.03.2016, 10:21, Ari Jolma kirjoitti:
>>>>> Folks,
>>>>>
>>>>> I played around a bit with the map algebra idea and came up with
>>>>> something that could work nicely as a plugin. The initial code is at
>>>>> https://github.com/ajolma/gdal/tree/trunk/gdal/map_algebra
>>>>>
>>>>> The idea is based on processing raster bands block by block and
>>>>> calling a given function on each block. Using macros and templates the
>>>>> code should be rather nice and manageable even when supporting
>>>>> multiple data types for raster cells.
>>>>>
>>>>> Further, the idea is to support three kinds of map algebra methods,
>>>>> mostly working on a raster band in-place.
>>>>>
>>>>> 1) Simple ones, which do not take any arguments beyond the raster band
>>>>> itself, examples are functions like log, sin, rand.
>>>>>
>>>>> 2) Those which take one non-spatial argument. The argument can be a
>>>>> scalar like a number, or more complex like a reclassifier.
>>>>>
>>>>> 3) Those which operate on two rasters. Examples are summation of
>>>>> rasters and computing flow directions on a DEM. The latter is a bit
>>>>> more complex since it is a focal method and requires a 3 x 3 matrix of
>>>>> blocks from the other operand raster.
>>>>>
>>>>> Maybe a fourth kind of methods are those which compute something from
>>>>> a raster.
>>>>>
>>>>> This would lead to four functions in the C API and raster band methods
>>>>> in the bindings.
>>>>>
>>>>> Comments are welcome, the initial code base contains a small demo
>>>>> program. Eventually, if this works, I'll make a RFC from this.
>>>>>
>>>>> Ari
>>>> _______________________________________________
>>>> gdal-dev mailing list
>>>> gdal-dev at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev