[GRASS-dev] hints appreciated for work on a r.zonal.geometry module

Markus Metz markus.metz.giswork at gmail.com
Mon Jun 20 14:20:38 PDT 2016

On Mon, Jun 20, 2016 at 6:40 PM, Moritz Lennert
<mlennert at 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.


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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

More information about the grass-dev mailing list