Proceed to GeoCommunity Home Page


SpatialNewsGIS Data DepotGeoImaging ChannelGIS and MappingSoftwareGIS JobsGeoBids-RFPsGeoCommunity MarketplaceGIS Event Listings
HomeLoginAccountsAboutContactAdvertiseSearchFAQsForumsCartFree Newsletter

Sponsored by:


TOPICS
Today's News

Submit News

Feature Articles

Product Reviews

Education

News Affiliates

Discussions

Newsletters

Email Lists

Polls

Editor's Corner


SpatialNews Daily Newswire!
Subscribe now!

Latest Industry Headlines
SiteVision GIS Partnership With City of Roanoke VA Goes Live
Garmin® Introduces Delta™ Upland Remote Trainer with Beeper
Caliper Offers Updated Chile Data for Use with Maptitude 2013
Southampton’s Go! Rhinos Trail Mapped by Ordnance Survey
New Approach to Measuring Coral Growth Offers Valuable Tool for Reef Managers
Topo ly - Tailor-Fit for Companies' Online Mapping Needs

Latest GeoBids-RFPs
Nautical Charts*Poland
Software & Telemetry GPS
Spatial Data Management-DC
Geospatial and Mapping-DC
Next-Gen 911-MO

Recent Job Opportunities
Planner/GIS Specialist
Team Leader- Grape Supply Systems
Geospatial Developer

Recent Discussions
Raster images
cartographic symbology
Telephone Exchange areas in Europe
Problem showcasing Vector map on Windows CE device
Base map

GeoCommunity Mailing List
 
Mailing List Archives

Subject: [gislist] SUM: GRID Tables
Date:  11/08/2005 02:30:00 AM
From:  Vassil Vassilev



Dear Sarah and Bill,

Thank you very much for your replies.
The solution of Sarah is much more simple and quick
(now I remember that I used it some time ago - but
when you don't take notes there is possibility to
forget, as it was now). Here is her solution:
.............................................
Hi Vassil,

You could use the zipcode approach to make one single
grid:

ELEV + (ASPECT *10) + (SLOPE * 100) + (LANDCOVER *
1000).

Best,

Sarah


Sarah Chamberlin
GIS Analyst
National Marine Fisheries Service
(208) 378 - 5660
sarah.chamberlin@noaa.gov
.....................................

I really appreciate the solution of Bill Huber, and I
will try it for sure. Here it is:

.....................................................

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 va

Sponsored by:

For information
regarding
advertising rates
Click Here!

Copyright© 1995-2012 MindSites Group / Privacy Policy

GeoCommunity™, Wireless Developer Network™, GIS Data Depot®, and Spatial News™
including all logos and other service marks
are registered trademarks and trade communities of
MindSites Group