Hello all,
I think I've discovered an issue with a method I'm using. Hopefully someone can help or at least point me in the correct direction.
I'm trying to use both slope and water accumulation as variables to determine where a historic trail could have traveled. I'm using a least cost analysis to do so by creating my own scale within each variable by reclassing results. These are then combined using weighted overlay to give me one raster set depicting where the easiest and most difficult areas to travel would be.
My problem comes in when using the cost path tool. It will draw the easiest path, or the past of least resistance, but the problem regards small wash line features. Although the program marks these as areas where water is more likely to accumulate (thus areas they wouldn't want to travel), when cost path runs it thinks it can go to the cell next to the stream and then cross diagonally, completely avoiding the line feature.
I've attached a picture to better describe what I'm talking about. The red line is the cost path drawing, the costs in the area are higher with darker blues, lower with lighter blues (or light purples). If you notice, at several points the path diagonally jumps across a stream when the stream is traveling diagonally as well. Checking the values of these cells, it certainly doesn't seem to be accounting for the higher valued cells around it.
Anyone have an idea how to fix this? Should I try finding a way to restrict movement just to up, down, left, and right? I'm at a loss at this moment, as I'm pretty new to using the program.
Help is appreciated!
Matt
the image shows what is expected and there isn't really a way to limit cost path to specific cardinal directions easily. On simple solution might be to use 'Expand' on the 'stream' class by a cell value of 1. Effectively this is a one cell 'buffer' which will close off those diagonals. You could compare those results to what you have to see if this is a sufficient enough barrier to suit your needs.
Excellent idea. I'll have to try it out. I don't anticipate it modifying my results too much, but I could definitely see how some scenarios could. Really appreciate the input!
Matt
We've had similar issues with lines we use as "walls" when walling DEMs for flow-conditioning, where corner connectivity across our wall line would make the wall "leak". The solution we came up with was to buffer the lines by half the cell diagonal (cellsize * .7) and running Polygon To Raster, instead of just Polyline To Raster. The vector step bugged me, as a certified waffle-head, but an Expand operation just made our walls unnecessarily thick.
Interestingly the pre 10.x didn't have this problem, but since 10.x it is possible for Feature To Raster and Polyline to Raster results to allow diagonal connectivity 'across' our walls, hence the buffer step.
Thanks for the idea, Curtis. I'll have to unpack these ideas and see what it'll do for me. Helps my confidence that buffering was one of the only ideas I had for resolving the issue, and it has worked for another. Hopefully they fix the problem in the future!
Matt