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. 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-dev _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
