# Understanding length- versus area-based budgeting for activities

edited October 2015 in RIOS
Greetings all,

RIOS asks for costs of landscape activities which can be input as an amount per unit length or as an amount per unit area.  I'm dealing with activities (bunds, terracing, trenching, etc) which have different costs based on the slope (since steeper slopes require more closely spaced structures). I often know the cost of building these structures for a unit length.

My question is, when RIOS deals with a unit length, how does it (later) convert this to a cost per area (the output shows values in cost per hectare). Does it assume that a length-based activities can only traverse a pixel once?

Thanks for any enlightenment!
Post edited by jelliso on
Tagged:

• RIOS length costs are calculated by measuring the perimeter of a pixel.  This isn't really a great way to measure return on investment across a landscape since the cost per pixel increases linearly as a pixel increases for unit length costs, but as a square for area costs.  That tends to bias per-length costs on rasters with large pixels and per-area costs for small pixels.  That's nonsense of course, so be careful when using per length costs when you can!
• I just wanted to add some suggestions to Rich's explanation - The per-length costs in RIOS are somewhat problematic for dealing with activities like terracing, etc. that you have in your study.  In most cases, what we have done is to make assumptions about the spacing of terraces on a hectare of land to calculate a per-hectare cost of terracing and input this to RIOS as a per-area cost (rather than per-length).

This would help you to reflect different costs for different sloping lands as well.  An option there would be to re-classify your land use map based on both land use and slope bins, for example breaking your croplands into classes like "croplands - 0-10% slope" and "croplands - 10-25% slope." Next, you specify two different activities: "terracing on 0-10% slopes" and "terracing on 10-25% slopes" and specify (in the LULC Classification csv with Activities input) that each activity is only allowed on the corresponding land use-slope combination.  Then you can make different assumptions about the spacing of terraces on the different slope classes, and adjust the per-hectare cost of the two activities accordingly.

This would be a more accurate way to represent the actual per unit area cost of such activities, rather than letting RIOS use the default assumption of length cost summed around the perimeter of pixels.

Cheers,