Title: Producing
Multiple Scale Map Products from a Single Master Database
Abstract:
AAA provides over 40 million
members with a wide variety of map products ranging in scale from downtown
views to regional atlases. AAA is currently developing a master database
along with tools for maintenance and product extraction utilizing ArcInfo
software. The new system is expected to improve consistency across
products, reduce maintenance costs, and offer flexibility to expand AAA's
product line. Part of the novelty of AAA��s approach is the concept
that a single master database will support the production of maps at multiple
scales. AAA has successfully published city and state level map products
utilizing this approach. This paper describes the concept of multiple
scale map production and the ongoing development effort, emphasizing lessons
learned and some of the solutions AAA has developed.
Introduction
The concept of producing
multiple scale maps from a single master database has emerged as an alternative
to the more traditional approach to digital map making which AAA has employed
in the past. The traditional approach utilizes a separate set of
data for each map product in the production cycle (see
figure 1). The maps are digitized at different scales, and carry
little attribute information, other than information required for symbology.
Figure 1. Traditional
Approach . Maps are maintained independent of each other. Updates
in one map are not seen by other maps.
The principal disadvantage
of the traditional approach is maintenance. A single road may appear
in a very large number of map products. Depending on the type of
edit required, the road must be edited separately in every map product
in which the road appears. This produces a logistical problem, in
that each map has its own production cycle, and edits are generally made
as a map product comes up in the production cycle. Information on
required edits must be logged, maintained, and coordinated among the various
map products affected. At any given point in time, the various map
databases may be inconsistent in terms of currency of data they carry.
Given the problems
of maintenance and consistency across map products, AAA envisioned a new
approach which would keep all current data in a Master database, from which
all the various map products could draw information (figure
2). This gave rise to the concept of maps as different views
into the same data.
Figure 2. Master
Database and Multiple Scale Map Products. Data is maintained at the
Master Database level. All maps draw on data from the same Master
DB.
Under the new approach,
every attempt is made to use data from the spatial library layers directly
wherever possible. Spatial and attribute edits to the data are map-independent
and are done at the Master Database level (figure 3).
These master database layers are filtered through visibility tables and
MAPPROJECTION but are essentially unmodified as they make their way to
the final map product. Visibility tables control what features appear
on a map, and MAPPROJECTION does on-the-fly projection of the layers to
the map product projection. The minimum set of information that must
be carried as local coverages includes features that must be displaced
for cartographic reasons, and all annotation. The expected advantage
of this approach is that all attribute and topological edits are done to
the master database and are thus available for other map products to use.
The result will be increased consistency across map products and reduced
maintenance costs. The disadvantages are increased software and data
complexity, and slower performance due to the on-the-fly projection.
Figure 3. Multi-Scale
products from a Single Master Database
Advantages of a Single
Master Database for Map Production
Immediate benefits for
map production:
-
Automate Map Production
-
Automate existing
business rules for map content and layout
-
Data-driven mapping
-
include or exclude
features based on feature characteristics and map type
-
symbolize depending
on feature characteristics and map type
-
Topological integrity,
necessary to support routing and geocoding
-
Maintainability:
eliminate redundant updating. If a feature needs to be edited, it
should be done only once, and the change reflected in all map products
where that feature appears.
-
Consistency:
Since all maps share a common spatial database, features are consistent
between products.
Additional benefits beyond
mapping:
-
Tie various in-house databases
together, adding a spatial dimension to existing attribute databases.
-
Increase access
to data between departments.
-
This GIS-enabled
data will support internal corporate applications
-
Emergency Dispatch
-
Vehicle Location
-
Travel Routing
-
Electronic publishing
opportunities
-
Creating new, improved
paper and digital mapping products
-
Internet services
-
CDs
-
In-vehicle navigation
Components of the Map
Production System
Seamless National Spatial
Database
The Master database is
stored in a Spatial database system, such as Librarian, ArcStorm, or SDE.
ArcStorm offers the advantage of feature-based locking for managing edit
transactions in a multi-user environment. SDE offers advantages of
speed and the ability to handle very large datasets.
The spatial data is
stored in a common projection suitable for a nationwide database.
Business rules
An essential part of creating
an automated system is a clear definition of the business rules that govern
map standards, content and appearance. This includes identification
of all the different map types, map sizes, and border styles, analysis
of what kinds of features appear on what types of maps, and how those features
should be symbolized.
Extraction rules and
visibility tables
Extraction rules are automated
expressions of the business rules which dictate what kinds of features
appear on what kinds of maps. Once the extraction rules have been defined
as business logic and coded into the system, any kind of map can be created
with minimum user intervention.
The extraction rules
automatically create visibility tables based on map type and map scale.
Together, extraction rules and visibility tables determine what features
appear on any particular map product. Visibility
tables are files containing pointers to specific features in the master
database. Our convention for visibility tables is one visibility
table for every layer in a map view. Visibility tables are used to create
selection sets, and selection sets define what features appear on a map.
The extraction rules
do a standardized job of setting up the visibility tables, but the operator
has an opportunity to fine tune the visibility tables by adding or removing
features as required for a map product.
This is both
the simplest and most effective technique in the master database concept.
By using visibility tables, we are effectively able to apply a filter to
our database, allowing only the features that we want to appear on a map.
Map View projections
and the MAPPROJECTION command
Our business rules state
that every map view (or inset) in a map product may have its own projection.
The master database is stored in a projection suitable for a nationwide
dataset. This means that the data must somehow be projected from
the master projection into a map-specific projection. The traditional
way to do this would be to create a local coverage and convert it directly
into the desired projection. However, since we want to rely on the
master database as much as possible, we are using the MAPPROJECTION command
instead. MAPPROJECTION allows you to specify the desired output projection
(in this case the map-specific projection) and utilize data which is stored
in a different projection. This projection transformation is done
on-the-fly, without altering the original data.
The only disadvantage
to using the MAPPROJECTION command is that there is a time penalty for
doing the on-the-fly projection. The time penalty is sometimes negligible,
sometimes significant, depending on the size and scale of the map.
So far, the performance has been tolerable, but of all the processing required
for this multiple map product concept, the MAPPROJECTION command is the
most time consuming. However, in order to gain the advantage of maintaining
one single master database, the extra processing time is acceptable.
A Minimum Set of Local,
Map-Specific Coverages
There are cases where,
for cartographic reasons, features from the master database need to be
manipulated to enhance their appearance on a particular map product.
Examples where this may be necessary include:
-
road segments, points
or areas of interest which must be displaced for cartographic reasons
-
text placement,
which is closely tied to map type and scale
-
features which must
be generalized to increase clarity and map legibility
At present, these features
are maintained in small, product-specific coverages. It is possible
that this map-specific information may be beneficial to other maps of a
similar type scale. We are investigating ways of maintaining this
information within the master database as well, with tags to identify the
map type and scale for which the features are appropriate.
Text Placement
Text placement is critical
on a published map product. Some Internet mapping applications use
automated routines that do a reasonable, but not very precise job of labeling
streets and other features. The public has so far been fairly tolerant
of text placement on Internet maps. However, labeling must be done
in a muich more aesthetically pleasing manner for a printed map product.
Text placement is one
of the lengthiest stages of production, particularly on a city map where
every street has to be annotated. Text is also the single largest
set of data that we currently carry outside of the master database.
As it stands today, text is one of the last remaining exceptions to our
concept of deriving multiple scale map products from a single database.
We use automatic text
generation routines followed by a process of manually fine-tuning the text
placement to produce a satisfactory map product. We are hopeful that
products such as Esri's Maplex will be able to provide high accuracy for
automatic text generation. However, text placement and repositioning
of automatically generated text continues to require manual operator intervention.
When high-quality automatic
text placement is a reality, a very manual and labor intensive part of
our production process will go away, and we will be much closer to the
concept of fully automated, data-driven map production.
Geographic Storage:
ArcStorm and SDE
The solutions for spatial
data storage were ArcStorm and SDE. ArcStorm offers feature locking,
which enables you to have a number of people editing the same database
without fear of overwriting or conflicts. SDE on the other
hand is intended for very large data sets and fast spatial queries.
Ideally, we would like to have a spatial database that is good for very
large datasets, offers feature locking, and supports fast spatial and attribute
queries, and fast display speed.
Feature locking is
an absolute requirement, particularly in the early phase of this project
when edits to the database will be more frequent. However, as the
size of our database grows, we expect to move our data into SDE.
ArcStorm is not intended for large datasets. In the early phases
of our project, ArcStorm seemed like the right solution, but as the size
of our database grows, and interest in our database grows within the organization,
the display and query speed of SDE is becoming increasingly important.
Although it does not offer feature locking, SDE does have spatial locking,
and we believe that this will be sufficient to meet our needs. The
other advantages of SDE, particularly its ability to handle very large
datasets, are compelling reasons to move towards this technology.
Obviously, if a future release of SDE supports feature locking this would
be the best of both worlds.
Data Storage Issues
Esri��s ArcStorm was chosen
to manage data for the map production system for the following reasons:
-
Multiple users being
able to simultaneously access data for edits is almost a necessity for
the map production system. Short of using an RDBMS and its sophisticated
mechanisms to ensure concurrency, this was the best tool available for
managing coverage data.
-
ArcStorm��s ability to
perform feature level locking is essential, especially during the initial
stages of the database construction.
-
Currently, the map production
system is heavily dependent on ArcInfo and its data structures. It
was felt that using ArcStorm to manage data as opposed to an external RDBMS
would mean greater ease in the manipulating data and would result in a
better overall performance.
In spite of the above
mentioned reasons, using ArcStorm has not been without its challenges.
Following are some of the issues that have prompted a reconsideration of
the choice to use ArcStorm:
-
Performance has
always been a major issue in a number of implementations of ArcStorm.
Simple commands like mapextent in Arcplot of a library layer may take a
long time. Checkin and checkout operations may be so time consuming
that users may be reluctant to initiate a transaction.
-
The strong point
of any database is its availability. Having to take the entire database
into single user mode to create a new layer, or load data into a previously
created layer has been creating a lot of scheduling problems for the map
production operations, especially since the database is being created for
the first time.
-
A number of show
functions require that the user be connected to the database. When
an installation has a limited number of ArcStorm licenses and the number
of users accessing the database is high, even if purely for read-only purposes,
this requirement by the software causes problems and time delays.
-
From an application
development perspective commands such as ASEXECUTE need to be converted
into functions with a return type. When an ASEXECUTE <database>
EXEC fails, it is always better to check the return status rather than
depend on the &SEVERITY.
Is migrating to SDE the
solution? This question is seriously being considered for the map
production system. The database design that is being used for the
ArcStorm implementation is being altered to be amenable to an SDE database
design in the future.
-
One of the main
benefits of migrating to SDE would, of course, be the performance boost.
For a centralized database of this nature that caters to not only the cartographic
department of the organization, but also to the rest of the enterprise
and eventually the public via internet, performance is paramount.
-
SDE��s dependence
on an external RDBMS for its security issues is being seen as an added
benefit in view of the tremendous amount of man and machine hours being
invested into adding value to the data.
-
Using SDE, the master
database is expected to be much more available than it is currently.
-
Modifications to
the database design are expected to help accomplish feature level locking
for the map production system.
-
AAA value addition
to topographic data includes both tabular data as well as rich data content.
The new generation of Universal database servers in conjunction with SDE
are expected to spawn a whole new family of applications for the data being
collected by AAA and its agencies.
-
Since the spatial
data is stored in an external RDBMS, non-GIS applications can access the
data with ease without having to use any of the map production system applications.
This is expected to establish the database as a truly enterprise wide data
repository accessible to every department.
Conclusion
The concept of creating
multiple scale map products from a single database is viable. The
system has successfully generated maps in different scale ranges from the
same master database. The maps produced by the system have been published
and are available for distribution to members. We have faced a number
of challenges along the way, but so far we have been able to overcome these
challenges and proceed with the system as planned.
Miguel Garriga
mgarriga@national.aaa.com
Senior GIS Analyst, GIS/Publishing Development & Support
AAA
Hari Koduru
hkoduru@national.aaa.com
GIS Analyst, GIS/Publishing Development & Support
AAA
1000 AAA Drive
Heathrow, FL 32746