Building dynamic network models with GIS software components
Geographic objects
The traditional GIS data model - the GeoRelational model - uses a row in a tabular database to represent
a geographic entity such as a parcel, road, or manhole. In this model, the feature type is defined purely by
the data - a parcel is no different than a building, a road no different than a stream. Each feature is
composed of geometry and a collection of attributes. For sophisticated development, this model is limited
because the client may only loosely bind behavior to the data.
In contrast, an object-oriented GIS model provides a means to encapsulate behavior with the feature data.
This tight coupling of data and behavior is what makes the system truly object-oriented. It allows
applications to define and work directly with their actual domain objects (e.g., parcels, roads, or
570
manholes) instead of just rows in a database. We wiIIterm such objects Geographic Objects. Geographic
Objects, when properly constructed on a component architecture, allow the user to create custom domain
objects that are no different in performance or range of functionality than the GIS vendor provided
objects. Additionally, Geographic Objects supply default behavior for the most common tasks such as
editing and display. The user may focus only on aspects of the Geographic Object that they wish to
customize, and rely upon the default behavior for the remainder that they do not wish to customize. In the
remainder of this paper, we will use the terms Geographic Object and feature interchangeably.
Network modeling
There are many difficult problems that a data modeler encounters when building sophisticated AM/FM
networks. At a very high-level, the largest problem areas include:
-
Topological Relationships
Within AM/FM/GIS systems, many (if not most) of the features participate in "active" topological
networks. Rather than relying upon end-user provided solutions to maintain these topological
relationships, the fundamental infrastructure of the system must handle this requirement (database
integrity as well as interactive topological editing).
- Complex Network Topologies
In certain AM/FM domains such as electric and telecommunications, it is frequently necessary to model
more sophisticated features which have complex internal network topologies. As an example from the
electric distribution domain, switchgear (such as the S&C PMH serie$ see S & C Electric Company,
1994) may have five associated network junctions, and four network edges arranged internally in a star
configuration. Rather than represent the switchgear feature as a single network junction, it is desirable to
consider that collection of network junctions and edges as corresponding to a single feature.
- Complex Relationships
Within sophisticated AM/FM/GIS object models, it is necessary to support user-definable relationships
between features. These relationships differ from the implicit topological relationships that the system
should also maintain. These relationships can come in two primary flavors; associations, and composite
relationships. Associations are bidirectional, semantic connections between two features. Composite
relationships are semantically stronger than associations as composite relationships define a one-to-many
relationship between an origin feature and a destination feature. The origin feature controls the lifetime of
the destination feature. You may use composite relationships to construct composition-based features -
features that are composed of other features (e.g., a transformer bank and a collection of transformer
units).
- Complex Model Maintenance
In order to maintain the integrity of sophisticated AM/FM/GIS object models, it is necessary to provide
mechanisms that support object validation without resorting to database-specific (and unportable)
triggers. Database triggers are unportable and are very difficult to debug in large systems. The validation
infrastructure must also facilitate relationship-based event notification.
