Implementing
a geodatabase for local government, Part 3
Designing
geodatabase behavior
Recall
from the previous two modules that a small city in southern
All the
subdivisions are recorded in detailed CAD drawings. The city engineers feel
that additional database layers for capital improvements should be based on
these CAD drawings. For example, new development means that utility networks,
such as water and sewer, will need to be extended. The additional loads on
these systems will also require improvements to the existing components. In
fact, the Public Works Department is planning a major overhaul of the city's
sewer and stormwater systems—in a major capital
improvement project, they will be separating the systems for environmental
reasons.
Sue, the
GIS consultant from OMH Inc., is planning to add the CAD data to the Public
Works personal geodatabase, thus providing the
engineers with a familiar baseline dataset. More importantly, designing the
sewer and stormwater systems in the geodatabase will also give them an opportunity to establish
relationships between new and existing components and build intelligence into
their GIS database.
Detailed CAD drawings provide the
city engineers and planners with surveyed information about parcel and street
data. The CAD data is going to be migrated to the pilot personal geodatabases and used as a baseline for further data
development.
In order
to prepare for this project, the Public Works Department would first like to
create rules and behaviors for how the sewer system can be assembled in the database.
They would also like to make data entry easier and more reliable when the
database gets modified.
The GIS staff at the Public Works Department have been thinking
about improving the database for a while. They have been closely following the
development of the ArcGIS® Sewer/Stormwater Data
Model, which provides many of the standards they desire for feature class
definition, rules for editing, and symbology.
As part of
the project, the city engineers want to build a completely accurate and
realistic inventory of system components. For example, the inventory would
include valves, manholes, meters, pumps, and other connection points.
Using the
ArcGIS Sewer/Stormwater Data Model as a starting
point, Sue and the city engineers are able to develop a UML diagram that suits
their needs. They decide that certain features, such as pumps, can be
effectively represented with subtypes based on the type of pump.
When a pump feature is added to the
geodatabase, one of six different subtypes is
selected. Each subtype shares the attributes of the Pump feature class.
For the
pilot project, the engineers also want to specify domains for the subtypes to
make data entry easier.
A range domain named PumpDiameter is created and then assigned to both the InletDiameter and DischargeDiameter
fields. The PumpDiameter domain is also associated
with each of the subtypes. When a new pump feature is added to the geodatabase, the diameter values entered for the InletDiameter and DischargeDiameter
fields can be immediately validated.
Every
feature class and nonspatial table is considered in
the same manner. For the pilot project, Sue works with a team of
representatives from each department to design the geodatabase.
Wherever possible, they use templates such as the ArcGIS Sewer/Stormwater Facilities Model to facilitate the design.
Once the
UML diagrams are complete, Sue can export them to an XML Metadata Interchange
(XMI) file and then use the ArcCatalog CASE Tools
Schema Wizard to generate geodatabases containing
feature classes with defined behavior.
After the
CAD datasets are loaded into these empty geodatabase
structures, the department staff can edit features and tables, digitize new
feature classes, and use the validation tools to enforce database integrity.