Strategies for Interoperation between a Network Modeling System and a GIS
Open DataBase Connectivity (ODBC)
The ODBC standard was started in the late 1980s by the SQL Access Group
and X/Open to provide a standard for database interoperability. Prior
to ODBC, applications had to be re-linked, and possibly even re-written,
to work with each relational database vendor’s system. Microsoft
decided to implement the call level interface of the ODBC standard, and
has ensured its success with the participation of all the major database
vendors.
ODBC offers the capability for a NMS to directly access data stored in
the GIS relational database. As discussed in the Hybrid Systems section
above, the spatial component of the GIS database may not be managed by
the RDBMS. In these cases, the spatial data must first be moved into
temporary tables in the relational database.
Object Linking And Embedding (OLE)
OLE started out as a specification to support compound documents in the
windows environment. Version 2 of the OLE standard refined some of the
aspects of the first version, but also added significant new features to
control and transfer data to other OLE compliant applications. There
are tremendous advantages in using 0LE2 to access GIS data, if the
applications and tools for its use are in place.
Microsoft has realized some of the deficiencies of ODBC, and has urged
software developers to use 0LE2 as a replacement for ODBC. The
tremendous popularity of ODBC with database vendors and developers,
along with performance improvements by 3rd party developers, has slowed
ODBC’S replacement by 0LE2.
Manipulating the Data
Model Selection
Prior to the transfer of data to the NMS, it is sometimes useful to be
able to specify that only a subset of the data is to be transferred.
This selection process can become quite complex when subsets of the
database must be considered.
Data Selection Methods:
- Entire Database Dump
- Area Subset Defined by Attribute
- Area Subset Defined by Enclosing Polygon
- Connectivity Trace
To illustrate subset selection issues, a natural gas distribution system
will be used in the following example. Suppose that our desire is to
transfer all connected pipes of an identical pressure level that are
within a particular geographic region. To perform such a selection, both
the pressure level and network system identifiers would have to be
stored and maintained within the GIS. Most GIS systems are not well
suited to the problems of managing gas network definitions.
Another functional technique is to have the user select one pipe, and
then trace all connected pipes at the same pressure level. If the trace
cannot cross either closed valves or regulators to a different pressure
level, the resulting set of defined facilities will represent one
hydraulically independent network. Although this method makes sense
from a modeling perspective, the performance overhead of requiring a
network trace to define a subset may make it unrealistic.
Object Transformations
Most GIS systems that have been designed for facilities management
utilize line objects to store pipe data, and point objects to store
fittings and valves. This relationship works well for a high percentage
of the data which must be transferred. Unfortunately, there are two
types of objects which must be transformed when they are moved to the
NMs. Most network modeling systems represent regulators and valves as
elements, rather than points. When using this type of representation
for a network, nodes are the only locations where water or gas can be
introduced and removed from the network. The node connecting elements
(NCES) are then responsible for performing regulation and isolation.
Point to Element Entitv Transformation Methods:
- Simple Insertion
- Claim an Existing Element
- Element Fragmentation
To set up a regulating element in the NMS, it’s point entity
representation in the GIS must have a knowledge of the network to which
it is connected. In our natural gas system for example, the regulator
point in the GIS must know that the upstream connected pipe represents a
higher pressure than the downstream connected pipe. Additional
information from engineering support databases may be required to setup
the regulator or valve element if all the necessary components are not
stored within the GIS.
Once the logical components of the point-to-element transformation
requirements are known, strategies can be developed to handle the
spatial components. One basic approach to the spatial problem is to
simply insert them into the model as new elements. This approach has
several limitations. The new elements must be created so that they not
only preserve the existing pipe connectivity, but must also be aligned
correctly within the model if they function as a regulator.
The second transformation technique makes use of a pipe connected to the
point entity for it’s representation within the NMS. The advantage in
this situation is a minimal amount of spatial processing must be done.
A limitation which must be acknowledged is the loss of the actual pipe
length when it is claimed for use as a zero logical length regulator or
valve within the model. This second transformation method works well
for facility data that are very granular in their segmentation. The
loss of segments and pipe length is, therefore, smaller when compared to
systems that are represented by a smaller number of longer segments.
The last transformation technique addresses situations where long pipe
segments exist. Claiming an entire pipe to create the needed valve or
regulator would cause a significant loss of length. As an alternative,
one of the adjacent comecting pipes can be fragmented into two sections
to represent both the original pipe, and the new valve, or regulator
element. This process works well if a new fragmenting node is inserted
into the model at a standard offset from the original GIS point entity.
