Let’s see…where did I leave off?
After posting a note on facebook hypothesizing that perhaps the graph shown in the previous post showed that the flow direction algorithm was biased toward the ordinal directions. Brian agreed that there was an artifact here, perhaps as a result of the algorithm, or possibly of the gridded nature of the elevation raster itself. Brian suggested a couple of tests, involving conversion from raster to point and reinterpolating the raster, converting to contours and then using topo to raster, or smoothing using focal statistics. I did not try any of these, because I did not want to open the interpolation can of worms here, per se, because I thought it might essentially introduce another variable and muddy the source(s) of bias further. I had reprojected the data from NAD83 to State Plane, because otherwise slope never comes out right, and this projection introduced an artifact mesh. After a little back and forth on this, Greg chimed in that DEMs are highly inaccurate to begin with as a result of data collection. , and that conversion back and forth only propagates the error.
I realized that the sine wave implies a D-infinity flow algorithms–that is, flow could be calculated in any direction from the cell center. This is, of course, not what ArcGIS actually does. What the graph should really show is 8 columns to represent the 8 discrete directional possibilities from one cell to any of its eight neighbors. What occurred to me at this point is that for any of these 8 possible directions, the cell count will not be the same at a given distance. If, for example, one measures the distance from the center of a cell to the center of each neighboring cell in the ordinal directions (diagonally), then the distance will be the cell width multiplied by the square root of two, and we can call the cell count 1. Assuming that cells can be partially counted, then the same distance in the cardinal directions will cover about 1.414 cells. Therefore, the pattern I noted may be nothing more than the geometry of a square, causing cell counts to be relatively lower in the ordinal directions for exactly the same flow length. I thought a way to test this might be to clip a circular extent and rotate it. It should be possible to remove the effect of this geometry by using a factor of the square root of two, and then to see whether the same number of cells is calculated for each angle of rotation (corresponding to the 8 directions in question) when the angle is accounted for. I made a graph that shows how I believe the pattern should change for an identical area as it is rotated through a full rotation at 15-degree increments.
Also, I made a couple short animations in Windows Live Movie Maker showing the flow directions as the circular clip from the DEM is rotated. These aren’t so much for analytical purposes as for fun. They were more fun with music, but I removed it to make the files smaller: