At 05:14 AM 11/7/2005 -0800, Vassil Vassilev wrote:
>Now I have to make a final grid with indexes
>which should be based on a table in which the four
>variables are described, for example if ELEV is ... if
>ASPECT is ... if SLOPE is ... if LANDCOVER is ... than
>FINAL is ... etc. there are 88 different combinations.
>
>I can do this by two or three ways but they are quite
>computer resources consuming.
This is a problem many people eventually have to confront, so I will
address it in general, using this specific instance to show what is going on.
In its most difficult setting, there is no simple mathematical formula for
the final value based on the component grids. This indicates a lookup
table should be used. Therefore, begin by preparing a table of the 88
different combinations and their desired final values. (Such a table
already has to exist in some form or another, so it's usually no trouble to
create it.)
The trick lies in efficiently joining this table to the collection of
grids. I will describe a widely applicable method. Most generally, then,
suppose you have 'm' grids Grid[1], Grid[2], ..., Grid[m]. Each contains
values of a corresponding categorical variable. By reclassifying these
variables, if necessary (it's usually not), we may assume the values in
Grid[1] lie between 0 and some non-negative integer n[1], and in general
the values in Grid[i] lie between 0 and n[i]-1. For instance, suppose we
take the grids in the order stated, so that ELEV is Grid[1], ASPECT is
Grid[2], ..., and LANDCOVER is Grid[4]. Thus m = 4 grids in this
example. If there are (say) 11 different elevation classes, we may
therefore suppose they are categorized as values 0, 1, ..., 10. Thus n[1]
= 11. If there are 4 different classes to ASPECT, n[2] = 4. To make this
illustration concrete, let's also assume there are n[3] = 2 SLOPE classes
and n[4] = 2 LANDCOVER classes. The total number of possible combinations
is n[1]*n[2]* ... * n[m] = 11 * 4 * 2 * 2 = 176. Only half of these, 88,
actually occur.
Let the product n[1] * n[2] * ... * n[m] be N: it's the largest possible
number of class combinations that might occur. At this point, you need to
check that N does not exceed the capacity of your GIS's grid data
structure. For instance, ESRI grids, at least until recently, could handle
a maximum of N = 1,000,000. A grid of 32-bit unsigned integers can handle
a maximum of N = 2^32 = more than four billion.
Assuming your GIS can handle values between 0 and N-1, the idea is to
replicate the action of an odometer: form the linear combination Grid[1] +
n[1]*(Grid[2] + n[2]*(Grid[3] + ... n[m-1]*Grid[m])...). (That's what we
do to convert a car's odometer reading to a distance: Grid[1] is the miles,
Grid[2] is the tens of miles, and so on, where all the n[i] are equal to
10.) In our example, this would be ELEV + 11*(ASPECT + 4*(SLOPE +
2*LANDCOVER)). See what this does: it assigns a unique value between 0 and
N-1 to every possible combination. A value of 0 results when all the
components are zeros: a value of N-1 results when the components are
(n[1]-1, n[2]-1, ..., n[m]-1). In the example, this would be the
four-tuple (10, 3, 1, 1), and sure enough, 10 + 11*(3 + 4*(1 + 2*1)) = 175
= 176-1.
(The proof that this always works is illuminating and practical. Suppose
you have some value 'k' that you suspect could have been formed from
different combinations of grid values. Divide k by 11 and inspect the
remainder. This must correspond to the value of ELEV, because--as you can
see above--all the other grid values were multiplied by 11. Therefore the
two elevations, at least, have to be the same. So strip out the
contribution from ELEV by subtracting off the remainder from k and dividing
the result by 11. Repeat the previous steps, this time looking at the
remainders after dividing by 4, then next looking at remainders modulo 2,
and finally looking at what is left. At each step you will find perfect
agreement in the component grids (by the Principle of Mathematical
Induction applied to m). Therefore equal combined values do indeed reflect
equal values of the component grids in every case. The proof even shows
how to recover the component values from the combined values.)
To achieve the join, you need to compute one more field in your lookup
table, using the same formula for combining the component values into an
index. Join the lookup table to the combined grid to produce the desired
"FINAL" values.
In summary, the task is done by obtaining a linear combination of grid
values (usually a fast and efficient operation, both in terms of computing
time and RAM), computing the same linear combination in a lookup table
(also fast), and joining the loo
|
