In addition to modularity, memory and storage constraints were also of concern when designing LUCAS. The single largest performance bottleneck in LUCAS is disk I/O. Reading and writing each row of each map layer requires disk accesses, therefore as few accesses as possible were used. Internally GRASS uses run--length encoding (RLE) [10] to compress the raster maps, which takes advantage of repetitions of the same cover type in a map layer, which further saves on disk I/O. The routine which demands the most memory is the statistical patch identification algorithm which requires an entire map layer to be in memory. A patch is a group of contiguous grid cells with identical LCLs.
These potentially large maps made loading the entire composite map into memory unfeasible and necessitated a row--oriented approach to analyzing and manipulating the maps. Fortunately the underlying GRASS routines already dealt with maps in a row--oriented fashion, so working with the ``composite'' map and the resulting GRASS land-cover map was simplified.
Another issue was portability, as a parallel version of LUCAS running
in a heterogeneous environment was planned (see
Section 6). Fortunately, the strong type checking of C++
lends itself to more standard, portable code.