Hi,
While work is ongoing concerning improving r.to.vect performance [1], I am looking at the possibility of creating an r.zonal.geometry module which would calculate a series of form statistics for raster zones (aka clumps). I would begin simply by trying to replicate the v.to.db statistics, i.e. area and perimeter, with compactness and fractal dimension derived from the two former.
Area calculation is quite simple (and already exists, for example, in r.stats.zonal with the count method). However, perimeter is a bit more complicated. My current idea is to 'simply' fetch raster info into a SEG structure and to check for each pixel whether the upper, lower, left and right neighbor has the same cat value as the current pixel. For each neighbor where this is not the case, I add one pixel edge to the total zonal perimeter.
Does this sound like the correct approach. Is there some already existing code that I don't know about that already does this ?
Just trying to avoid reinventing the wheel.
My current motivation is to allow a complete OBIA toolchain without going through vectorization at any point. At this stage, both i.segment.stats and v.area.stats require the vectorization of raster zones for shape statistics which makes the process very slow.
Moritz
[1] https://trac.osgeo.org/grass/ticket/2045
On Mon, Jun 20, 2016 at 6:40 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
Hi,
While work is ongoing concerning improving r.to.vect performance [1], I am
looking at the possibility of creating an r.zonal.geometry module which
would calculate a series of form statistics for raster zones (aka clumps). I
would begin simply by trying to replicate the v.to.db statistics, i.e. area
and perimeter, with compactness and fractal dimension derived from the two
former.
Area calculation is quite simple (and already exists, for example, in
r.stats.zonal with the count method). However, perimeter is a bit more
complicated. My current idea is to 'simply' fetch raster info into a SEG
structure and to check for each pixel whether the upper, lower, left and
right neighbor has the same cat value as the current pixel. For each
neighbor where this is not the case, I add one pixel edge to the total zonal
perimeter.
For raster-based perimeter calculation, you do not need a SEG
structure. Instead, you could use a 2x2 moving window and compare top
right - bottom right and bottom left - bottom right. Simply have two
rows at a time accessible. Whenever a pair is different, increment the
perimeter of each member of the comparison that is not NULL. You would
need to pad the region with a NULL row on top and bottom and a NULL
column to the left and right. This works only with unique
cluster/clump IDs and not with classes. Do you want to obtain any
other parameters than area size and compactness? Another one might be
smoothness = perimeter of the cluster / perimeter of the cluster's
bounding box.
HTH,
Markus M
Does this sound like the correct approach. Is there some already existing
code that I don't know about that already does this ?
Just trying to avoid reinventing the wheel.
My current motivation is to allow a complete OBIA toolchain without going
through vectorization at any point. At this stage, both i.segment.stats and
v.area.stats require the vectorization of raster zones for shape statistics
which makes the process very slow.
Moritz
[1] https://trac.osgeo.org/grass/ticket/2045
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On 20/06/16 23:20, Markus Metz wrote:
On Mon, Jun 20, 2016 at 6:40 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
Hi,
While work is ongoing concerning improving r.to.vect performance [1], I am
looking at the possibility of creating an r.zonal.geometry module which
would calculate a series of form statistics for raster zones (aka clumps). I
would begin simply by trying to replicate the v.to.db statistics, i.e. area
and perimeter, with compactness and fractal dimension derived from the two
former.
Area calculation is quite simple (and already exists, for example, in
r.stats.zonal with the count method). However, perimeter is a bit more
complicated. My current idea is to 'simply' fetch raster info into a SEG
structure and to check for each pixel whether the upper, lower, left and
right neighbor has the same cat value as the current pixel. For each
neighbor where this is not the case, I add one pixel edge to the total zonal
perimeter.
For raster-based perimeter calculation, you do not need a SEG
structure. Instead, you could use a 2x2 moving window and compare top
right - bottom right and bottom left - bottom right. Simply have two
rows at a time accessible. Whenever a pair is different, increment the
perimeter of each member of the comparison that is not NULL. You would
need to pad the region with a NULL row on top and bottom and a NULL
column to the left and right.
Ok, thanks ! That's pretty much exactly like clump.c in r.clump, or ?
This works only with unique
cluster/clump IDs and not with classes.
Yes. Not sure how usefule class-based geometries would be...
Do you want to obtain any
other parameters than area size and compactness? Another one might be
smoothness = perimeter of the cluster / perimeter of the cluster's
bounding box.
The idea is to extend gradually, so yes, bounding box based statistics would be nice. Probably also statistics based on the eigenvalues of the x,y coordinates matrix which allows approximating the form by an ellipse and calculating length/width ratio statistics.
But at this stage, I guess that for all these a two-row approach might be enough.
I don't know when I will have time for this, but I would love to be able to get this done before foss4g where I will present the GRASS OBIA toolchain...
Moritz
On Tue, Jun 21, 2016 at 9:36 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 20/06/16 23:20, Markus Metz wrote:
On Mon, Jun 20, 2016 at 6:40 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
Hi,
While work is ongoing concerning improving r.to.vect performance [1], I
am
looking at the possibility of creating an r.zonal.geometry module which
would calculate a series of form statistics for raster zones (aka
clumps). I
would begin simply by trying to replicate the v.to.db statistics, i.e.
area
and perimeter, with compactness and fractal dimension derived from the
two
former.
Area calculation is quite simple (and already exists, for example, in
r.stats.zonal with the count method). However, perimeter is a bit more
complicated. My current idea is to 'simply' fetch raster info into a SEG
structure and to check for each pixel whether the upper, lower, left and
right neighbor has the same cat value as the current pixel. For each
neighbor where this is not the case, I add one pixel edge to the total
zonal
perimeter.
For raster-based perimeter calculation, you do not need a SEG
structure. Instead, you could use a 2x2 moving window and compare top
right - bottom right and bottom left - bottom right. Simply have two
rows at a time accessible. Whenever a pair is different, increment the
perimeter of each member of the comparison that is not NULL. You would
need to pad the region with a NULL row on top and bottom and a NULL
column to the left and right.
Ok, thanks ! That's pretty much exactly like clump.c in r.clump, or ?
Yes. r.to.vect also does this padding and processing of a 2x2 window,
but I find the code in r.clump easier to use as template for a new
module.
This works only with unique
cluster/clump IDs and not with classes.
Yes. Not sure how usefule class-based geometries would be...
Do you want to obtain any
other parameters than area size and compactness? Another one might be
smoothness = perimeter of the cluster / perimeter of the cluster's
bounding box.
The idea is to extend gradually, so yes, bounding box based statistics would
be nice. Probably also statistics based on the eigenvalues of the x,y
coordinates matrix which allows approximating the form by an ellipse and
calculating length/width ratio statistics.
But at this stage, I guess that for all these a two-row approach might be
enough.
I don't know when I will have time for this, but I would love to be able to
get this done before foss4g where I will present the GRASS OBIA toolchain...
Moritz