# Generating fixed distance buffer including slope using ArcGIS Desktop?

Is it possible to generate a fixed distance buffer including slope using ArcGIS Desktop 10?

The distance on the map is not equal to the distance on the ground due to the incline. If the calculation is good, I have got this result. If the buffer is 300m (horizontal length on the map), I got 300m on the ground equal to 235m on the map. That's actually what I was looking for. I'll still check if it really on that slope that distance. • Please do not specify two different software packages in a single question -- This automatically makes the question too broad, since it's effectively two questions. I doubt any "Buffer" command would ever consider slope, since there is no room for a surface in the function parameters. Your best hope is to research "Buffer3D" commands. – Vince Aug 15 '17 at 10:22
• This is essentially a duplicate of this question gis.stackexchange.com/questions/70101/… - albeit unanswered it does suggest exploring the concept of 'path distance' as a possibility. – Ed Rollason Aug 15 '17 at 11:16
• While there seems to be no possibility in QGIS (or ArcGIS...) alone, I could imagine adding the help of PostGIS to be worth a try (not asked for but since you don´t really care about software...): import your raster as a vectorized point layer (with height values in attributes, you could use a smaller subset of your raster to reduce size) along with your lines, create 3D Points from it and use a query with ST_3DDWithin to find all Points in 3D distance to your line. Then create a polygon from selected points via ST_ConvexHull and export as layer. – ThingumaBob Aug 15 '17 at 11:51
• QGIS or ArcGIS, any solution – nagib Aug 15 '17 at 13:07
• let me add: if you consider trying my approach, keep in mind that it is still a linear distance. to accumulate the distances of all points in between, the query would be much more complex – ThingumaBob Aug 15 '17 at 15:23

You should use cost PATH and a vertical factor, and not cost DISTANCE, because the extra distance is a function of your travel direction.

In your case, you don't need to use any horizontal factor or friction raster, but you need to specify a vertical factor. It will compute the vertical difference between the origin cell and EACH neighbour, then apply a factor to the horizontal distance. In your case, this factor will be, as mentioned by by @JG---, equal to '1/cos(x)'. In practice, you can use the SEC() function (which is the same as 1/cos(x)) or, if you prefer, the cos() function with power -1. So, the parameter should be (assuming that your DEM Z values are in the same coordinates unit than your coordinate system): 1) no cost raster, 2) maximum distance(optional) = your buffer distance, 3) Input vertical raster = your digital ELEVATION model (do not use the slope!) 4) Vertical factor = Sec (with default settings) or Cos (with power = -1). Once you have this raster, reclassify it to a binary raster (e.g. with Con(distance_raster < your_buffer_distance, 1) ) then convert to polygon.

Cost path gives you the shortest path, which could differ from accumulated distance along the line that is perpendicular to your line of reference because it will try to avoid obstacles (e.g., it will use the pass instead of going straight to the cliff).

I agree with the use of cost distance although the answer won't be very precise based on your elevation cell size. By using the cosine function, the generated slope in degrees, and the cell size of the elevation layer a cost layer could be produced.

``````hypotenuse = cell size/cos(angle)
``````

Where hypotenuse equals the ground distance traveled.

There are a range of tools in spatial analyst that would compute this for you but it may be easiest in Raster Calculator and look something like below:

``````cell size/cos(slope raster)
``````

It is also important to note that x, y, z need to be in a common unit which can be achieved using a metric projection or by applying a z-factor conversion to the cell size.

• be carefull with that: slope raster will take the steepest slope, not necessarily the slope in the direction of the displacement. – radouxju Aug 16 '17 at 11:39