Maps are dead. Long live maps
Maps and Computers
By applying Cartesian coordinates to points and vectors along a line, it became possible to store
and retrieve two- and three-dimensional graphics in computer files. Computer aided drafting
(iaCADlg) took off in the 1970™s with major projects and software vendors responding to a
tremendous demand to retire existing paper-based maps and diagrams in favor of faster, cheaper
Automated Mapping (ipAMlg) programs. But an interesting thing happened on the way to AM
utopia. In addition to making the chore of map maintenance faster and cheaper, the new CAD
technology also made possible, for the first time, a convenient method for storing more
information than the picture alone could sustain. The concept of discriminating features into
dynamically selectable levels gave on-line map users a real sense of empowerment. When
features were grouped into logical classes and assigned to different levels, users could customize
the display of features to focus on the classes of interest for specific tasks. Furthermore, the use
of database linkages allowed select features to be linked to external database records, extending
the information that could be known about a feature well beyond what could otherwise be
portrayed by symbol or level assignment.
In the 1980™s, relational database technology found its way to automated mapping and changed
the way we thought about the linkages between graphic features and database records. Instead of
segregating feature classes for levels based only on thematic content, it now became useful to
separate points, lines and polygons so that the related database records could automatically
contain attributes peculiar to each geometry class. Lines would know at which node they
intersected with other lines, and which polygon was on the right and left side. By relating
extended attributes to this fundamental topological knowledge it became possible to construct
systems capable of answering questions like iiwhat parcels are affected by a proposed right-of-
way expansion?ll or irwhat™s the shortest route from customer X to service Y?lv Systems with
relational database extensions to automatically maintained topological pointers became known as
Geographic Information Systems (isGISlt) to distinguish them from CAD systems which had less
demanding requirements for the organization of feature geometries.
In addition to benefits derived from the topological knowledge managed in a GIS, users became
further empowered to design increasingly detailed alternate ilviewsle of the same data for
different purposes. Now, instead of storing feature symbology in a graphics file and having to
explain that iha double red line is a major highwayly, GIS users focused on storing only the real-
world attributes with the real-world geometry, and telling the system to iodraw every major
highway as a double red line.ly The difference is more than a trick of syntax. It removed the
symbol specification from the object being stored and into the realm of methods. Essentially a
stored series of instructions would decide what symbol each feature should have, and any
number of these instruction sets could be stored for any set of objects.
Figure 2 ΠMapping Innovation Timeline (2)
In the 1990™s we saw the increasing role of the relational database overshadow the role of the
graphics front-end in a typical GIS. Where once the external database was used as a way to pack
more information behind selected graphic features, now the feature geometries are treated as just
one of the many attributes an object can possess inside the relational database. Furthermore, the
sets of instructions about how to portray the featuresŠthe stored itviewslŠŠcould be stored in the
relational database, as well as the methods that should be invoked whenever a feature is added, changed or moved, in order to ensure that the system integrity is not violated. The fact that all
these components used to be thought of as very different things (the graphic features, the non-
graphic attributes, the plotting and validation programs) is now seen as a kind of historical
accident created by the until-recently-corrected inability of the relational database to hold them
all together in one place as an integrated wholeŠa place, it seems, they were always destined to
be as soon as the appropriate generic data structures could be worked out.
The significance of what happened to the graphic front-end in a contemporary geospatial
database is astonishing, given the trend towards increasing data content we plotted from the
Babylonian tablets to today. On each turn we noted the trend to increase the richness of data
content by elaborating, annotating and improving the placement of graphic objects in an overall
picture. Maps start to work only after the user comes to terms with the overall picture (this space
on the paper corresponds with a larger place on the ground), then adds to that framework layer
upon layer of additional information. The geospatial database is the last evolutionary turn in a
trend that really picked up the pace with the application of computer technology, so that the map-
as-little-picture-of-the-world framework is no longer the starting point of the user™s experience.
In its place, we have the database-as-multi-dimensional-model-of-the-world framework, in
which maps exist as ephemeral byproducts. The data behind the picture has become so intense
that it has effectively turned the map inside out.
