Product Generation-Enhanced: National Mapping Division's Next Evolution in Graphic Production Systems

Background

Since the late 1980's, the U.S. Geological Survey's National Mapping
Division (NMD) has been developing the feature-based digital line
graph (DLG-F, formerly DLG-Enhanced) data model in response to user
requirements for feature-based data.  The NMD has now begun a
transition from the DLG-3 data model to the DLG-F model.  In line with
this transition, the NMD is developing several systems to support
DLG-F implementation.  Included among these systems is the product
generation-enhanced (PGE) graphic production system.


Although the primary focus of PGE system development is the production
of graphic products from DLG-F data, system development is also driven
by requirements for automation and flexibility.  The requirement for
automation is due to the ever-present goal of increasing production
efficiency.  This goal is especially critical where current
expectations entail doing more with less.  The requirement for
flexibility is in response to the rapid changes in today's spatial
data environment.  The PGE system must be able to adapt quickly to
these changes.


Standards-Driven Approach

To accommodate requirements for automation and flexibility, the PGE
system applies a standards-driven approach.  Unlike most previous NMD
production systems where product specifications were hard-coded into
the software, the PGE system applies a methodology that is independent
of a specific set of standards.  Fundamentally, the PGE system is a
toolset of processing, editing, and plotting functions that are
separate from the product standards.  To apply product specifications
to a dataset, load both the dataset and the product standards from
external sources.  The processing functions then apply the product
standards to the dataset.  If product standards change, simply load
the revised standards into the PGE system.  This approach allows the
PGE system to be very flexible regarding changes to standards.


This standards-driven methodology was adapted from that originally
used in the DLG-F production system, NMD's vector collection and
revision system for DLG-F data.  In conjunction with developing the
DLG-F production system, the NMD designed and built a standards
database that explicitly defines its DLG-F products.  The DLG-F
production system loads and applies these standards in the collection
and revision of vector data.  PGE system development has extended this
approach to include graphic products.


The PGE system supports system automation by using standards to drive
automated processes.  Standards-driven automation can be as basic as
automatically associating a feature with a specific symbol for
plotting.  However, the approach is taken much further with the
application of conditional rules.  Data are analyzed for specific
cartographic conditions that may require data modification based on
the situation.  This use of conditional rules is particularly useful
in the complex processing associated with generalization.


Conditional rules in the PGE system follow a simple database table
structure:


     If <object_1> <condition> <object_2> then <resolution>


The bracketed words (<>) are columns in the database table.  The
table also includes modifiers for object dimension, condition value,
and resolution value.  In addition, the rows in the table can be
linked for compound conditions.  An example of a basic conditional
rule is:


     If <stream/river> <symbol_coalesces> <road> then <displace>


This rule is applied in the PGE system by identifying all symbol
coalescence between source features and then resolving those instances
where a rule exists.


Each rule has a unique identifier that allows any rule application to
be traced back to its source rule.  This identifier is useful in
identifying rules that require further refinement.  The identifier can
also be used where the PGE system identifies a problem condition but
cannot apply a resolution.  These instances are flagged for
interactive edit.  The editor can call up a queue of flagged instances
and display the rule that triggered each edit flag.  This technique is
useful in a phased approach toward complete automation.  The system
does not have to provide a full solution for problem data.  If the
system can first identify the problems, the automation is half
complete.  In other words, the problem identification part of the rule
can be implemented without waiting on completion of a resolution
function.


Besides being applied to generalization conditions, the same structure
can be used in several other processing components; including data
filtering, type selection, and text placement.  This use of a single
rule structure simplifies both rule development and rule
application.


The degree to which graphic production processes are automated depends
on how completely the standards are defined and how well the standards
are integrated with the application functions.  In the above
stream/river rule example, the rule must exist in the standards before
it can be automatically applied.  In addition, the rule must be in a
form that can be interpreted by the processing functions.  On the
application side, the system must be able to detect the existence of
"symbol coalesce" between the features involved and apply the
displacement.  Because the NMD standards development for graphic
products is far from complete, the PGE system is designed as a
baseline system in which to incorporate standards-driven functions as
standards and processing algorithms develop.


DLG-F in ArcInfo

A challenge for the PGE development team has been how to work with the
DLG- F data model within ArcInfo.  From the start of PGE development,
an objective has been to make use of the spatial analysis and spatial
data management capabilities in ArcInfo.   Certain DLG-F modeling
constructs, however, do not fit neatly into ArcInfo.  These include
the nesting of attributes on values and the existence of compound
features across multiple dimensions.


Although the DLG-F data model is not directly supported in ArcInfo,
it can be implemented through relational database applications.  INFO
could be used to support the model and has been applied in other
limited applications.  Given the scope of feature and product
information to be managed in a production system, however, the
decision was made to take advantage of the data management
capabilities of Oracle in place of INFO.  The spatial information
(points, chains, rings) can be moved between ArcInfo and Oracle as
needed, but almost all other information, such as metadata,
attributes, and relationships, resides in Oracle.


One characteristic of the DLG-F data model that the PGE system employs
when using Oracle with ArcInfo is the permanent feature identifier. 
The concept behind the permanent feature identifier is to have a
unique identifier on each feature instance that links all users of
that data to any changes in the feature.  Rather than replacing all
features when updating data holdings, users only have to update those
features that have changed.  Although the PGE system was not developed
to revise data, a requirement exists to maintain this identifier
throughout all processing in case errors in the source data are
encountered.  Because no data source is perfect and errors do occur,
the PGE system can supply data corrections back to the data source by
identifying the specific feature in error.


Because this unique feature identifier is maintained, it can be used
as the link between feature attribution and feature spatial
representation.  In ArcInfo, the permanent feature identifier is
placed in the feature attribute tables of the spatial data.  This
unique identifier can be related to Oracle through the Database
Integrator to access all nonlocational characteristics of the feature. 
A problem occurs, however, when features share spatial geometry.  For
example, quite often survey lines are coincident with boundary lines. 
If arcs are used to represent the data, this shared geometry results
in duplicate arcs.  If the data are topologically structured to
support two-dimensional features, one of the duplicate arcs is
deleted, which results in a loss of the link to the feature.


Conceptually, this problem can be solved by using routes for
one-dimensional features and regions for two-dimensional features.  In
practice, however, the slow performance of editing routes on large
datasets (e.g., 10,000 routes) is unacceptable.  Instead, the current
approach in the PGE system is to separate one-dimensional and
two-dimensional features into different coverages.  One-dimensional
features are represented as arcs and are allowed to exist as
duplicates and without intersections if they are nonnetwork features.
Two-dimensional features are represented as regions, complete with
full polygon topology.  Zero-dimensional features may exist as nodes
in the one-dimensional coverage if they are associated with lines, or
they may exist in a separate point coverage.  All themes except
hypsography (i.e., contours) are integrated into the same coverages. 
The volume of hypsography data causes too many problems if these data
are integrated; therefore hypsography data are segregated to a
separate coverage.


In this approach to using DLG-F data in ArcInfo, the problems in
maintaining the model are dealt with through the Oracle database
management system.  The PGE system can take advantage of the spatial
editing and plotting capabilities in ArcInfo without developing
potentially cumbersome maintenance processing techniques in INFO.


Besides being applied to editing and plotting of DLG-F data, ArcInfo
is being used for text placement and collar generation, and it may be
applied for deriving contours and (or) shaded relief if DLG-F contours
are unavailable.  These developments are just under way or planned for
the near future.


Feature-based Transaction Loads and Unloads

In the above discussion on the use of permanent feature identifiers,
the point is made that having a unique identifier on feature instances
allows individual feature revisions rather than wholesale replacement
of complete datasets.  This approach is being applied in NMD's
development of its feature-based archival database.  Data are entered
in and extracted from this database through individual feature
transactions.  Consequently, when DLG-F data are required as a source
for graphic production, the archival database will supply all feature
instances that occur in the area of interest as individual
transactions.


Each feature transaction contains the feature identifier in addition
to all its relevant locational and nonlocational characteristics.  The
transaction also contains a tracking mechanism identifying the nature
of the transaction.  When DLG-F data are loaded into the PGE system,
all transactions are identified as ADDS.  If data are found by the PGE
system to be in error and require output transactions, the feature
identifiers along with descriptions of the feature changes are sent
back to the archival database. Although this methodology requires
significant additional development for broad-based application, the
approach appears promising.


Development Platform

The PGE system operates on a Data General UNIX platform using Oracle
7+, ArcInfo 7.0+, and custom modules written in C.  In general,
Oracle is used to manage feature data and product standards; C
programs are used for data loads, unloads, and conflict detection and
resolution; and ArcInfo is used for topological structuring, feature
editing, and plotting.


Functional Capabilities

The functional capabilities of the PGE system include the following:

Load/Unload Data
DLG-F features are loaded or unloaded as feature transactions.  An
additional requirement of the PGE system may be to load data from
other sources, including elevation data, vector data from other
organizations, orthoimages, or digital raster graphics (DRG).  The
raster data loads are mostly straightforward.  Loading vector data
from other organizations may require conversion to a feature-based
format.


Reduce Data
Data loaded into the PGE system will often exceed output product
requirements, both in content and extent.  The PGE system will clip
data to the output product's geographic extent (i.e., tile) and (or)
filter the content, if necessary.


Generate Elevation Representation
DLG-F contour data may not be available as a data source for those
products requiring elevation data on the output product.  Other
elevation sources, including digital elevation models (DEM) and tagged
vector contours (TVC), may be used to derive contour and (or) shaded
relief representations.  TVC's refer to vector contours, but without
topology, without full attribution, and possibly with gaps where
coalescence or banding exists.


Generate Map Collar
The PGE system must generate map legend information, credit notes,
source dates, etc., from source data, source metadata, and external
sources such as the Geographic Cell Names Database.  This process also
requires generation of the neatline and associated coordinate
labels.


Generalize Data
Graphic representation requires legibility at the output product
scale.  Source data may require thinning, merging, or other
manipulations to produce legible output representation.  Currently
this process is limited to feature conflict detection and resolution,
but it will eventually include broader generalization concerns for
each product series.


Edit Data
Although the objective of the PGE system is to reduce interactive
editing, a fully functional edit system is required.  A major
component of the edit system is an edit queue, which is a list of
problem areas identified by the generalization processes that could
not be automatically resolved.  The edit queue will direct an operator
to each problem and display both the data in question and the rule
that identified the problem.  Editors will also be able to review the
data for problems not identified by automated processing.


Plot Data
The PGE system has requirements to produce review plots for
cartographic editors and PostScript files for final film separate
generation.  The PGE system will also produce replacement DRG files
from PostScript plot files.


Status and Future Development Plans

The PGE system is designed as a baseline system to accommodate
increasing automation as standards and processing algorithms evolve. 
The current system can load DLG-F data and standards, apply limited
data generalization, support DLG-F editing, and generate PostScript
files for film separation or generation of DRG files.  The system is
also constrained to producing 1:24,000-scale graphics to content
levels approximating the Federal Geographic Data Committee's
Framework content because this is the only graphic product defined
up to this point in the standards database.  Near-term developments
include output of feature-based transaction files, collar 
generation, and automated text placement.  Further development of
standards and generalization is ongoing and can be expected to
continue throughout the life of the system.


Planned developments beyond the baseline system include an evaluation
of Esri's spatial database engine (SDE).  The SDE may offer a more
efficient database engine for managing DLG-F data in place of the PGE
system's current Oracle implementation.  The SDE also offers several
spatial analysis functions that may be applicable to automated
generalization.  Other investigations include the possible porting of
the system to Windows NT once ArcInfo is supported on that
platform.


Any use of trade, product, or firm names is for descriptive
purposes only and does not imply endorsement by the U.S.
Government.