Jan 6 1999: I am starting the year with an increased commitment to
generating a couple more useful classes, but I am letting others deal
with graphic interfaces and other general issues.
I have a new class that does lots of stuff with an AAT file, I hope to
produce a class that uses rivers to fix DEMs.
March 24, 2000: still poking around. Finally wrote Pat.java
My work in Java and GIS
Having cut my teeth using and expanding homemade GIS systems, I was reluctant
to adopt a store-bought GIS like ARC/INFO. Over the years, I have become
comfortable with ARC/INFO, and have
fallen into the habit of equating GIS and ARC/INFO. Some tasks
which stymied me as a FORTRAN programmer are trivial (at least after years of
expericence) in ARC/INFO. However, some conceptually simple tasks drive me
up the wall. I have responded by downloading data from the proprietary
database, manipulating it with my own programs, and feeding back into ARC/INFO.
This has fallen into two major categories.
Grids (rectangular matrices of values) can be written into files of integers
or floating-point numbers, modified by standalone programs, and read back
into ARC/INFO formats. (In fact, a file of binary integers, with an
associated header file, can be seen as both a universal data file and as a
displayable ARC/INFO image.)
Although ARC/INFO has a strong grid-algebra language, it does not have the
full power of addressing arrays on both sides of an assignment statement, and
it does not have the power to modify an array and work on it without first
writing it out as an intermediate grid. Such power is implicit in most
Examples of externally processing include:
delivering many grids, including time series, to a hyrologic modeler who
thinks that FORTRAN is the universal language and that GIS languages are too
obscure and ephemeral.
running an old TOPMODEL program (with array sizes kicked up) to fill sinks
more reliably than arc/info.
Tracing water flowing downhill. (This was successfully written as an
ARC/INFO macro, but runs 100 faster in C or java)
Running a flowaccumulation algorithm that does not distribute all the
water to the lowest neighbor.
Take a look at a class that converts a bil file to a java array
and a class that does work on arrays.
Look here for Seattle data QA
An ARC/INFO Arc Attribute Table (AAT) is just a sequence of binary records.
I have written an arc class which holds an AAT record,
and a class that reads
an array of records and maipulates them. One remaining
problem with the class is that the list of items must be hardcoded to match
the specific list items in a record. That list varies as users add items,
and is also dependent on whether the coverage is single- or double-precision.
Here is a class that reads an AAT file and checks for
connecting contour lines that have different elevations.
It can be called by a class
that enumerates all the line coverages that find a certain filespec.
I have been having trouble writing an application that can be called either
from an applet or a command line. For now, I have a
separate version that can stand on it's own.
I have a new
swallows any ARC/INFO ArcAttribute Table. NOTE: important bug fix 3/11/98, and updated 4/2/2000
It works with any number of additional items.
The constructor method reads the data into arrays. (See internal documentation
for details.) There is also a writeAat method, two report methods that
println information about the AAT, and a findItem method that returns the
index of a named item. I used a test program to
but I advise caution before invoking writeArcs to overwrite your Aat.
Here is a program that uses this classs to do
actual work, checking a river system to make sure that an attribute increases
as you move downstream. Here's one that interpolates
elevations at stream junctions. It's a bit tough to follow with knowing the
details of the GIS work that precedes it.
Finally, a class to read a PAT file
with a little test program
How does one use a DEM to calculate contributing
area to a river network, avoiding severe errors that can result from little
inaccuracies in the DEM?
I have another version of the program that does more stuff.
- grid the streams by ID number
- using the flowdirection grid, calculate the (local) contributing area
to each stream segment.
- transfer that area to the "vector" streams coverage.
- use AddAat.java to sum the local contributing
areas as you go downstream.
I am trying to port a grid-based slope-stability application from ARC/INFO
to java for wide distribution. If I get a grant, I will be forced to get
moving with it.
I see that an open GIS is taking shape,
with products already available.
Let me know if you use my code,
if you improve it, if you have or know of any
public code that does it better, if you know stuff I should know, if you want to
cooperate on java GIS, if you know who stole my Giant Iguana bicycle, or if you
are a reptile fancier who stumbled on this page because it contains the word
Virtues of downloading data to be processed outside a GIS:
Speed. Even interpreted java is 50 times as fast as TABLES for operations
I have been doing. Much of this is probably because of all those "2 records
selected" messages. I have not introduced any indices or other optimazation
methods, so results will vary widely with scale.
It is a step toward building a complete standalone public-domain system.
Faults of standalone processing:
Any hybrid system is less portable than either of its components.
ESRI may write a command to do it, or someone may find a clever workaround.
Virtues of writing in java in particular.
It will be universal and free.
It is based on C and C++, but simpler and better. A C programmer can
easily understand the guts, and a C++ programmer can understand the skeleton.
It has its own universal graphics library.
Because java is object-oriented, collaborative GIS building is more
Faults of writing in java in particular.
It requires a standalone java interpeter to work on your data.
It is not widely distributed yet.
If you want object orientation, try ESRI's
The more people learn java, the more annoying twitchy web pages we will see.