Calculating Variable Width Buffers on a Stream Segment Based on Elevation


GOAL: variable width buffer based on elevation
RESULT: What we’ve got is mostly correct, but with the following issue.

METHODS
In the example below, the stream line is shown in blue and some retention ponds are visible in the aerial photo near that stream:

Next, we take that stream segment and make it into a grid with the same extent as our elevation grid. It looks like this, where each cell has a slightly different elevation value (streams generally go downhill!):

Then we create a Euclidean allocation grid from those stream elevations. It just assigns the elevation of the nearest source stream pixel to all of the other cells. For example, the yellow area is all assigned pixel values of 148817 (meters X 100, since I have also multiplied the elevation grid by 100 to make it into an integer). That stream pixel value that the yellow is emanating out from has a value of 148817.

The next step is to subtract the Euclidean grid from the true elevation grid so that, for each pixel, we determine how much higher that pixel is than the elevation of the closest stream pixel. Ideally, this would produce a variable width buffer once you set a threshold for how high you want to go. For example, if I set the threshold at 1/2′ (which is 15 units in my data, remember it is meters and multiplied by 100), then the resulting “buffer” looks like this, in green:

The area shaded in green is a model of where the locations around the stream are within a half-foot elevation rise of the stream. Areas that are not in green are higher than half a foot of the stream. Note that I’ve left out some of the details which involve subtracting the Euc grid from the elevation grid, then testing (with a con statement in ArcMap in this case) whether or not the result is above 15 or lower than 15, where it is lower than 15, we assign the pixel a 1 and where it is above 15 we assign a NoData value.

THE ISSUE
The model works pretty well in many areas. As can be expected, it looks even better when we use less fine increments. So if we calculate the 7′ elevation rise, for example, the resulting buffer does not have a lot of strange “jogs” out from the stream line. I’ve chosen this particular example location to illustrate the problem that these retention ponds make very clear. One would expect that the entire retention pond, which has a completely even elevation surface, would be in the buffer if part of it is. However, in this case, the anomaly lies with the Euclidean distance raster. Since it is allocating the closest stream elevation to each pixel, if a stream changes in elevation enough from one neighboring pixel to another to cause the subtraction of the grids to cause one part of the pond to be “in” the buffer and one “out” of the buffer, then this will happen.

STEP BY STEP EXAMPLE
In this case, the pink part of the Euclidean distance calculation, in the upper left quadrant, comes from a source pixel having elevation equal to 148,987.
The purple area of the Euclidean grid just below that pink area has an elevation value equal to 148,801.
The retention pond has an elevation of 148,990 throughout its area (well, at least until you get to the slight rise at its edges).

For the pink part then, 148,990 – 148,987 = 3. Clearly, 3 is within out threshold of half-foot (which is 15 units)
For the purple part, 148,990 – 148,801 = 189. Clearly, 189 is not in our half-foot threshold. Thus, it doesn’t show up, even though the retention pond has an even elevation throughout!

At this stage in the analysis we must quantify the effect of this anomaly on the overall model’s accuracy.

(I noted at the end of How To Create an Inside Buffer Based on Elevation, that a cost distance raster could be used to do what I describe above. However, cost distance works only for local areas where the stream elevation remains constant–in this case, the stream elevations change from mountain elevations on down to plains elevations)

  1. #1 by Parker Wittman on June 10, 2012 - 12:32 pm

    I love your analytical posts like this, Gretchen. Thanks.

    I haven’t thought *too* deeply about this… but perhaps you could *fix* the pond issue by adding one more analytical step: If you were game for moving over to VectorLand, you could turn your output buffer raster into a polygon and merge it with any vector representations of water bodies that overlap the buffer (provided that suitable water body polygons exist). Would this produce the desired output?

  2. #2 by Gretchen on June 11, 2012 - 3:14 pm

    Yes, I think that an additional overlay of lakes, ponds, etc. (which, yes, we can tease out of the available data) is a good idea. In fact, anywhere where there is a more or less continuous lack of slope may be something to add in to the results. Good ideas for me to ponder. Thanks and glad you like these types of posts.

Comments are closed.