Storing and Serving GIS Data

Here's the text of the message I sent to Ruth, Dirk, and John Stuckey in June:
The following explains why I think the /gis/ folder on Miley needs a uniform drive letter assigned to it.

The ArcView site license should encourage lots of people to start thinking about making and using maps, and will also result in the purchase and creation of substantial numbers of digital map files and ancillary images. We want to store and distribute these in an efficient and expeditious manner, and so need to work out some routines. It seems entirely appropriate to use Miley as the main server for GIS coverage --since it was established specifically to provide for image data in various forms. A /gis/ directory now contains a goodly amount of GIS data.

By their very nature (being large graphics files of various sorts) GIS images are somewhat clumsy to deal with. For example, a topographic quad is probably about 6MB, so it's really desirable to avoid having lots of copies of it taking up network space. One way to accomplish this is to make use of ArcView's "project" files (.apr), which are generally quite small (10-20K) and serve as pointers to the large files. Thus, a 6MB geoTIFF of Sherando quad is located on the L: drive in /biology/gis/ (it's under the cryptic name "o37078h8.tif"); if one has Netscape configured to recognize .apr as an extension that launches ArcView as an application, the URL http://www.wlu.edu/~hblackme/giswork/test.html has a link which (a) invokes the .apr and (b) opens ArcView with the Sherando quad displayed --and displayed as the creator of the project saved it (e.g., zoomed to a particular feature). Thus, a user may retrieve a map and perform various actions on it (add layers, change extents, etc.), and can then save the result as a NEW .apr project file, and a third person can then retrieve and use that derived project --all drawing upon the original geoTIFF image.

The problem of the moment with Miley is that it has to be mapped by each user individually --I have it as O:, John Blackburn has it as P:, and so on-- so that an .apr (which points to the location of the image on which the project is based) can't be shared. The solution, clearly, is to have a uniform drive mapping for Miley's /gis/ directory (all the rest of Miley will remain off limits except for Web access). Other contents of the /gis/ directory, in addition to maps and images for general use, would include the ArcView executables (it seems more sensible for people to install and run ArcView locally, rather than over the network, though we understand that lab machines would have ArcView installed as part of the standard setup) and other GIS tools (Microdem is a good example).

Fairly extensive work remains to be done building web pages to support learners and experimenters who venture into the waters of GIS. The humble beginnings are at http://miley.wlu.edu/gis/ and an image-based navigation scheme is in the works for locating and retrieving GIS data (http://miley.wlu.edu/gis/datalocator/indexmap1.html at the moment, for our holdings for the state of Virginia, though the same locator scheme will eventually be extended to provide access to the whole array of GIS data holdings). I'd like to start making .apr files to fit with John Blackburn's work on the locator maps, but until there's a uniform drive letter for the /gis/ folder it's not sensible to do that work.

Two months later, it's really time to start organizing this material. Some categories are pretty obvious: The organization of this trove will of course be handled via web pages, which will also contain pointers to tutorials for the many things people might want to do.