On 20/06/16 23:20, Markus Metz wrote:
On Mon, Jun 20, 2016 at 6:40 PM, Moritz Lennert
<[email protected]> 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
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
