| GISdevelopment.net ---> GITA 1999 ---> Engineering and Design Applications |
Patterns for building Utility Data Models
Michael Zeiler
Environmental Systems Research Institute
380 New York Street
Redlands, CA 92373
E-mail: mzeiler@esri.com
Michael Zeiler
Environmental Systems Research Institute
380 New York Street
Redlands, CA 92373
E-mail: mzeiler@esri.com
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:
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:
The cartographic representation of utility objects must be faithful to a long history of manual and digital mapping. Over time, utilities have evolved a set of cartographic practices perform several important functions. They convey rich attribute data on the map and portray small but important objects so that they are not overwhelmed by large geographic objects. These practices also provide specialized map products for distinct audiences such as personnel in customer relations, operations, and engineering.
These are a few of the cartographic problems:
The essential criterion for handling the attributes of objects well is data integrity. These are some of the actions on data that the modeler would like to prescribe so that editing errors are minimal:
A methodology for capturing problems and articulating design solutions has emerged - first within the discipline of architecture and more recently in object-oriented software development.
Christopher Alexander first elucidated the notion of patterns and pattern languages to capture elements of architectural design. He has written several books including A Pattern Language.” Towns, Buildings, Construction and The Timeless Way of Building. His insight was to identify as patterns those qualities that make living spaces more attractive and then to combine those patterns into a framework for designing buildings and communities. His writing asserts the dominant goal of architecture -to enhance the human condition by designing living spaces that promote qualities such as openness, freedom, accessibility, and comfort.
The application of a pattern methodology towards software design became widespread with the publication of a seminal book, Design Patterns: Elements of Reusable Object-Oriented Sof~are, by Gamma, Helm, Johnson and Vlissides. These authors borrowed ideas from Alexander and compiled a catalog with definitions of core software patterns frequently encountered such as iterator, proxy, composite, factory method, singleton, and fayade. Design patterns are low-level archetypes that are broadly applicable to all facets of object-oriented software development. Patterns are also being applied as higher levels of abstraction, such as data objects in a application.
Elements of patterns
Christopher Alexander says this about patterns: “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without every doing it the same way twice.” This description is also apt for software design. Designers immediately recognize a good pattern as ubiquitous and useful.
A pattern is documented as a structured narration of a design solution. Patterns are being used in a wide set of domains, so the elements and format of this structured narration vary, but most practitioners recognize these elements of a pattern:
Patterns in GIS Software Components
The goal of the modeler is to solve the riddle of contrasting representations by creating a data model that unifies the network, cartographic, and tabular views of a utilit y system. A central instrument of the data modeler is the intrinsic data model exposed by the native GIS. Modern object-oriented GIS software offers several new facets that enables the modeler to realize the integration of the disparate representations of objects. Newly engineered GIS software offers:
A common problem to any domain based upon linear networks is that the cartographic features do not correspond precisely to elements of the implicit network.
Consider a transportation network. It includes features such as railroads, highways, rivers, and airline routes. Some of these network features allow transport in both directions while others constraint transport to one direction. An airline route is an interesting object: It certainly should be modeled within a network, but it isn’t properly a map feature.
Furthermore, utility data models contain complex objects where one geographic feature represents multiple elements, such as cable pairs or phases of power. These requirements lead to a GIS data model that supports considerable flexibility in feature representation and network modeling.
Geometric networks and logical networks
A solution to reconciling cartographic and network representations is a GIS component data model like this:
This UML diagram depicts a GIS component data model that supports dual network representation: I) as a geometric network, a collection of map features participating in a linear network and 2) as a logical network, the full representation of all the visible and invisible elements of a utility network. The important point to grasp about this model is that a network feature can correspond to one or many network elements. A full exposition of this model is beyond the scope of this paper, but there are many interesting patterns here, one of which is the complex junction feature.
GIS data model ~attern: Complex iunction feature
The complex junction feature is a pattern that is available within the core GIS data model.
A switchgear is an example of a complex junction feature. It is drawn on a map as a single feature but contains interna[ edges with fuses and switches, busbars, and junction points. Switchgear have a high side connection point and multiple low side connection points. The low side connection points can serve three phase line sections or can split into individual phase line sections.
Context:
Utility networks can include complex junction devices such as multiplexer or switchgear that contain internal topologies. One of these devices might be represented as a single map feature, as a collection of network elements (junctions and edges), and as a set of related rows in a series of database tables.
These devices are typically dynamic in their operation and have constraints on which types of lines which can be connected on the high and low side.
Solution:
Model this type of device with a network feature that contains an internal topological configuration of network edges and junctions. This user interface of this feature exposes a high-side connection point and multiple low-side connection points.
Validation rules can be applied when external lines are attached to the connection points so that flow conditions such as voltage levels are correct.
The display of this feature can be customized so that internal dynamic settings, such as current switch status, can be drawn on the map.
Consequences:
The internal parts of this complex junction device cannot be directly edited as individual features. Instead, a custom property sheet is the user interface for modifjing the configuration or internal components.
The database design must allow that certain object types, such as fuses, are sometimes represented as features (when they are outside a switchgear) or as objects (when they are internal to a switchgear.)
Utility domain pattern: Line section
The core GIS data model makes certain omnipresent patterns available for ready implementation, but because GIS software is generic by design, other patterns remain for development by the data modeler. An example of a utility domain pattern is the line section.
Context:
The elements of many utility systems can be classified into two levels: primary distribution and secondary distribution. The GIS user can become overwhelmed with a network that is a complete collection of secondary and primary segments.
It is desirable to create collections of primary line segments that simplify interaction with the network. Line sections give the user a two-level view of the network.
Line sections are commonly used by distribution engineers. They represent a basic unit of a network for flow analysis.
Solution:
A line section is an aggregation of primary line segments. It simplifies the engineer’s view of a large utility network from hundred of thousands or millions of segments to a few thousand sections.
Line sections are somewhat arbitrary in definition and are delimited by these conditions:
The line section makes all of its constituent parts accessible for iteration. It can perform counts such as the number of customers or accumulated load. A line section can also enhance the drawing of line styles or annotation.
Consequences:
A line section is a useful aggregation of like line segments, but when a significant change occurs between its two end junctions, such as the placement of an isolation or regulating device, this object must be split. If the line section is split and has an arbitrary identifier, then the editor should be able to specifi a new identifier for the two line sections and relevant attribute values.
Conclusion
Utilities represent probably the most demanding customers of GIS technology and require advanced data models to represent complex linear networks. A new generation of component-based GIS software is becoming available to meet this demand.
Utilities can now exploit new sophisticated network data models that are available within the core GI S. While the core GIS system has an enhanced model for utilities, work remains to create domain-specific data models. The application and extension of these network data models require a careful and deliberate analysis.
This paper has shown that patterns are an important and useful technique to assist the development of custom data models that closely emulate the actions and qualities of the real-world objects in a utility system.
References
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.
The cartographic representation of utility objects must be faithful to a long history of manual and digital mapping. Over time, utilities have evolved a set of cartographic practices perform several important functions. They convey rich attribute data on the map and portray small but important objects so that they are not overwhelmed by large geographic objects. These practices also provide specialized map products for distinct audiences such as personnel in customer relations, operations, and engineering.
These are a few of the cartographic problems:
- Topologically interesting relationships occur within a very small geographic area. An example is that many devices and lines can be mounted on a single pole, so there is a requirement to draw features such as fuses or reclosers at offset positions and from their true geographic location. Also, sophisticated drawing methods are needed to display line features such as secondary underbuild and parallel circuits.
- Many utility systems have multiple networks along the same set of support structures. A common cartographic technique is drawing parallel networks at offsets. Sometimes, annotation or special line styles are employed to denote multiple networks.
- An object on a map such as a substation may contain other objects, but it may be represented as a single symbol on a map.
- A utility system requires diverse displays of geographic data. Two common types of views are detail (or cartographic) and schematic. Detail map views need to intelligently render network features appropriate to a variety of map scales. Schematic map views are used for studying sectionalizing devices and analyzing voltage drops.
The essential criterion for handling the attributes of objects well is data integrity. These are some of the actions on data that the modeler would like to prescribe so that editing errors are minimal:
- Attributes should be confined to a well specified set or range of values and combinations of values should be compatible. Also, specifying default attributes values is an aid to the editor.
- Some objects are bound to each other. The data modeler should be able to specify relationships so that move, copy, and delete edit operations yield the expected result.
- There are certain important classifications of feature sets, such as whether they designate underground or overhead, distribution or secondary, or wood or metal.
A methodology for capturing problems and articulating design solutions has emerged - first within the discipline of architecture and more recently in object-oriented software development.
Christopher Alexander first elucidated the notion of patterns and pattern languages to capture elements of architectural design. He has written several books including A Pattern Language.” Towns, Buildings, Construction and The Timeless Way of Building. His insight was to identify as patterns those qualities that make living spaces more attractive and then to combine those patterns into a framework for designing buildings and communities. His writing asserts the dominant goal of architecture -to enhance the human condition by designing living spaces that promote qualities such as openness, freedom, accessibility, and comfort.
The application of a pattern methodology towards software design became widespread with the publication of a seminal book, Design Patterns: Elements of Reusable Object-Oriented Sof~are, by Gamma, Helm, Johnson and Vlissides. These authors borrowed ideas from Alexander and compiled a catalog with definitions of core software patterns frequently encountered such as iterator, proxy, composite, factory method, singleton, and fayade. Design patterns are low-level archetypes that are broadly applicable to all facets of object-oriented software development. Patterns are also being applied as higher levels of abstraction, such as data objects in a application.
Elements of patterns
Christopher Alexander says this about patterns: “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without every doing it the same way twice.” This description is also apt for software design. Designers immediately recognize a good pattern as ubiquitous and useful.
A pattern is documented as a structured narration of a design solution. Patterns are being used in a wide set of domains, so the elements and format of this structured narration vary, but most practitioners recognize these elements of a pattern:
- A name is an important attribute of a pattern which succinctly describes it, is universal to the range of applicable domains, and can be naturally used in conversation.
- Each pattern exists within a context that describes the problem to resolve and the forces at play. The context dictates whether a given pattern is applicable or useful.
- The solution describes the parts of the design that cleanly resolve the contradictions among the forces upon the pattern. The solution is not a technical specification or pseudo-code; it is a conceptual description that reveals insight.
- The application of a pattern has consequences that are declared. These consequences are side-effects of the solution and the trade-offs made in the design.
Patterns in GIS Software Components
The goal of the modeler is to solve the riddle of contrasting representations by creating a data model that unifies the network, cartographic, and tabular views of a utilit y system. A central instrument of the data modeler is the intrinsic data model exposed by the native GIS. Modern object-oriented GIS software offers several new facets that enables the modeler to realize the integration of the disparate representations of objects. Newly engineered GIS software offers:
- Implementation upon commercial off-the-shelf relational database management systems of the customer’s choice. GIS software extends the DBMS with support for long transactions and versions, spatial data types and operators, and map display and query.
- A soflware component-based data model which is extensible by configuration management and object-oriented programming techniques of inheritance and encapsulation.
- Customization through standard visual programming environments such as Visual Basic, Delphi, or Visual C++.
- Improved native support for linear networks that contain map features with relationships to one or several virtual network elements.
A common problem to any domain based upon linear networks is that the cartographic features do not correspond precisely to elements of the implicit network.
Consider a transportation network. It includes features such as railroads, highways, rivers, and airline routes. Some of these network features allow transport in both directions while others constraint transport to one direction. An airline route is an interesting object: It certainly should be modeled within a network, but it isn’t properly a map feature.
Furthermore, utility data models contain complex objects where one geographic feature represents multiple elements, such as cable pairs or phases of power. These requirements lead to a GIS data model that supports considerable flexibility in feature representation and network modeling.
Geometric networks and logical networks
A solution to reconciling cartographic and network representations is a GIS component data model like this:
This UML diagram depicts a GIS component data model that supports dual network representation: I) as a geometric network, a collection of map features participating in a linear network and 2) as a logical network, the full representation of all the visible and invisible elements of a utility network. The important point to grasp about this model is that a network feature can correspond to one or many network elements. A full exposition of this model is beyond the scope of this paper, but there are many interesting patterns here, one of which is the complex junction feature.
GIS data model ~attern: Complex iunction feature
The complex junction feature is a pattern that is available within the core GIS data model.
A switchgear is an example of a complex junction feature. It is drawn on a map as a single feature but contains interna[ edges with fuses and switches, busbars, and junction points. Switchgear have a high side connection point and multiple low side connection points. The low side connection points can serve three phase line sections or can split into individual phase line sections.
Context:
Utility networks can include complex junction devices such as multiplexer or switchgear that contain internal topologies. One of these devices might be represented as a single map feature, as a collection of network elements (junctions and edges), and as a set of related rows in a series of database tables.
These devices are typically dynamic in their operation and have constraints on which types of lines which can be connected on the high and low side.
Solution:
Model this type of device with a network feature that contains an internal topological configuration of network edges and junctions. This user interface of this feature exposes a high-side connection point and multiple low-side connection points.
Validation rules can be applied when external lines are attached to the connection points so that flow conditions such as voltage levels are correct.
The display of this feature can be customized so that internal dynamic settings, such as current switch status, can be drawn on the map.
Consequences:
The internal parts of this complex junction device cannot be directly edited as individual features. Instead, a custom property sheet is the user interface for modifjing the configuration or internal components.
The database design must allow that certain object types, such as fuses, are sometimes represented as features (when they are outside a switchgear) or as objects (when they are internal to a switchgear.)
Utility domain pattern: Line section
The core GIS data model makes certain omnipresent patterns available for ready implementation, but because GIS software is generic by design, other patterns remain for development by the data modeler. An example of a utility domain pattern is the line section.
Context:
The elements of many utility systems can be classified into two levels: primary distribution and secondary distribution. The GIS user can become overwhelmed with a network that is a complete collection of secondary and primary segments.
It is desirable to create collections of primary line segments that simplify interaction with the network. Line sections give the user a two-level view of the network.
Line sections are commonly used by distribution engineers. They represent a basic unit of a network for flow analysis.
Solution:
A line section is an aggregation of primary line segments. It simplifies the engineer’s view of a large utility network from hundred of thousands or millions of segments to a few thousand sections.
Line sections are somewhat arbitrary in definition and are delimited by these conditions:
- A topological junction in the primary circuit,
- Significant in-line devices such as transformers, voltage regulators, or capacitors,
- Major sectionalizing devices such as reclosers and switches,
- Large commercial loads, such as a shopping center or factory, and
- A change in line conductor type or phase transposition.
The line section makes all of its constituent parts accessible for iteration. It can perform counts such as the number of customers or accumulated load. A line section can also enhance the drawing of line styles or annotation.
Consequences:
A line section is a useful aggregation of like line segments, but when a significant change occurs between its two end junctions, such as the placement of an isolation or regulating device, this object must be split. If the line section is split and has an arbitrary identifier, then the editor should be able to specifi a new identifier for the two line sections and relevant attribute values.
Conclusion
Utilities represent probably the most demanding customers of GIS technology and require advanced data models to represent complex linear networks. A new generation of component-based GIS software is becoming available to meet this demand.
Utilities can now exploit new sophisticated network data models that are available within the core GI S. While the core GIS system has an enhanced model for utilities, work remains to create domain-specific data models. The application and extension of these network data models require a careful and deliberate analysis.
This paper has shown that patterns are an important and useful technique to assist the development of custom data models that closely emulate the actions and qualities of the real-world objects in a utility system.
References
- Gamma, E., Helm, R., Johnson, R., and Vlissides, J., 1995: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, Massachusetts.
- Alexander, C., Ishikawa, S., Silverstein, M., 1977: A Pattern Language: Towns, Buildings, Construction. Oxford University Press, New York, New York.