GRASS was chosen to be the GIS used in the development of LUCAS for several reasons:
First, GRASS is able to import a variety of data types. The remote
satellite imagery used to generate the GRASS vegetation map layers
used in LUCAS was purchased from EOSAT, a company which distributes
Thematic Mapping (TM) and Multi-spectral Scanner (MSS) satellite data.
These images were interpreted for land cover using a software package
called ERDAS [7]. This format could readily be converted to
a native GRASS format with the GRASS utility r.in.erdas. Other
geographical map layers, such as slope, aspect, and elevation, were
originally in Digital Elevation Model (DEM) format and were imported
via m.dem.extract. The land ownership data was in
ARC/INFO
format and was imported using v.in.arc.
Finally, the population density maps were originally in
TIGER/line
format and were subsequently
converted to ARC/INFO and imported into GRASS in the same manner. The
ecologist preparing these maps also used many of GRASS's map
manipulation tools to create data layers, such as the distance from
each point to the nearest road, which required a simple distance
calculation for each grid cell.
Second, the source code for GRASS is provided in the software distribution. In developing LUCAS, there were many instances in which features or techniques were not fully documented which made the availability of the GRASS source code invaluable. A greater understanding of the functionality of GRASS was thus also gained. The source code also enabled a few GRASS routines to be adapted and integrated into LUCAS, avoiding the unnecessary rewriting of programs. Another benefit of the availability of the source code is the relative ease of software portability.
The final reason GRASS was selected was one of sheer economics. Because GRASS was developed with governmental funds, it and its source code are freely available from USACERL. If a commercial package such as ARC/INFO were selected, the source code would not necessarily be included in the distribution and licensing fees would effectively make each copy of LUCAS cost-prohibitive.
GRASS is not a perfect tool, however. As a non-commercial package, many bugs persist in the code. For example, the GRASS X-windows monitor often functions properly under SunOS 4.1.3, but not under Solaris 2.3. Some of the features of GRASS are not well documented, which again made the availability of the source code invaluable. The GRASS environment works well for someone with knowledge of UNIX and programming but would be rather challenging for an ecologist or land manager without such skills. In spite of its many foibles, GRASS is a useful environment in which to work and program.
LUCAS was built on top of the GRASS libraries, so switching to another GIS would be difficult, but not impossible. Replacing the map access routines would be straight forward, but the graphical display code would need to be completely rewritten. Naturally the algorithms and methods comprising the essence of the LUCAS simulations would remain the same, regardless of the GIS being used.
Figure 1: Example of the GRASS storage hierarchy