EMAPS is an object-oriented environment designed
to manage grid cell geographic information and to visualize site
planning design proposals and environmental impacts, using a variety
of representational approaches. The object-oriented approach
to GIS and graphics enables a variety of views -- plan, perspective,
illustrative or diagrammatic, static and dynamic -- within a modular,
interactive system. Rather than pursuing 'photo-realistic' simulations,
we are interested in how abstractions and representational conventions
can be used to gauge visual and environmental impacts of proposals
for landscape change, in a dynamic, interactive computer-aided
design environment.
Stephen M. Ervin
Department of Landscape Architecture
Harvard University Graduate School of Design
48 Quincy St. Cambridge, Massachusetts, USA 02138
email: servin[@]gsd.harvard.edu
Introduction
Landscape planning and design decisions -- such as
those related to new housing and infrastructure development, waste
management or energy facilities, transportation corridors, forest
and wildlife management, etc. -- must be made with the help
of a variety of models and modes of representation. Traditional
software development has tended to segregate design, analysis
and evaluation into products, such as 'GIS', 'CADD', 'Image Processing',
'MultiMedia', video animation technology, and others. Typically
these are combined in various ad-hoc ways by designers and planners;
linking separate software modules together, often imperfectly,
to produce visualizations in the process of analyzing geographic
data and formulating design proposals (1).
The power of images -- maps, plans, diagrams, photographs
-- is well established, and the need to produce a assortment of
them in the course of any planning and design investigation is
paramount. In GIS and CADD technology, the needs of end-product
cartography and three-dimensional visualization have been relatively
well attended to, especially at the high-end. For in-process
and multi-modal visualization, however, most software
products provide fewer and less flexible options. This article
describes an environment designed to provide user-customizable
displays of raster geographic data, that is, data recorded as
a regular array of values of one or more thematic observation(s)
over some geographic area. This kind of information is gathered
by several different remote sensing platforms (typically satellite
or airborne) and used extensively in natural resource assessment,
regional planning and large-area landscape design. Together with
appropriate image processing procedures and cartographic modelling
techniques (2), which can be used to alter and interpret the raw
data, raster geographic data can be used equally well for analysis,
design and evaluation (3).
The two most common forms of display of these data
are illustrated in figures 1 and 2: an overhead plan view, in
which values are represented by rectangles colored according to
some key, and an oblique aerial perspective, in which a thematic
map such as in Figure 1 has been 'draped' over a fishnet mesh
derived from a second map of elevation values. These are typical
of the highly abstract models produced by many GIS systems.
These kinds of 'maps' are simple and familiar, but limited. A
principal reason for producing displays during design (or in any
act of communication) is to support or encourage visual inferences
across a range of scales and levels of abstraction, whether for
oneself, or in communication with others. A comprehensive environment
for operating on geographic data should provide for a variety
of kinds of displays, tailored to their intended purpose(s).
These displays should be amenable to user customization in a friendly,
flexible, consistent manner -- that is, they should be provided
by something like 'macros' with the rigor and expressive power
of a good programming language. We are increasingly in a world
where it makes less and less sense to write a whole new program
for each analysis.
EMAPS
The EMAPS system was developed in response to this need for a
flexible, extendable, user-modifiable GIS with facilities for
both displaying and modelling geographic data (this article is
primarily about the display capabilities.) EMAPS is written
in object-oriented Common Lisp (4), presently running on a Macintosh
computer. A hierarchy of objects -- windows, maps, cells --
takes advantage of the class-instance inheritance and generic
methods of Common Lisp to allow easy prototyping and exploration
of variations. The combination of a class library of objects,
a protocol for accessing them, ready access to the full display
capabilities of the computer (in this case QuickDraw), and the
interpreted nature of Lisp make for an interactive environment
for exploration of geographic information and landscape visualization.
The conceptual structure of EMAPS is simple and the list of primitive
objects is small:
A window is an object capable of performing computer graphics for display. It has characteristics such as size, colors, bit-depth, etc.
A map is an object representing the spatial distribution of some attribute(s) as a rectangular array of cells. Each map is capable of displaying itself in a window, and has a list of characteristics such as name, thematic content, scope, scale and resolution, etc. Each map is linked to a key and made up of cells.
A cell is an object which represents a (rectangular) spatial extent on the ground and encodes an attribute or attributes for that extent. Each cell has a value (or values), and one or more methods for displaying itself in its map's window, and reporting or changing its value(s).
A key
is an object that basically implements a two-column table, providing
a lookup between a value or range of values and a display attribute,
such as a symbol, color, pattern, etc. The key
is used when a map
or a cell is displayed in a window.
In EMAPS, each map
is composed of a number of cells,
typically arranged in a rectangular two-dimensional array as in
an ordinary raster grid-cell map. The cells need not be all the
same size, nor need they correspond to patches of ground actually
arranged in a rectangular array, but these are common conventions
that simplify some computations. For example, in such a system
each cell has at most eight immediate neighbors, which are physically
adjoining and whose coordinates are easily computed. (Arbitrary,
non-adjoining 'neighbor'-lists may of course be specified for
any cell. Underground water-flow, for example, may connect spatially
distant areas in the landscape.)
In its simplest formulation then, EMAPS simply provides
a raster GIS capability. Since its underlying language is Lisp,
which does not require declaration of variable types, and indeed
can handle any size or kind of number (4), the cell values are
not restricted to integers in any range -- cell values may be
integers, floats, bignums, or even characters or strings. Naturally,
some penalty in speed of computation is paid for this flexibility.
Since the display functions are customizable -- as are all cell-access
or update functions -- it is the responsibility of the display
function to take into account the possible variable types of cell
values and display them accordingly. procedures.
It's important to note, however, that in EMAPS, cell
values are in fact procedures, not simply values. In its
general form, a cell
is an object which can respond to the request 'What is your value?',
or the message "Set your value to X", as well as other
messages, such as "Display yourself in window W". Depending
on the time and form of the request (or message) the cell's response
may vary. The precision, for example, of a numeric value may
vary: under some conditions, an integer may be returned, under
others a full double precision value, under yet others, a 'qualitative'
value of -1, 0, or +1, simply indicating polarity. These 'conditions'
may either be embedded in the request itself, or determined by
some global value(s). In this way, each cell is in fact a 'cellular
automaton' (6): an object with a state which may change as some
function of a number of inputs, typically derived from other automata's
states. Cellular automata provide a reasonably well-understood
general model with considerable potential (6) for managing and
exploring geographic information and phenomena .
With the hierarchy of method-dispatch and inheritance
procedures provided by Common Lisp, it is possible that there
is only one display function inherited by all cells; it is equally
possible for each cell to have its own unique display procedure.
The most common condition is in between - that different classes
of cells have different display
For a simple plan map, the display function just
draws a filled square (rectangle), colored according to the cell's
value as in figure 1. The color is derived by asking the map's
key to match a value; a key is just a lookup table that given
a value returns a color (or a pattern, or a symbol, as below).
These colors may be some conventional set, such as those used
in standard land-use maps, or may be customized for the purpose
at hand. The choice of colors may be guided by cartographic convention,
or may in fact be an important design/communication decision.
For a perspective map as in Figure 2, each square is first subdivided
diagonally to produce two triangles; the triangles' vertices
are assigned z-values from a second map, and the coordinates are
passed through a perspective transformation using ordinary matrix
techniques. Simple cosine shading may be used to alter the intensity
of color in each triangular facet according to a single point
source of light, to heighten the perception of depth and surface
orientation. Drawing cells in order from back to front effectively
uses the 'painter's algorithm' of hidden line/surface removal.
But cell display functions can do more than just
draw rectangles. Figure 3 shows an 'arrow map' produced by modifying
the graphics display procedure for cells, such that each cell
draws a two-dimensional vector with an arrow-head in its grid
position; the angle of the vector is determined by the cell value
(modulo 360). Such a vector-field map may be used to visualize
orientation, or aspect, of a topographic surface, or water flow
over such a surface, or indeed motion of any sort (wildlife movement/migration,
e.g.) in the field.
The map of figure 3 is an example of an arbitrary drawing function
embedded in each cell (the same in each cell, in this case.)
There must be a Lisp function for drawing arrows, that has access
both to the low level graphics of the computer platform, and to
some global values (like maximum line length, angle of arrow-head,
etc.). Such graphics functions are relatively easy to construct;
EMAPS provides overhead support for many simple wire frame and
polygonal objects, but the potential variety of drawing functions
is limitless.
Cell display functions need not be limited to these flat abstractions such as rectangles and arrows. In order to get at the question of "What might it look like?" for landscape planning and design, we have developed a set of cell display procedures that produce pseudo-three-dimensional symbols: buildings and houses of varying densities and overall form, several types of vegetation, smokestacks and parking lots, for example. These symbols, corresponding to land use codes, can be arrayed in three-dimensions, over a digital terrain model, to provide a preliminary 3-d analysis of the (possible) form of proposed site plans. For trees, we have both polygonal faceted models, that can be exported to polygonal solid modelling/simulation software, and bit-mapped equivalents which are somewhat more 'realistic' looking and faster to display, especially on low-end (Macintosh) displays. Figure 4. shows a sampling of some of these simple polygonal and bit-mapped figures. These figures are easily imported from two-and three-dimensional modelling software as lists of faces and/or vertices or as scanned rectangular bit-maps.
In some cases, a window incorporates information from two maps, as when land use is draped over terrain. In this case, EMAPS effectively sets up communication between the two maps, so that the first produces a terrain model, the second the coloration or set of three dimensional symbols. Figure 5 shows a composite perspective view of a landscape plan produced in this way. In this view, elevation data has been rendered as a triangulated underlay, (triangulated as described above) colored by a map that combines land cover and hydrology (different kinds of forest are colored different shades of green, different kinds of water features different shades of blue, and so forth.) On top of this terrain, vegetation is represented by simple two-dimensional symbols produced with a slight random variation in size and shape; buildings, residential and municipal, by three-dimensional block figures. While the back-to-front algorithm works (mostly) for the overall image, within each cell the facets must be depth-sorted back-to-front, a time consuming but necessary step. Some minor perspective anomalies may remain, but for preliminary visualization purposes these are generally irrelevant. When the model is passed to a more sophisticated three-dimensional rendering environment these can be eliminated.
Using simulations such as these, judgments can be made at the
preliminary design stage about dimensions and densities of view
corridors, buffers, height limitations, vantage points and special
views. In this sense, the visual evaluation becomes just one
more in a suite of evaluation models used to inform the design
and planning process. These views are understood to be approximations;
more realistic than just plan views, but more schematic than
'photo-realistic' renderings or presentation drawings.
An additional use of this set of techniques is to begin to visualize
change over time, using color cues along with animation. Figure
6 shows three more views of the same terrain as in figure 5, but
set in three other seasons seasons: fall, winter, spring. In
each case, the underlying data have not changed, only the viewing
parameters have. That is, different symbols have been substituted
as appropriate (bare branched deciduous trees in the winter, sparsely
foliated in the spring and fall) and color palettes have been
changed (fields, for example, are white in winter, bright green
in spring, medium green in summer, and tan colored in the fall.)
These visualizations are the most 'life-like' in their intent,
as they give a feeling of different aspects of the landscape at
different times of year (albeit from a distance in the air).
Other dimensions of the landscape -- such as visibility distances,
or sun/shade pockets, 'sense of enclosure' or 'view of water',
also change with the seasons, and these analyses could be overlaid
on the substrate of the colored landscape to add to the visualization
of the landscape character in many of its dimensions.
We have carried this integration of visualization and analysis
one step further, providing a way of viewing proposed changes
in the context of their impacts. Design decisions can be represented
as values in a raster (proposed new land uses), and some measure
of the impact of proposed changes can be evaluated using appropriate
cartographic models. One version of such an evaluation can yield
a 'qualitative' impact, ranging from beneficial, through benign
to harmful and disastrous, for example. Then an 'impact map'
can be produced, using an evocative color coding scheme -- red
for Bad, green for Good, yellow for Neutral, for example. This
color-coding scheme is by no means universal (no color scheme
is), but within a culture of viewers used to traffic lights, for
example, easily understood. These color codes for impact can
then be used to tint the three-dimensional landscape. Thus trees
and structures in zones with benign impacts appear green, whereas
in negatively impacted areas they appear in orange or red (in
disaster areas). This approach -- wearing virtual 'rose-colored
glasses' -- is simple but effective. Patterns of impacts that
have an element of geographic or spatial correlation (such as
along drainage courses, or ridgetops, for example) are made obvious
in this approach, and seem much more immediate when seen in pseudo-three-dimensions
than when simply presented as a colored impact map. Figure 7.
shows a portion of a red,yellow and green landscape (in which
"near road" = red, "water or far from road"
= green).
In addition, once these sites are projected into three-dimensional
surface- or solid- models, it is possible to use other CADD and
image processing software to enhance the three-dimensional understanding
of the proposal; for example, by providing animated walk-throughs
or fly-overs of the site. We use the POLYTRIMS visualization
and animation software for the SGI Personal IRIS, developed by
the Centre for Landscape Research at the University of Toronto
(7). Using this hardware/software combination, it is possible
to generate real-time animations of complex scenes represented
as three-dimensional planar polygonal surfaces. A simple ASCII
interchange file format provides a syntax for descriptions of
polygonal facets (coordinates and color) for the POLYTRIMS software.
Once the proposed site plans have have been generated on the
Macintosh, and converted onto the IRIS, the designer can fly,
drive or walk through or around her plan, to evaluate the overall
form and visual impact of the proposal. The images produced are
rough in many ways: all trees and buildings are alike and rather
diagrammatic; colors are shaded but there is no provision for
the subtleties of texture or curved surfaces; the ground is broken
up into half-acre colored triangles, to name but a few of the
visual objections . These representational conventions are no
more limiting than any others commonly used in design processes,
however, and are no more difficult to "see through".
Similarly, we can animate motion through the false-colored landscapes
described above, using the speed and graphic power of the IRIS
computers, and the interface developed for the POLYTRIMS program.
Walking from the green forest into the red housing and parking
area, or taking a drive along a road and watching the hilltops
along the road to see if the highly impacted landscape is visible
in red, are both more personal and engaging than simply seeing
a viewshed analysis. It is this engagement that gives the power
to this form of visualization.
CONCLUSIONS
The idea of object-oriented GIS is simple and appropriate: maps
are objects with behavior, and a GIS or a cartographic model is
simply a collection of specified maps with specified relationships
between them. For raster format data, maps are composed of cells,
and cells have behavior. In simple raster maps, all cells are
essentially alike, with similar kinds of values and display functions.
For more complex modelling and simulation purposes there may
be many 'species' of cells, with different behavior, and different
display functions. Both these options are equally well supported
by the interactive, extendable characteristics of EMAPS (derived
from the underlying Lisp).
EMAPS manipulates raster data, and the map-cell hierarchy is
an obvious one. But there is no conceptual reson why the objects
that comprise a map should not be 'vector' objects as well. Points,
lines and polygons are equally well modelled with the object-oriented
approach. Some features in the landscape such as roads and streams
are quite poorly represented when rasterized - both in their behavior,
and their appearance - so we are now extending the functionality
of EMAPS to include integrated vector objects along with (or
on top of) cell objects. The raster vs. vector decision is not
an ideological one, but a functional one based on the characteristics
of the data we are interested in representing.
Making design decisions in this object oriented environment enriches
the process over conventional raster modelling. That is, rather
than simply assigning a land use code, with some summary statistics
attached, one can assign behavior as well. Using a variety of
kinds of cells, with different behavior, opens up many possibilities
for design and modelling of complex environments. Likewise, the
impacts of such design decisions can be evaluated from many viewpoints,
using different methods: objective metrics may be available for
impacts, as in standardized Environmental Impact reports; for
other impacts, visualization and subjective assessment are appropriate.
Once a landfill design has been established as acceptable in
its environmental impact, for example, several more design questions
remain, such as "Can it be seen from the road?", and
"What might it look like?"
We stress that the visualizations so produced are attempts to
answer the question "What might it look like,
rather than "What will it look like? The three-dimensional
images produced by EMAPS are schematic, as described above. Nonetheless,
these simulations may be remarkably informative and useful. We
are more interested in the forest than in the trees! So we are
not even approaching the question of 'photo-realistic' visual
simulation, with its technical complications (ray-tracing, surface
texture mapping, shadow casting and all...), and its deep-seated
theoretical problems (who says what constitutes realism,
anyway?). Instead, we are producing the equivalent of a designer's
thumbnail sketch, cross-section or doodle. This has undeniable
value in the design process, but no overly great weight is placed
upon it - - these images are ephemeral and mutable at will --
designed for change and recycling, rather than as finished renderings.
This is not to say that the three-dimensional substrate so created
could not be used as the basis for more finished renderings --
only that we do not at present use them that way. Questions about
design process -- "When are what graphic products produced,
and for whom?", for example -- are raised, but not answered,
by our efforts.
These representational conventions -- abstractions, simplifications,
false-coloring among them -- are important both in design education
and in design communication. What is important for both design
students and designers and planners communicating with others
(including 'laypeople') is the use of representations to support
ideas, points of views, emphases, etc. By providing a rich and
variable reporetoire of such conventions, EMAPS supports a variety
of forms of communication. Inherent in all communications is
the danger of misinterpretation, and especially when one image
stands in for many words the dangers are inc reased. False coloration
may be especially confusing for novices, and most appropriate
for limited and pointed usage. But for years the 'artists rendering'
has been treated as 'objective' (or at least been treated as news
rather than advertising in many newspapers). The advent of computer
graphics has simply extended the possibilities for abuse, rather
than raising any whole new issues iun this regard.
EMAPS, with its methodology linking planning scale analysis with
site-scale three-and four- dimensional simulations offers promise
for integration of techniques commonly understood as disparate,
labelled GIS, or CADD, or visualization, etc. An important aspect
of this enterprise is to provide a modelling environment, and
not just a representation or visualization tool. This object-oriented
approach to modelling and displaying geographic data adds one
more set of elements into the rich and complex soup of models
and abstractions (9) used by designers and embedded in GIS.
This idea, of multiple views of evolving models, is the best underpinning
for comprehensive computer-aided design, whether it's called CADD,
GIS, or anything else.
REFERENCES
1. R. Gimblett, "Linking Perception Research, Visual Simulations and Dynamic Modelling within a GIS framework: The Ball State Experience", Computers, Environment and Urban Systems Vol 1, 1988 pp 109-123.
2. D. Tomlin, Geographic Information Systems and Cartographic Modelling, Prentice-Hall, 1990.
3. S. Ervin,"Teaching Theories and Methods of Landscape Planning with low-cost GIS", in CELA Selected Papers, Vol. 3, 1991
4. G.L. Steele, Jr. . Common Lisp The Language,Second Edition, Bedford, MA: Digital Press, 1990
5. T. Toffoli and N Margolus. Cellular automata machines : a new environment for modeling. Cambridge, Mass. : MIT Press,, 1987.
6. R.M. Itami, "Cellular Automatons as a Framework for Dynamic Simulations in Geographic Information Systems", in Proceedings, GIS/LIS, 1989.
7. J. Danahy, "Irises in a Landscape: An Experiment in Dynamic Interaction and Teaching Design Studio", in McCullough, Mitchell & Purcell (Eds) The Electronic Design Studio, Cambridge, MA: MIT Press, 1990
8. C. Steinitz, "A Framework for Theory" Landscape Journal, Spring 1990
9. R. Van Der Schans, "The WDGM Model, a formal Systems View on GIS", International Journal of Geographical Information Systems,v.4.no.3, 1990 pp 225-239
10. D. Norton and E. T.Slonecker, "The Ecological Geography
of EMAP", Geo Info Systems, November/December 1990
ACKNOWLEDGEMENTS
The development of EMAPS has been supported by an equipment grant
from the Milton Fund of Harvard University, and by the particularly
comfortable and productive programming and prototyping environment
provided by Macintosh Allegro Common Lisp.
Note: The similarity in name to the 'EMAP' GIS project of the
US Environmental Protection Agency (10) is entirely coincidental;
EMAPS is named (sort of) after the programmable text editor EMACS,
written by Richard Stallmann of the GNU Software Foundation.
EMAPS is to maps as EMACS is to text.
BIOGRAPHICAL SKETCH
Stephen M. Ervin is an Assistant Professor in the Department
of Landscape Architecture at the Graduate School of Design, Harvard
University. His teaching responsibilities are in the areas of
design computing and technology, including Geographic Information
Systems and Computer Aided Design. His research interests are
in the roles of representation in design design processes and
the development of dynamic interactive design support systems.
He holds a Master's degree in Landscape Architecture from the
University of Massachusetts at Amherst and a PhD from the Massachusetts
Institute of Technology. He may be reached via email at: servin@gsd.harvard.edu