Logo GISdevelopment.net

GISdevelopment > Proceedings > GITA > 1997


GITA 2002 | GITA 2001 | GITA 2000 | GITA 1999 | GITA 1998 | GITA 1997
Sessions

Advanced Technical Topics

Building & Supporting Applications

Business Evolution & Platform Migration

Expanding the User Base -- Non-Traditional Applications

From the office to the Field

Fundamental & Economic Issues of AM/FM/GIS

Lessons Learned

Major Technology Trends and their Impacts

Project Planning, Implementation and Management

Re-Engineering and Integration Issues

Scada and Real-Time Systems

User Project Presentations

Best of the Rest

Invited Presentation


GITA 1997


Advanced Technical Topics


Building a Modular Interface Between a GM and three (3) Engineering Analysis Packages


Packages
Interfaces have been – or soon will be – written for three specific packages to suit the requirements of Greenwood (SC) Commissioners of Public Works. The packages are:
  • GAS WorkS3, natural gas distribution
  • KYPIPE 24, potable water and sewer
  • Scott& Scott5, electric distribution
Since we know that this system will need to support several packages, we built it to be a base for at least these:
  • EPANet6, potable water with water quality
  • WaterCAD7, potable water with water quality
3Asoftwareproduet andatrademark ofBradley B. Bean,PE, 1517NorthWeberStreet,ColoradoSprings,CO 80907.
4Developed by the Civil Engineering SoftwareCenter,University ofKentucky, CollegeofEngineering, Lexington, KY40506-0046.
5A product Of Scottk Scott Systems, Inc., 500 Union Street, Suite 745, seattle, WA 981012332.
6Developed by the Risk Reduction Engineering Laboratory, Office of Research and Development, U.S. Environmental Protection Ageney,Cincinnati, OH 42268
7A product and trademark of Haestad Methods,37 Brookside Road, Waterbury, CT 06708.


  • Stoner SWS-W8, water
  • Stoner SWS-G9, gas distribution and transmission
  • Requirements of the AM/FM/GIS System
    For export to an external analysis package to be worth the trouble, the network within the AM/FM/GIS must be correct. Facilities have to be checked for valid network connection as they are added or changed. Not many AM/FM/GIS systems can do is.

    Entity relationships and cardinality must be strictly enforced

    The user’s tools should allow a subset of the entire network to be extracted. Although the entire network may be needed every year or two for a complete end to end study, most of the time the user wants to make estimates on a limited sub-network.

    Finding the “ends” of the sub-network is the key logic required

    The sub-network must have valid connections between facilities. If the entity relationships and cardinality are inherently correct within the AM/FM/GIS, the next requirement is to make sure that they do not get inadvertently corrupted during export. Here we have the advantage of a true object-oriented AM/FM/GIS with a true object-oriented database. Since the facilities are objects with behaviors, we simply have them “report” their connectivity, so there is little additional code to write or maintain.

    Either there must be absolute connection between facilities, or export must have the ability to re-validate connections during export

    Looped flow must be accommodated for piped networks. In the past we could ignore looping for electrical networks, but that is changing. In an effort to improve power reliability, some utilities are practicing limited looping. Looping is a challenge to the export process since its detection is not always easy. If it is not detected, the AMFM7GIS can export duplicates of nodes and segments. Often the analysis package will detect this, so all you have wasted is time. Worse is when the package does not detect it and the resulting calculations are wrong and misleading.

    No duplication of a node or segment is permitted in the exported file

    The normal output to an analysis package is a node-segment table constructed by the AM/FM/GIS. The core is a table that maps the facilities in the AIWFIWGIS to their equivalent in the analysis package. An example of the differences we see are:
    • Some AM/FM/GIS facilities can be either a node or a segment in the analysis package. The assumption in most of these packages is that a human looks at the paper map sheets, sees a junction and codes it as a pipe fitting because it has no other significance to the study. But, if you need to know the pressures at that point or it is an end point of the sub-network being exported, it has to be exported as a node and not a pipe fitting.

      8An abbreviation for Stoner Workstation Serviee- Water by Stoner Associates,Inc.,P O Box 86, Carlisle,PA 17013-0086.
      9An abbreviation for Stoner Workstation Serviee- Gas by Stoner Associates,Inc.


    • KYPIPE 2 has separate sets of “cards” for each facility catego~. set must be in precise sequence.
    • GAS WorkS has just two “files”, node and pipe
    • Some AM/FM/GIS facilities can be either a node or a segment In addition each
    Matching AM/FM/GIS facility types to the categories in the analysis package differs greatly with each package

    We have found the most challenging data format limitations of the analysis systems are in field size and required data that are not naturally in the AM/FM/GIS. For example, GASWorkS limits the node name to 10 characters. As noted below, getting a totally unique, system-wide facility ID within 10 characters is nearly impossible. KYPIPE 2 requires header data that are meaningless to an AM/FM/GIS.

    Finally, the AM/FM/GIS export process must be able to export in DOS, Windows and UNIX file formats, That is not usually a problem for UNIX-based AM/FM/GIS systems, It maybe more difficult with DOS or Windows systems exporting to UNIX.

    Limits placed on the external analysis system
    Most AM/FM/GIS systems keep the network as many short pipe and conductor segments. It is exported as a very large set of nodes and segments. This can be a problem for some packages. Some are priced based upon the number of nodes and/or segments they process. Number of pipes or number of feeders are common terms. Some packages run very slowly with large numbers of nodes and segments. “Intelligence” within the AM/FM/GIS to join segments is not dependable. Since network validity has the highest priority, our export design will not risk loss of topology to reduce the output size.

    It must accommodate a large number of segments and nodes I An AM/FM/GIS with many classes or layers tends to have duplicate IDs or name when merged into a single extract. So, with thousands of facilities, AMiFM/GIS facility IDs need to be very long if they are to be unique. We have partly solved this by using “names” that are really unreadable hexadecimal hash in order to keep the size small. The major disadvantage is that the IDs are meaningless to the user and they cannot be imported back into the AM/FM/GIS, as discussed below.

    Page 2 of 3
    | Previous | Next |

    Applications | Technology | Policy | History | News | Tenders | Events | Interviews | Career | Companies | Country Pages | Books | Publications | Education | Glossary | Tutorials | Downloads | Site Map | Subscribe | GIS@development Magazine | Updates | Guest Book