#3269: r.roughness.vector: bug in rescale formula
--------------------------------------+-------------------------
Reporter: sbl | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.2.1
Component: Default | Version: unspecified
Keywords: AddOn,r.roughness.vector | CPU: Unspecified
Platform: All |
--------------------------------------+-------------------------
There is a little bug in the formula that produces the "Fischers K" output
(line 317).
"- 1" should not be in there.
#3269: r.roughness.vector: bug in rescale formula
--------------------------+--------------------------------------
Reporter: sbl | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.2.1
Component: Default | Version: unspecified
Resolution: | Keywords: AddOn,r.roughness.vector
CPU: Unspecified | Platform: All
--------------------------+--------------------------------------
Comment (by hellik):
Replying to [ticket:3269 sbl]:
> There is a little bug in the formula that produces the "Fischers K"
output (line 317).
> "- 1" should not be in there.
#3269: r.roughness.vector: bug in rescale formula
--------------------------+--------------------------------------
Reporter: sbl | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.2.1
Component: Default | Version: unspecified
Resolution: | Keywords: AddOn,r.roughness.vector
CPU: Unspecified | Platform: All
--------------------------+--------------------------------------
Comment (by sbl):
Yes, same issue there.
For what I can see, line 265 in https://trac.osgeo.org/grass/browser
/grass-addons/grass6/raster/r.roughness/r.roughness.window.vector.sh
should be changed equally like this:
{{{
- r.mapcalc $FISHER = "($window * $window - $STRENGTH) / ($window *
$window - 1)"
+ r.mapcalc $FISHER = "($window * $window - $STRENGTH) / ($window *
$window)"
}}}
Result should be scaled from 0 to 1. Thus formula should be:
#3269: r.roughness.vector: bug in rescale formula
--------------------------+--------------------------------------
Reporter: sbl | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.2.1
Component: Default | Version: unspecified
Resolution: | Keywords: AddOn,r.roughness.vector
CPU: Unspecified | Platform: All
--------------------------+--------------------------------------
Comment (by hellik):
Replying to [comment:2 sbl]:
> Yes, same issue there.
> For what I can see, line 265 in https://trac.osgeo.org/grass/browser
/grass-addons/grass6/raster/r.roughness/r.roughness.window.vector.sh
> should be changed equally like this:
>
> {{{
> - r.mapcalc $FISHER = "($window * $window - $STRENGTH) / ($window *
$window - 1)"
> + r.mapcalc $FISHER = "($window * $window - $STRENGTH) / ($window *
$window)"
> }}}
> Result should be scaled from 0 to 1. Thus formula should be:
>
> {{{
> V' = (max(V[i-j]) - V) / max(V[i-j]
> }}}
Could you ping Carlos, the author of both addons, regarding this issue?
Another related question: There are now two AddOns for this purpose:
r.roughness.vector (last changed 2 years ago)
and from 2016: r.vector.ruggedness
Both basically calculate the same metric(s), though they have their differences and both have their pros:
r.roughness.vector offers more advanced options (esp. useful for multi scale application)
r.vector.ruggedness uses parallelization
Having two modules for one task / metric, which are not conceptually different is a bit confusing...
IMHO both should be merged into one, keeping the strength of each of them...
Other thoughts?
Cheers
Stefan
-----Original Message-----
From: grass-dev [mailto:grass-dev-bounces@lists.osgeo.org] On Behalf Of GRASS GIS
Sent: tirsdag 24. januar 2017 08.45
Subject: [GRASS-dev] [GRASS GIS] #3269: r.roughness.vector: bug in rescale formula
#3269: r.roughness.vector: bug in rescale formula
--------------------------------------+-------------------------
Reporter: sbl | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.2.1
Component: Default | Version: unspecified
Keywords: AddOn,r.roughness.vector | CPU: Unspecified
Platform: All |
--------------------------------------+-------------------------
There is a little bug in the formula that produces the "Fischers K" output (line 317).
"- 1" should not be in there.
On 24 January 2017 at 09:55, Blumentrath, Stefan
<Stefan.Blumentrath@nina.no> wrote:
Hi,
Hi,
Another related question: There are now two AddOns for this purpose:
r.roughness.vector (last changed 2 years ago)
and from 2016: r.vector.ruggedness
Both basically calculate the same metric(s), though they have their differences and both have their pros:
r.roughness.vector offers more advanced options (esp. useful for multi scale application)
r.vector.ruggedness uses parallelization
Having two modules for one task / metric, which are not conceptually different is a bit confusing...
IMHO both should be merged into one, keeping the strength of each of them...
+1 for merging... this could be a work for the next code sprint
And many thanks for clarification and contrasting results in detail…
And sorry for throwing the question at the list without having checked that (I just scanned the module code).
I noticed the difference in the references referred to in both modules. From scanning the code they seemed to do the same thing, but now I see that the main difference is probably that r.vector.ruggedness uses slope directly for weighting vector strength, while r.roughness.vector uses the “inverted” slope / colatitude angle (90 – slope). Apart from that both modules look quite similar (as are the names) in terms of what they do to the DEM.
So, there might still be a point of consolidating them into one module which offers both the “Sappington et al. 2007 metric” and the “Hobson 1972 metric”…
Just a thought…
Kind regards,
Stefan
···
Hi,
There seems to be some difference in the calculation between these two add-ons. Apologies for any duplication, but in the way of explanation I wrote the parallelized r.vector.ruggedness because I needed to calculate the VRM measure in a hurry and was confused about the results from r.roughness.vector.
The result from r.vector.ruggedness is identical (apart from how slope and aspect are calculated) to the result from the Sappington et al. 2007 paper and the Sappington-authored script in ArcGIS (see attached derived from the nc_spm_08 grass dataset). The form of the calculation is slightly different (but the end result is the same) because I average rather than sum the x,y, and z rasters to avoid a strong edge effect because AFAIK r.mapcalc doesn’t have an automated method of dealing with bordering nulls (hence the averaging workaround). The r.vector.ruggedness results are also the same as how SAGA GIS calculates this metric, and it is this version of the ‘VRM’ metric that has been used extensively in the literature over the past few years.
r.roughness.vector appears to produce a very different result (see attached). Perhaps this represents an alternative implementation, but the main difference lies in how the DEM is decomposed into its x,y, and z components.
So if the add-ons are to be merged then perhaps this needs to be resolved?
Another related question: There are now two AddOns for this purpose:
r.roughness.vector (last changed 2 years ago)
and from 2016: r.vector.ruggedness
Both basically calculate the same metric(s), though they have their differences and both have their pros:
r.roughness.vector offers more advanced options (esp. useful for multi scale application)
r.vector.ruggedness uses parallelization
Having two modules for one task / metric, which are not conceptually different is a bit confusing…
IMHO both should be merged into one, keeping the strength of each of them…
+1 for merging… this could be a work for the next code sprint
+1 for that suggestion. There might be a few variants / other directional measures that could be included with a ‘method’ argument like real surface area.
And many thanks for clarification and contrasting results in detail…
And sorry for throwing the question at the list without having checked that (I just scanned the module code).
I noticed the difference in the references referred to in both modules. From scanning the code they seemed to do the same thing, but now I see that the main difference is probably that r.vector.ruggedness uses slope directly for weighting vector strength, while r.roughness.vector uses the “inverted” slope / colatitude angle (90 – slope). Apart from that both modules look quite similar (as are the names) in terms of what they do to the DEM.
So, there might still be a point of consolidating them into one module which offers both the “Sappington et al. 2007 metric” and the “Hobson 1972 metric”…
There seems to be some difference in the calculation between these two add-ons. Apologies for any duplication, but in the way of explanation I wrote the parallelized r.vector.ruggedness because I needed to calculate the VRM measure in a hurry and was confused about the results from r.roughness.vector.
The result from r.vector.ruggedness is identical (apart from how slope and aspect are calculated) to the result from the Sappington et al. 2007 paper and the Sappington-authored script in ArcGIS (see attached derived from the nc_spm_08 grass dataset). The form of the calculation is slightly different (but the end result is the same) because I average rather than sum the x,y, and z rasters to avoid a strong edge effect because AFAIK r.mapcalc doesn’t have an automated method of dealing with bordering nulls (hence the averaging workaround). The r.vector.ruggedness results are also the same as how SAGA GIS calculates this metric, and it is this version of the ‘VRM’ metric that has been used extensively in the literature over the past few years.
r.roughness.vector appears to produce a very different result (see attached). Perhaps this represents an alternative implementation, but the main difference lies in how the DEM is decomposed into its x,y, and z components.
So if the add-ons are to be merged then perhaps this needs to be resolved?
Another related question: There are now two AddOns for this purpose:
r.roughness.vector (last changed 2 years ago)
and from 2016: r.vector.ruggedness
Both basically calculate the same metric(s), though they have their differences and both have their pros:
r.roughness.vector offers more advanced options (esp. useful for multi scale application)
r.vector.ruggedness uses parallelization
Having two modules for one task / metric, which are not conceptually different is a bit confusing…
IMHO both should be merged into one, keeping the strength of each of them…
+1 for merging… this could be a work for the next code sprint
#3269: r.roughness.vector: bug in rescale formula
--------------------------+--------------------------------------
Reporter: sbl | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.2.1
Component: Default | Version: unspecified
Resolution: | Keywords: AddOn,r.roughness.vector
CPU: Unspecified | Platform: All
--------------------------+--------------------------------------
Comment (by guano):
Hi there, sorry for the late reply.
I went looking in the paper by Hobson (1972), and the original formula for
Fischer K is: (N-1)/(N-R), but in the module (and in my paper) I used the
*inverse* of it (so smooth areas would end up with a low value). Inverting
the formula gives (N-R)/(N-1).
I went looking in the paper by Hobson (1972), and the original formula for
Fischer K is: (N-1)/(N-R), but in the module (and in my paper) I used the inverse of it (so smooth areas would end up with a low value). Inverting
the formula gives (N-R)/(N-1).
As for merging the modules, I’m ok with it. makes more senso to have a generic roughness module with several options on methods.
+1 for that suggestion. There might be a few variants / other directional measures that could be included with a ‘method’ argument like real surface area.
And many thanks for clarification and contrasting results in detail…
And sorry for throwing the question at the list without having checked that (I just scanned the module code).
I noticed the difference in the references referred to in both modules. From scanning the code they seemed to do the same thing, but now I see that the main difference is probably that r.vector.ruggedness uses slope directly for weighting vector strength, while r.roughness.vector uses the “inverted” slope / colatitude angle (90 – slope). Apart from that both modules look quite similar (as are the names) in terms of what they do to the DEM.
So, there might still be a point of consolidating them into one module which offers both the “Sappington et al. 2007 metric” and the “Hobson 1972 metric”…
There seems to be some difference in the calculation between these two add-ons. Apologies for any duplication, but in the way of explanation I wrote the parallelized r.vector.ruggedness because I needed to calculate the VRM measure in a hurry and was confused about the results from r.roughness.vector.
The result from r.vector.ruggedness is identical (apart from how slope and aspect are calculated) to the result from the Sappington et al. 2007 paper and the Sappington-authored script in ArcGIS (see attached derived from the nc_spm_08 grass dataset). The form of the calculation is slightly different (but the end result is the same) because I average rather than sum the x,y, and z rasters to avoid a strong edge effect because AFAIK r.mapcalc doesn’t have an automated method of dealing with bordering nulls (hence the averaging workaround). The r.vector.ruggedness results are also the same as how SAGA GIS calculates this metric, and it is this version of the ‘VRM’ metric that has been used extensively in the literature over the past few years.
r.roughness.vector appears to produce a very different result (see attached). Perhaps this represents an alternative implementation, but the main difference lies in how the DEM is decomposed into its x,y, and z components.
So if the add-ons are to be merged then perhaps this needs to be resolved?
Another related question: There are now two AddOns for this purpose:
r.roughness.vector (last changed 2 years ago)
and from 2016: r.vector.ruggedness
Both basically calculate the same metric(s), though they have their differences and both have their pros:
r.roughness.vector offers more advanced options (esp. useful for multi scale application)
r.vector.ruggedness uses parallelization
Having two modules for one task / metric, which are not conceptually different is a bit confusing…
IMHO both should be merged into one, keeping the strength of each of them…
+1 for merging… this could be a work for the next code sprint