This forum is shutting down! Please post new discussions at

Understanding length- versus area-based budgeting for activities

jellisojelliso Member
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


  • RichRich Administrator, NatCap Staff
    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!
  • adrianvogladrianvogl Member, NatCap Staff
    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.

  • Thanks Rich and Adrian for the clarification on this issue.

    As an alternative to Adrian's suggestion to differentiate LUCs and activities according to different slope classes, I have an additional idea, and I wonder if it would have an identical result...

    Different activities are created for each slope class (ex: grass strips up to 8% slope). Then, a shapefile is created to prohibit that activity on slopes outside of the specified range (ex: on slopes greater than 8%).

    Prices could be area-based using the price for an average slope for the slope class.

    I think this would produce an identical result?
  • adrianvogladrianvogl Member, NatCap Staff
    Yes, you are correct - this would produce the same result as you can prevent activities in certain places either by using shapefiles (in the Activity Preferences) or by not allowing them in the LULC classification table.
Sign In or Register to comment.