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

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 computer languages. 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.

    ARCS

    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 class that 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 check it, 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.
    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 Iguana.

    Virtues of downloading data to be processed outside a GIS:

  • Flexibility
  • 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 feasible.

    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 Avenue
  • The more people learn java, the more annoying twitchy web pages we will see.