Design Challenges of Building Models
Any person who builds a utility data model quickly realizes that this is a daunting task. The data
modeler’s work is made complicated by the need to reconcile several distinct and sometimes
contradictory aspects of representing an object.
There are three basic representations of the objects that comprise a utility system:
- As parts of network which can be traced,
- as features on a map which can be drawn to cartographic conventions, and
- as rows within corporate database tables upon which queries can be made.
The essential problem of the data modeler is that objects in these three representations do not
have a simple-correlation with each other. A feature- on a map may represent a number of
elements in a logical network. Some objects exist in corporate databases but are invisible on the
map. Network elements and database rows may potentially have a many-to-many relationship.
An indispensable goal of the data model is to keep synchronous the elements of these disjoint
representations of a utility network.
Network desire challenges
The network representation of utility objects is of the greatest interest to those who use the GIS
for dispatch and operations during an outage or when doing engineering analysis. These are
some situations when the network view should harmonize with cartographic and tabular views:
- A given line section in a utility network might represent multiple transport media such
cable pairs in telephony, phases of electric power, and multiple circuits.
- The topology of a utility network is dynamic and defined by the current status of isolation
devices such as switches and valves. These objects may control a flow state by supervisory
command or autonomously in response to a flow condition such as pressure or voltage.
- Large utility systems can quickly overwhelm a geographic database with hundreds of
thousands or millions of edges and nodes. Many utility networks can be sub-divided into
primary and secondary segments. It would be desirable for the network model to allow two-level
traces that optimize performance by tracing secondary segments only at the source or
destination of the trace.
