Calculating “relative slope” per Mora-Vahrson method in ArcGIS

Question

I'm a longtime lurker who finally decided to register on the forum (in no way driven by my need to have a certain question answered, of course...).

I was contacted by a colleague asking for help calcuating an input for a landslide model he's working on. Specifically, the model he's following (the Mora-Vahrson paper/model) asks for the slope input to be not in degrees or percents, but "relative slope." This is obtained by using the formula:

Sr= [(ElevMAX-ElevMIN)/(Area)],

where the the min and max elevations are the lowest and highest points within a bounded area (most commonly 1 square km); these area searches/calculations are carried out across the desired study region without overlap.

I've tried multiple ways to calculate this using my existing skillset (limited; I'm an archaeologist with a background in GIS who was asked to help out...) and program (ArcGIS). I'm using a 90m resolution SRTM DEM for the area and have currently settled on using the Block Stats tool to calculate the MIN (and the MAX) for for a specified area 1000 x 1000m, and then entering those resultant rasters into the Raster Calculator as part of the Mora-Vahrson equation), and dividing by 1 (as the area of the Block Stat calculation, expressed in square km).

What I would like to gauge from more experienced GIS users is whether or not the Block Stats process I described seems to meet the requirements for the model's relative slope component. If anyone else has had experience calculating relative slope or a similar process, I'd be very interested to hear about it. Thanks.

Answer 1

Use focal statistics instead of block statistics: when using rectangular neighborhoods this produces the same results in the centers of the blocks, but focal stats are computed with moving (overlapping) windows, effectively creating a representation of a surface of relative slopes. Moreover, focal stats can be computed with more natural neighborhoods, such as circles, rather than the artificial isothetic rectangles required of block stats.

ArcGIS's focal statistics command will compute a range statistic: that's the numerator. To compensate for edge effects, it's often wise not to assume the moving windows have constant area (because their areas diminish towards the edges). Instead, create a unit grid (using Not(IsNull(...)) for instance) and compute the focal sum using the same neighborhood specification. Multiplying the focal sum by the squared cellsize (in squared kilometers, if that's what you need) gives the "focal area" grid. This calculation compensates not only for edge effects but also for any missing (NoData) values within the grid itself. This is the denominator: divide the focal range by this to obtain the relative slope.

If, at the end, you really need non-overlapping neighborhoods (although I can see no essential reason why that's necessary), you can subsample the resulting grid along any array of points you like, such as at the centers of the originally intended blocks. Perhaps surprisingly, this might not be any less efficient than carrying out block statistics directly: the time to carry out (simple) grid operations tends to be limited more by overhead like data I/O than by the calculations themselves. Having a full grid of results can, at the least, provide a richer and more informative map of the calculation than the block statistics grid does.