Message |
That, unfortunately, does not address the problem: the fetch is not the shortest distance from a point to the boundary, but rather is the length of the longest connected line segement contained wholly within the polygon and passing through the given point. In a very long straight channel, for instance, all points will be within a half-width of the boundary, but the fetch at every point will be approximately the _length_ of the channel.
There is an approximate grid-based approach. Here's the idea: Choose a direction. Find the distance to the shore (polygon boundary) from each water cell (cell in the polygon's interior) _in that given direction_. Do this again for the opposite direction (changed by 180 degrees). Add the two grids. This gives the total straight-line distance through each cell _in that give direction_. Repeat for a set of directions and retain the maximum distance.
The directions for which you can obtain accurate results are at multiples of 45 degrees. To do the computation with other angles, first rotate the polygon, create a grid for the rotated polygon, and work on that. In this fashion you can inspect as many angles as you like.
Here are some details from an e-mail exchange I had some four years ago. The context is Spatial Analyst 1.0 + ArcView 3.x, but all the details translate easily to ArcGIS 8.x.
> In a grid cell cover of just the water bodies, I'd be happy
> to find the maximum number of cells in each row, column, and
diagonal
> that each cell is a component of.
This, I believe, can be done. Here's the strategy. Pick a direction (up,
down, left, right, one of the diagonals). Suppose you could compute the
distance (in cells) from each water point to the nearest shore point ALONG
THE CHOSEN DIRECTION. You could use this to solve your problem. After
all, to find the number of cells in a column, just compute the number of
cells down plus the number of cells up (plus one for the cell you are
on). Use a similar procedure for the row and the two diagonals.
Well, you can compute these distances. You use the FlowAccumulation
request. Simply tell Spatial Analyst that the water is flowing in the
desired direction at a constant rate. The flow accumulation is then
directly proportional to the distance flowed from a source (the shore) to
each cell (a point on the water).
You will want to experiment before you do this for real. I do so using the
map calculator because it allows interactive exploration of the results of
grid requests. Later you can script the whole mess, largely by copying the
map calculator expressions.
Begin by loading Spatial Analyst. Create a view and add any grid theme (in
order to enable the Analysis|Properties and Map Calculator menu
items). Establish a small grid for the exploration. I usually set
bottom=left=0, top=right=8 or 16, say, and cell size=1.
Here is a sequence of map calculator expressions to (a) create a simulated
water body and then, for each water cell, (b) compute the number of
contiguous "water" cells within the column. The result will be in the
"column" theme. Similar expressions would be needed for the row and
diagonals. It is important, if you want to re-use these expressions, to
name the themes exactly as I have, so I provide first the theme's name
(which you specify AFTER the map calculation creates it) and then the map
calculator expression.
Water: ( grid.makerandom.Filter(#GRID_FILTERTYPE_LOW ,
false).Filter(#GRID_FILTERTYPE_LOW , false)< 0.55.AsGrid).Int
Down: [Water] * 64
Up: [Water] * 4
Distance down: [Down].FlowAccumulation(nil)
Distance up: [Up].FlowAccumulation(nil)
Column: ( [Distance up] + [Distance down] + 1)
Comments:
After the first map calculator expression has been executed, you can delete
the irrelevant theme you started with--the map calculator will stay enabled
as long as a grid theme is present. (This is an interface bug.) Zoom to
the extent of the calculated theme so you can see what's happening.
The "water" theme is an indicator grid: 0 means no water, 1 means water
exists. You can work your water/land grid into this form using the map
calculator or through reclassification.
If your random "water" theme does not look very interesting, just choose
Theme|Edit theme expression and press the evaluate button. (The evaluate
button begins disabled. The work around for this bug is to press any
key--the shift key is real safe--to enable the evaluate button.) You will
get a new random water theme. Repeat until it looks good (modify the
expression if you like: the value of 0.55 establishes how much of the grid
is water and how much is land).
The directions are documented in the discussion for the FlowDirection
request in the ArcView help. They have to be reversed to compute
distances; thus: 1 = left, 4 = up, 16 = right, 64 = down, and neighboring
powers of 2 are the interpolating diagonal directions. Really minor
changes (replace the "64" and "4" in the map calculator expressions) will
suffice to do the computations for the row and the two diagonals.
For the diagonals you will have to multiply the distances by the square
root of 2, since Spatial Analyst computes flow accumulation in terms of
cells traversed rather than distance. The best time to do this is in the
last computation, as in
Up to right: ([Distance up to right] + [Distance down to left] +
1)*(2.Sqrt)
Once you have four themes, named (say) "column", "row", "up to right", "up
to left", then you can compute the maximum along all four directions using
the LocalStats request, as in
[Column].LocalStats(#GRID_STATYPE_MAX, {[row], [up to right], [up to left]})
The FlowAccumulation request executes reasonably quickly. It should be
feasible to use this approach on mega-cell grids. |