g] On Behalf Of Ari Jolma
Sent: 23 January 2018 08:25
To: gdal-dev@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
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 app
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 reaso
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 t
Folks,
Some updates on the RFC 62.
Working on the code, I've managed to rewrite the C++ API almost
completely OO. There is a need for only a bootstrap function, which
constructs a new band object from a regular GDALRasterBand. The map
algebra methods are methods of this object. The new band c
12.04.2016, 12:47, alex kirjoitti:
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 an
>-Original Message-
>From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Ari
>Jolma
>Sent: 12 April 2016 07:10
>To: gdal-dev@lists.osgeo.org
>Subject: Re: [gdal-dev] Map algebra
>
>
>11.04.2016, 19:30, alex kirjoitti:
>>
>> The
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 t
>-Original Message-
>From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Ari
>Jolma
>Sent: 10 April 2016 09:20
>To: gdal-dev@lists.osgeo.org
>Subject: Re: [gdal-dev] Map algebra
>
>08.04.2016, 19:28, Gregory, Matthew kirjoitti:
>> I would w
08.04.2016, 19:28, Gregory, Matthew kirjoitti:
I would want any map algebra library to handle three types of issues when
dealing with raster data:
1) Handling mask or nodata values (e.g. an analysis mask should be
able to be set on any algebra operation that retains or combines
n
> -Original Message-
> From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of
> Gregory, Matthew
> Sent: 08 April 2016 17:29
> To: gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] Map algebra
>
> Hi all,
>
> Alex wrote:
> > What e
Hi all,
Alex wrote:
> What exactly do you mean by Map Algebra? I understand it to cover the
> following:
>
> 1. Local operations: pixel-by-pixel operations on raster bands.
> 2. Focal operations: operations that calculate an indicator for each
> pixel based on the values in surrounding pixels
> 3
> -Original Message-
> From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of
> Ari Jolma
> Sent: 08 April 2016 07:05
> To: gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] Map algebra
>
> 08.04.2016, 02:21, alex kirjoitti:
> >> That is
08.04.2016, 02:21, alex kirjoitti:
That is one aspect, yes. However, so far I've considered only operations on one
or two bands at time. Operations on more than two can of course be dissolved
into a series of operations with max two at a time.
That will often be possible, but not always. For ins
>
> That is one aspect, yes. However, so far I've considered only operations on
> one
> or two bands at time. Operations on more than two can of course be dissolved
> into a series of operations with max two at a time.
That will often be possible, but not always. For instance how would you
diss
sage-
From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Ari
Jolma
Sent: 01 April 2016 09:39
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Map algebra
I've got this into a rather nice working shape. The code needs to be
reorganized (it is now, horror, all in hea
d only once that is done and dusted, consider the
map algebra on top of it.
Kind regards, Alex
(sorry for the self-promotion)
>-Original Message-
>From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Ari
>Jolma
>Sent: 01 April 2016 09:39
>To: gdal-dev@lists.
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
02.04.2016, 16:08, Even Rouault kirjoitti:
- Are the methods handling 2 bands able to deal with different block
sizes ?
Yes, the band size needs to be the same
Not sure to understand your answer: my question was rather about block sizes.
I forgot a "however": Yes, the block sizes can differ
see also rasdaman with its n-D raster query language based on Array Algebra,
which effectively is the basis for the forthcoming ISO Array SQL standard:
http://www.rasdaman.org
publications:
http://www.faculty.jacobs-university.de/pbaumann/iu-bremen.de_pbaumann//pubs.php
cheers,
Peter
On 04/02/20
Le samedi 02 avril 2016 14:48:15, Ari Jolma a écrit :
> 02.04.2016, 15:15, Even Rouault kirjoitti:
> > A few thoughts and questions :
> > - I guess what would be cool from the perspective of a C++ user is to be
> > really to write the above pseudo code with C++ operator overload when
> > appropriat
02.04.2016, 15:15, Even Rouault kirjoitti:
A few thoughts and questions :
- I guess what would be cool from the perspective of a C++ user is to be
really to write the above pseudo code with C++ operator overload when
appropriate ! A += B, A.min(B), min_A= A.min(), etc...
Operator overloading i
Le vendredi 01 avril 2016 10:38:48, Ari Jolma a écrit :
> I've got this into a rather nice working shape. The code needs to be
> reorganized (it is now, horror, all in header files) but that's another
> thing.
From the perspective of people wanting to use the core mechanisms to extend
with their
I've got this into a rather nice working shape. The code needs to be
reorganized (it is now, horror, all in header files) but that's another
thing.
I've so far built this around a basic DEM catchment analysis workflow.
It includes many kinds of steps so it is a pretty good benchmark. In
pseud
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
25 matches
Mail list logo
