Strategies for Interoperation between a Network Modeling System and a GIS
Model Size Reduction
Network Modeling Systems have matured in recent years, and expanded
their capabilities to deal with much larger models. Model problem sizes
thought to be too large just a decade ago, are now routinely modeled.
In large part, this is due to advances in processor speed, larger
amounts of memory, and easy to use 32 bit operating systems. Even with
these advances, concern must still be expressed about the amount of
detail in some GIS databases. The network analyst wants to find a way
to represent the model using the least number of pipes and nodes, but
still have acceptable accuracy.
Two strategies can be used to reduce models to acceptable sizes. The
first is to use the tool set found within the GIS. While processing the
data for export, if two pipes are found with very similar attributes,
they could be combined to form one pipe in the NMS. The second strategy
relies on NMS tools to perform model problem size reduction. The model
is first created on a “one-to-one” basis, where every pipe within the
GIS has a corresponding pipe in the NMS. After import into the NMS
software, the attributes and hydraulic characteristics of the model are
evaluated to decide which pipes may be combined. The advantage of the
second approach is that hydraulic characteristics may now be considered
as part of the reduction criteria.
Transferrring Data from a NMS to a GIS
Transferring hydraulic analysis results from a NMS to a GIS is
significantly easier than transferring data in the other direction, but
not without its own unique considerations. Most modern NMS software has
the capability to create special delimited files which store results
from the analysis. This formatted results file can be loaded into
relational database tables without significant preparation.
As an example, the Oracle SQLload utility provides a language to specify
which table receives the data, the file containing the load data, and
instructions on how to parse and select specified columns for the table.
~ alternate technique directly accesses analysis results that have been
placed into the model file when it is saved. This approach requires
much more knowledge of the NFIS file format, and also takes significantly
more work to access the data of interest.
Once the analysis results have been loaded into the specified tables,
applications can be constructed within the GIS to provide thematic
mapping displays of the data.
It is important to note that when results of an analysis have been
loaded into a GIS environment, many persons with no knowledge of the
analysis may have access to the data. Additional tables which contain
descriptions of the analysis should be added to the GIS to enhance
interpretation of the results data.
Software Development Tool Options
Native GIS Languages
As mentioned earlier, many GIS systems provide excellent languages and
environments for the development of customized applications. Using an
environment that comes bundled with the GIS product may be the most
compelling reason for its use. The investment that many utilities have
made in the total understanding of the GIS system can be more than
enough justification not to look elsewhere.
Third Generation Languages (3GLs)
Third generation languages have been the mainstay of software
development since their introduction in the 1960s. Engineering analysis
software has traditionally been well suited to the use of the FORTRAN
programming language. In the early 1980s, a new language called ‘C’
started to gain momentum in the software development community, thanks
to its association with Unix workstations, and its speed and efficiency.
These 3GL tools are adequate for use in integration software
development, but many other alternatives also deserve consideration.
Fourth Generation Languages (4GLs) and Object Oriented Programming (OOP)
The current 4GL marketplace makes many promises to its users, such as
shorter software development cycles, linkages to automated design tools,
and less coding through the use of business rules. One of the issues
associated with many 4GL products is their lack of official standards.
Some systems interact with GIS data through ANSI standard Structured
Query Language (SQL), but most other aspects of their use are completely
proprietary. Powersoft’s PowerBuilder is an example of a 4GL,
37.client/server development product that has become very popular in many
large Information Systems shops.
Object oriented languages such as Visual Basic and Visual C++ have also
become very popular with software developers. C++ provides an
exceptionally powerful 00P environment, but the effort to use it
effectively may be too much for those who are less than fully committed
to these products. The Microsoft Foundation Class (MFC) allows very
detailed access to the Windows Application Programming Interface (API),
but such intricate manipulations are usually not warranted in customized
analysis interface software.
Microsoft’s Visual Basic and Borland’s Delphi products have provided
easier access to the Windows API while giving Rapid Application
Development (RAD) capabilities. One of Visual Basic’s biggest criticism
is that it suffers from poor performance because it is an interpreted
language. Delphi’s compiled executable address many of the performance
issues of Visual Basic, but rely on Borland’s Object Pascal, which is a
proprietary, object oriented, extension of conventional Pascal. It is
worth noting that the use of Dynamically Linked Library (DLL) components
with Visual Basic can relieve some of its poor performance. The DLL is
a compiled binary file, which is incorporated into the application at
run time.
Componentware
The component market has evolved significantly since its introduction as
simple VBX additions to Microsoft’s Visual Basic. With the release of
Visual Basic4, new 32 bit components called OCXS now provide object
linking and embedding capabilities. Many GIS vendors also supply
components that can provide embedded GIS functionality to customized
applications. ESRI’S MapObjects is an excellent example of a component
library that provides data manipulation and visualization for ArcInfo
and ArcView databases.
Conclusion
After reviewing the data requirements necessary for interoperation
between a GIS and a NMS, hopefully some of the strategies are now
clearer.
The selection of a software development environment should be based on
the requirements of the interface, and the experience of the interface
developers. Adequate planning and investigation into available
supporting tools and libraries should precede any significant software
development project.
