ArcGIS Pipeline Data Model Version Core Abstract and Core Classes

(1)

ArcGIS

®

Pipeline Data Model

Version 4.0 - Core

Abstract and Core Classes

(2)

May 2007

Printed in the United States of America.

The information contained in this document is the exclusive property of ESRI. This work is protected under United States copyright law and other international copyright treaties and conventions. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, or by any information storage or retrieval system, except as expressly permitted in writing by ESRI. All requests should be sent to Attention: Contracts Manager, ESRI, 380 New York Street, Redlands, CA 92373-8100, USA.

The information contained in this document is subject to change without notice.

U.S. GOVERNMENT RESTRICTED/LIMITED RIGHTS

Any software, documentation, and/or data delivered hereunder is subject to the terms of the License Agreement. In no event shall the U.S. Government acquire greater than RESTRICTED/LIMITED RIGHTS. At a minimum, use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in FAR §52.227-14 Alternates I, II, and III (JUN 1987); FAR §52.227-19 (JUN 1987) and/or FAR §12.211/12.212 (Commercial technical Data/Computer Software); and DFARS §252.227-7015 (NOV 1995) (technical Data) and/or DFARS §227.7202 (Computer Software), as applicable. Contractor/Manufacturer is ESRI, 380 New York Street, Redlands, CA 92373-8100, USA.

ESRI, the ESRI globe logo, ArcCatalog, ArcGIS, ArcIMS, ArcMap, ArcObjects, ArcPad, ArcSDE, ArcToolbox, www.esri.com, and @esri.com are trademarks, registered trademarks, or service marks of ESRI in the United States, the European Community, or certain other jurisdictions. Other companies and products mentioned herein are trademarks or registered trademarks of their respective trademark owners.

(3)

May 2007

ArcGIS Pipeline Data Model

Version 4.0

Abstract and Core Classes

An ESRI Technical Paper

Contents Page

Forward ... 1

Executive Summary ... 3

1.0 Introduction... 5

2.0 What Is the APDM? ... 5

3.0 Why Use the APDM?... 6

3.1 The Business Case... 6

3.2 The Technical Case... 10

4.0 History of the APDM ... 12

5.0 APDM Steering Committee ... 13

6.0 APDM Technical Committee... 13

7.0 Difference Between a Standard and a Template... 14

8.0 Design Rationale ... 14

9.0 Core Elements ... 15

9.1 Stationing and Station Equations ... 16

9.1.1 Distance Based ... 18

9.1.2 Arbitrary (Pseudo-distance Based)... 18

9.2 The Centerline (Routes, Measures, and Events) ... 19

9.3 Hierarchy... 20

9.4 Coincident Geometry ... 21

9.5 Events Versus Features... 21

10.0 APDM Conceptual Model ... 22

10.1 APDM Abstract Classes/Metadata Overview... 23

10.2 APDM Abstract Classes... 23

10.2.1 What is an abstract class?... 24

10.2.2 Why are abstract classes used? ... 24

10.2.3 Duplication of Attributes within APDM abstract classes ... 25

10.2.4 Inheritance (How to read the APDM Logical Model Poster)... 26

10.2.5 Abstract Class Definitions... 30

10.2.5.1 APDMObject ... 33

10.2.5.2 ObjectArchive ... 33

(4)

ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes May 2007 Contents Page 10.2.5.4 NonFacilityObject... 36 10.2.5.5 FacilityObject... 37 10.2.5.6 FeatureArchive... 38 10.2.5.7 CenterlinePolyline... 40 10.2.5.8 CenterlinePolylineEvent ... 41 10.2.5.9 CenterlinePoint ... 42 10.2.5.10 OfflineFeature ... 43 10.2.5.11 OfflinePoint... 44 10.2.5.12 OfflineFacility... 45 10.2.5.13 OfflineNonPointFacility ... 46 10.2.5.14 OfflinePointFacility ... 47 10.2.5.15 OnlineFeature... 48 10.2.5.16 OnlinePolyline ... 49 10.2.5.17 OnlinePolylineForOfflineFeature ... 50 10.2.5.18 OnlinePoint ... 52 10.2.5.19 OnlinePointForOfflineFeature ... 53 10.2.5.20 OnlineFacility ... 54 10.2.5.21 OnlinePolylineFacility ... 55 10.2.5.22 OnlinePointFacility ... 56 10.2.5.23 Fitting... 56 10.3 APDM Metadata... 57 10.3.1 Class-level Metadata... 58 10.3.1.1 ReferenceMode ... 58 10.3.1.2 APDMClass ... 67 10.3.1.3 OnlineLocationClass... 68 10.3.2 Feature-level Metadata ... 77

10.3.2.1 Online Event Feature-Level Metadata Attributes ... 78

10.3.2.2 ControlPoint Feature-Level Metadata Attributes... 82

10.4 APDM Core Classes and Relationships... 89

10.4.1 EventID... 94

10.4.2 Core Object Classes... 94

10.4.2.1 Activity ... 94 10.4.2.2 ActivityHierarchy ... 95 10.4.2.3 AltRefMeasure... 97 10.4.2.4 <class name>Audit ... 98 10.4.2.5 Company ... 100 10.4.2.6 ExternalDocument ... 101 10.4.2.7 LineLoop... 102 10.4.2.8 LineLoopHierarchy... 106 10.4.2.9 OwnerOperator ... 108 10.4.2.10 Product ... 108 10.4.2.11 SubSystem... 109

(5)

ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes May 2007

Contents Page

10.4.2.12 SubSystemHierarchy... 112

10.4.3 Core Feature Classes ...114

10.4.3.1 ControlPoint... 114

10.4.3.2 Site ... 116

10.4.3.3 StationSeries ... 117

10.4.3.4 SubSystemRange ... 119

10.5 APDM Core Domains ...121

10.5.1 Required Domains...122 10.5.1.1 gnOperationalStatus... 122 10.5.1.2 gnStatus... 122 10.5.1.3 clStationEditResponse ... 123 10.5.1.4 clXYEditResponse... 123 10.5.1.5 clZEditResponse ... 123 10.5.1.6 gnOnlineLocationMechanism... 124 10.5.1.7 gnHistoricalState... 124 10.5.1.8 gnAngle... 124 10.5.1.9 clEditResponse... 125 10.5.1.10 gnAPDMClassType ... 125 10.5.1.11 gnRefModeBasis... 126 10.5.1.12 gnRefModeType ... 126 10.5.1.13 gnRefModeUnits... 126 10.5.1.14 gnYesNo ... 127 10.5.1.15 gnRequiresGeometry ... 127 10.5.2 APDM Compliance...127

10.5.3 Non Geometric Features ...129

10.5.4 Topology...134

10.5.5 Centerline ...134

10.5.6 Structure...136

11.0 Implementation Issues ...136

11.1 The APDM and ‘Inline’ History...136

11.1.1 Inline History Implementation ...138

11.2 Using the APDM in a Versioned Geodatabase Environment ...141

11.3 Features as Events, Events as Features ...142

11.4 Topology and the Geometric Network...142

11.5 Developing Applications ...143

11.6 The APDM and Other Pipeline Data Models ...144

11.7 Conversion To/From PODS and ISAT ...145

11.8 Getting Data into the Model...145

12.0 Model Future...146

Appendix A - Standards and Conventions...147

Naming Conventions ...147

(6)

Contents Page

Foreign Keys...148

Use of Feature Datasets ...148

Maximum String Size...149

Documentation Standards...149

Object or Feature Class...149

Attributed Relationship Class ...150

Appendix B - Glossary ...152 A ...152 B ...153 C ...154 D ...157 E ...159 F ...160 G ...161 H ...163 I ...163 J...164 K ...165 L...165 M...167 N ...168 O...168 P ...171 Q...173 R ...173 S ...175 T ...177 U ...178 V ...178 W ...178 X ...179 Y ...179 Z ...179

Appendix 3 – APDM 3.0 to APDM 4.0 Conversion Utility Script ...180

Disclaimer ...180

(7)

Forward

It has always been the intent of the ArcGIS Pipeline Data Model (APDM) Technical Committee to keep pace with the technology released by Environmental Systems Research Institute (ESRI). One of the primary purposes of the APDM is to explore how ESRI technology can be best utilized for the pipeline industry. Every year ESRI unfolds new approaches to spatial analysis, new data structures, and new desktop and server tools. These new capabilities impact the APDM in wonderful and challenging ways. The question often arises “When will the APDM become stable?” The uniform response is “It is stable, but it will always evolve.”

It is fair to say that the APDM Version 4.0 represents a significant step forward from the APDM Version 3.0. The APDM Version 1.0 strove to capture the salient information about the pipeline world. Version 2.0 sought to define the APDM as a customizable template that could be extended to meet end user needs, and Version 3.0 sought to refine the information captured in the previous two releases and align it with the ArcGIS 9.0 technology offered by ESRI. The focus of Version 4.0 has been to define, capture and store the ‘behavior’ of pipeline systems, particularly that of reference modes (stationing) and response to ‘centerline’ editing. In addition, Version 4.0 is designed to take

advantage of ArcGIS 9.2 technology.

A byproduct of encapsulating behavior is the concept and rule of APDM compliance. As more operators adopt the APDM and more vendors develop applications for the APDM, the need for ‘interoperability’ becomes paramount. Interoperability can be loosely defined as ‘the exchange of and description of data, schema and behavior between different implementations, and within a single APDM implementation.’ A requirement for ‘interoperability’ is ‘compliance’ to the rules of the APDM. What was called the ‘core’ in the APDM 3.0 is still the ‘core’ in the APDM 4.0. Core refers to those schema items that are required. What were called the ‘conceptual’ classes in the APDM 3.0 are now referred to as ‘abstract’ classes in the APDM 4.0. The abstract classes denote the set of ‘required’ attributes, domains and relationships that make an APDM 4.0 model

compliant. The APDM 4.0 abstract classes are expanded and refined in comparison to Version 3.0.

The whitepaper, the logical model diagram and the physical Unified Modeling Language (UML) model have all been re-worked to consistently reflect the ‘compliance’ structure within the APDM. If all feature and object classes within a particular APDM

implementation properly inherit from the APDM abstract classes and metadata structures, then the implementation is considered compliant. Compliant APDM implementations facilitate data sharing and easier application development since the root behavior is now defined within the model. Essentially, the APDM Version 4.0 still adheres to the

principal that an end user editing and updating features within an APDM geodatabase can do so using out-of-the-box ESRI software tools.

(8)

Another question common to operators considering adoption of the APDM is whether any one vendor ‘owns’ the APDM and controls it. The answer to this question is “Yes, ESRI owns the APDM.” However, while ESRI owns the APDM, control of the APDM rests with the pipeline industry at large via the APDM Steering and Technical

committees. ESRI does not consider itself a standards body, nor does the APDM consider itself a ‘standard’ data model.

The APDM is available on the web for free to all ESRI users (www.apdm.net). The model is open to everyone, even to competing interests. The APDM is founded on the supposition that an open and free model, supported by the volunteer efforts of ESRI pipeline users, will confer lasting benefits on the entire ESRI pipeline community. The goal of the APDM is to publish a data model that can be used to facilitate consensus and interaction between various pipeline interests working with ESRI technology. The APDM is a template-based model (just like every other model available from ESRI) that works on a common ‘abstract’ model that can be expanded to suit the needs of any pipeline operation. This allows operators to create value-added data model

implementations that can support the tools and applications specific to their organization, and yet still remain APDM compliant.

Lastly, you will soon discover the APDM is rife with its own peculiar, pipeline-specific terminology and nomenclature. Every effort has been made to present the material in a readable and understandable fashion. This document contains a wealth of information describing the structure, content and semantic behavior of the APDM. Please let us know if the material requires revision or clarification.

Submitted on behalf of the APDM Technical and Steering Committees. May, 2007

(9)

Executive Summary

Today’s pipeline operating environment is more demanding than ever. In order to be successful, pipeline companies must not only provide a competitive return on investment to shareholders, but also ensure healthy relationships with other stakeholders including regulatory agencies, the public at large, emergency responders, environmental interest groups, customers and suppliers. In response to these pressures, many operators are focusing on a strategy of operational excellence. Operational excellence implies an effective infrastructure for knowledge and data management, data analysis, and reporting. For many pipeline companies, a deployment of ESRI’s Geographic Information System (GIS) technology utilizing the ArcGIS Pipeline Data Model (APDM) can provide a superior platform for data management. Superior data management results in improved pipeline integrity management, together with attendant improvements in productivity, cost reduction and cost avoidance.

The APDM is designed to store information found in gathering and transmission pipelines, particularly gas and liquid systems. The APDM is expressly designed for implementation as an object-relational ESRI geodatabase for use with ESRI's ArcGIS® and ArcSDE®_{products. The APDM is the only pipeline data model designed to take}_full advantage of ESRI’s advanced GIS spatial data management and analysis technology. Unlike other available pipeline data models, the APDM can only be implemented with ESRI geodatabase technology.

The APDM is intended to be a flexible data model template that any pipeline company can readily modify to suit its own needs. Companies with existing relational databases may choose to migrate to the APDM to take advantage of the ESRI geodatabase data management environment. Such companies are expected to extensively modify the APDM template to conform the APDM to the requirements of their existing data stores. For companies without an existing data model, the APDM ships with a variety of optional, example classes (analogous to relational database tables) which can be used to store many types of pipeline information.

All of the features in the APDM can be organized into one of three categories: 1)

Abstract classes, 2) Core classes, and 3) Optional Classes. The abstract classes define the framework of the APDM; all other classes in the APDM inherit properties, relationships and behaviors from one of the APDM abstract classes. The APDM abstract classes are required elements of the model. The core classes are those object, feature and relationship classes, together with associated domains, that are required to maintain APDM

compliance. The core classes define the APDM centerline features, stationing attributes, and supporting model elements. The optional classes are defined in a separate document (ArcGIS Pipeline Data Model Version 4.0 Optional Classes). The optional classes are included as implementation examples, but none of them are required elements of the model. The optional classes are included to provide a starting template for companies with no existing pipeline data model.

(10)

The APDM was initiated in 2002. The intellectual property of the APDM is owned by ESRI. Ongoing maintenance and enhancement of the content and structure of the APDM is governed by and performed by the elected members of the pipeline industry managed APDM Steering and Technical committees, respectively.

(11)

May 2007

ArcGIS Pipeline Data Model Version 4.0

Abstract & Core Classes

1.0 Introduction

This technical paper explains the ArcGIS Pipeline Data Model (APDM) and is intended for those interested in implementing a transmission pipeline geodatabase using ESRI® ArcGIS®_{software. The document is written for pipeline GIS professionals, company} managers, developers, and graphic system operators. It provides a detailed description of the objects in the model, how the model is organized, and suggestions on how the model can be implemented within an organization. The document assumes that the reader has a working knowledge of common pipeline terminology and pipeline-specific GIS terms, such as stationing, centerline, station series, and control points, and a working knowledge of ESRI linear referencing technology. A glossary is provided to explain terms pertinent to the APDM. This document concentrates on the abstract and core classes of the APDM; the optional classes that are distributed as implementation examples are discussed in a separate document, ArcGIS Pipeline Data Model Version 4.0 Optional Classes.

2.0 What Is the APDM?

The ArcGIS Pipeline Data Model is designed for storing information pertaining to gathering and transmission pipelines, particularly gas and liquid systems. The APDM was expressly designed for implementation as an ESRI geodatabase for use with ESRI's ArcGIS and ArcSDE®_{products. A geodatabase is an object-relational construct for} storing and managing geographic data as features within an industry-standard relational database management system (RDBMS).

The APDM is developed and governed by Steering and Technical Committees under the umbrella of ESRI. The Steering and Technical committees include representatives from pipeline and pipeline vendor companies. ESRI helps facilitate the development and use of the APDM to serve the needs of their client base. While ESRI owns the APDM, control of the APDM is vested in the user community. The APDM model and supporting documentation is freely available and accessible to everyone via the web at www.apdm.net.

ESRI does not consider itself a standards body; therefore, in keeping with the spirit of other published ESRI models, the APDM is not intended to be a comprehensive or all encompassing model. Rather, the APDM is designed to be a starting template of core elements from which a pipeline company can craft a model tailored to its business needs by adding features or refining existing features within the rules defined by the APDM template. A primary objective of the model is to account for linear referencing of features (stationing). Most transmission pipeline companies refer to the location of features or

(12)

events that occur along the pipeline system as events occurring along a route (station series) at a certain distance (measure). Stationing is handled in the model using out-of-the-box ESRI technology referred to as routes and measures.

The APDM is designed as a starting point. It is neither the purpose nor the focus of the APDM technical committee to design a model that is a comprehensive description of all possible features found in a pipeline system. Nor is it the intention of the model to prescribe a rigorous methodology or standard approach to modeling pipeline systems. The model’s intent is to provide a set of core objects and attributes that describe and effectively handle stationing, plus a core set of abstract classes by which most, if not all, pipeline features can be categorized. The purpose behind providing a core set of features is to provide pipeline and vendor companies with a consistent framework for developing applications against the model, and for data transfer between existing databases. By this approach, any pipeline company can add features to the model, modify existing features in the model, or subtract features from the model as required by business needs. The core elements of the model remain a small subset of the features found in the model. Any new features added must fall into one of the abstract APDM classes including referenced and non-referenced features, and online and offline features. Another focus of the APDM is to develop a model that end users can implement and add data to without the need for custom code or development efforts. This is achieved by using core ESRI technology that allows any pipeline company to develop a tailored data model that meets its business needs while maintining compatibility with ESRI tools.

3.0 Why Use the APDM?

A variety of factors are driving pipeline operators towards more advanced and effective pipeline data management tools; these business drivers provide the ultimate impetus for a pipeline company to adopt ESRI geodatabase technology and the APDM. Of course, there are other options besides ESRI geodatabase technology and the APDM for managing pipeline data, but an APDM geodatabase implementation offers several advantages over available alternatives in terms of efficiency, effectiveness, reliability, cost, and capability. The business and technical cases for the APDM are outlined below.

3.1 The Business Case

The pipeline operating environment is more demanding than ever. In order to be

successful, pipeline companies must not only provide a competitive Return on Investment (ROI) to shareholders, but also ensure healthy relationships with other stakeholders including regulatory agencies, the public at large, emergency responders, environmental interest groups, customers and suppliers. Any successful pipeline company must develop effective strategies for dealing with the following challenges:

Profitability – The ultimate goal of a pipeline operator is to achieve maximum

profitability while maintaining safe and reliable system that meets or exceeds industry and regulatory standards.

(13)

Regulatory Pressure – In the wake of tragic accidents such as the Bellingham, WA

incident of 1999, public outcry elicited a response from the federal government in the form of increasingly demanding and prescriptive regulations. The Pipeline Safety Improvement Act of 2002 resulted in amendments to CFR Title 49 § 192 Subpart O – Pipeline Integrity Management, and CFR Title 49 § 195 Subpart F – Operations & Maintenance (§ 195.450 High Consequence Areas, and § 195.452 Pipeline Integrity Management) for interstate gas and liquids transmission pipeline operators, respectively. These new regulations require operators to develop an unprecedented level of knowledge regarding their pipelines and environments in which they operate in order to create highly detailed pipeline Integrity Management Programs (IMP’s). Annual audits performed by the Pipeline and Hazardous Materials Safety Administration’s (PHMSA) Office of Pipeline Safety (OPS) under the auspices of the U.S. Department of Transportation (DOT) are designed to enforce regulatory compliance. Failure to comply can result in spectacular fines and disruption of business operations; this makes the IMP a critical element of any pipeline company’s profitability strategy. Effective integrity management also implies optimized availability of pipeline assets for operations resulting in increased revenue and increased opportunities for operational cost reduction through improved operational efficiency and reliability.

Operational Complexity – As technology and business management practices evolve,

organizations such as pipeline companies are becoming increasingly complex in nature. Increasingly the activities of a business unit are dependent upon and/or affect the

activities of other units. For example, Control Centers interact with Engineering departments to design and monitor line pressures, likewise relying on Emergency Response and Environmental groups to respond to incidents, further demanding a tight integration with frontline Field and ROW personnel to execute on site activities. Almost every activity within a pipeline organization requires coordination across multiple business units. This evolving complexity presents challenges and opportunities for cost reduction by increasing efficiency and greater output through discovering and realizing synergies.

Aging Infrastructure – Much of the nation’s pipeline infrastructure is approaching the

latter stages of its original designed service life. Successful management of aged pipelines requires extraordinary diligence and attention to detail. Modern inline

inspection, direct assessment, and close interval survey methods are all critical elements of an effective Baseline Assessment Plan (BAP) and ongoing mitigation plans, but these tools and processes all produce tremendous volumes of information. Failure to effectively manage and analyze this information leads to inefficient or even fatally flawed mitigation plans. Thus, effective data analysis and management is key to service reliability,

operational cost reduction and cost avoidance strategies.

Suburban expansion – Formerly rural pipeline Rights Of Way (ROW) are being

(14)

response and public notification burdens, potential for third party damage, complexity of risk analysis, and the financial, operational, litigable and regulatory consequences of an unintended product release. Effective strategies for dealing with suburban encroachment are a critical aspect of any pipeline company’s cost optimization strategy.

Mergers, Acquisitions & Restructuring – As pipeline systems change hands, many

companies find themselves faced with the tasks of integrating staffs, business processes and workflows, and data management systems. Failure to do so results in increased operating costs through staff inefficiency, and increased regulatory exposure.

‘Graying’ of the Workforce – For many pipeline companies, much of the corporate

knowledge base is stored in the brains of senior staff. As these employees retire, critical knowledge is irretrievably lost. Whenever such knowledge is lost, unnecessary cost is incurred to reproduce it. In some cases the consequences of lost knowledge can be dire from both an operational and financial standpoint. Thus, an effective knowledge and data management infrastructure becomes an important cost reduction and cost avoidance tool. In response to above challenges, many operators are focusing on a strategy of operational excellence achieved through the incorporation of new technology and processes to integrate and optimize the organization. In the Information Age, operational excellence implies an effective infrastructure for knowledge and data management, data analysis and reporting. Increasingly, operators are realizing that the traditional hardcopy-based or CAD-based data management environment is simply not up to the task. Indeed, for some of the more prescriptive regulations such as gas or liquids High Consequence Area (HCA) analysis, a GIS-based platform is practically required. As discussed below, ESRI geodatabase technology and the APDM provide a superior foundation for data and knowledge management.

For pipeline operators, an effectively implemented data management system based on the APDM can becomes an integral part of the operations and asset management framework. Effective implementation enables increased productivity, cost reduction and cost

avoidance. Increased productivity is achieved through optimized maintenance planning and execution with reduced downtime, resulting in greater output and increased available capacity for operations. Cost reduction is achieved through increased staff and

operational efficiency and reductions in rework and unnecessary work. Cost avoidance is improved through increased operational safety and reliability, and through reductions in regulatory fines, unfavorable litigation judgments, and ultimately, avoidance of consent decrees and corrective actions.

An effective data management platform such as APDM can reduce the time it takes to perform tasks such as data maintenance and integration, freeing company personnel to spend more time on critical functions such as analysis of and response to information. More time is available for preventive maintenance activities, project planning and oversight, and other work in need of completion. Likewise, by automating traditionally

(15)

manual and inefficient functions, overtime can be reduced and in some cases, headcount can be reduced as well, thereby reducing operating costs. For example, the APDM enables deployment of advanced mobile electronic field data collection and

communication. In many cases, the conversion from paper forms to electronic data capture can result in a 20-40% reduction in time spent on a given activity by field inspectors and technicians. For a full time inspector paid $50K per year, the net savings can range from $10-20K per inspector. Based on the size of the organization, this alone can amount to significant savings when implemented throughout the company.

Other expenses typically reduced with implementation of the APDM include the

reduction and in many cases elimination of time spent integrating disparate data sets and the time and cost to create and update maps and drawings. Further, advanced data integration and analysis is enabled and can be used to justify project deferrals or even avoidance. For example, the integration and assessment of Close Interval Survey (CIS) data combined with InLine Inspection (ILI) data can be used to develop engineered criteria for adequate cathodic protection levels, which many times justifies the deferral of projects such as Cathodic Protection (CP) installations, excavations and rehabilitation projects. It should not be unexpected that a mature implementation of an enterprise data management system based on the APDM can reduce pipeline maintenance costs by as much as 5-10%. For a pipeline company with an annual maintenance budget of $20 MM, this can result in savings in excess of $1MM per year. Eventually, the extension of the system to facilities and tank farms may further extend the ability to reduce operating expenses.

A significant benefit from any solution is the ability for it to lead to increased revenues. In the case of the APDM, it is a platform that when implemented effectively will lead to better informed decision making, faster data collection, communication and processing and rapid response to identified needs. New capabilities can enable the monitoring of anomalies versus shutdown and excavation, the optimization of maintenance planning and scheduling to reduce unnecessary work and the better coordination of needed work. Over time, it should be expected that an enterprise-wide improvement in information management, communication and decision making will lead to improvements in capacity availability and utilization of anywhere from 2-10%. Conservatively speaking, if

available capacity can be increased by 1% on a gasoline system that on average transports 1MM barrels per day at a revenue of 1$ per barrel, then increased revenue could amount to on average over $10,000 per day.

Increased productivity, cost reduction and cost avoidance are important factors in improving ROI, but ROI is only one part of a balanced scorecard. Many pipeline

companies are focused on being excellent corporate citizens. An effective platform based on the APDM can become an important tool for maintaining a positive image and good relationships with all of the pipeline’s important stakeholders: regulatory agencies, the public, emergency responders, environmental groups, customers and suppliers.

(16)

Many of the cost justifications developed above for an APDM implementation can be equally applied to an effective, spatially enabled implementation of a relational pipeline database such as Integrated Spatial Analysis Techniques (ISAT), Pipeline Open Data Standard (PODS), or Industry Standard for Pipeline Data Management (ISPDM). However, the APDM and ESRI geodatbase technology offers additional cost benefits over these relational technology alternatives.

Reduced ‘entry cost’ – For smaller operators, the APDM can be implemented in a

personal, file or workgroup geodatabase, eliminating the need for enteprise RDBMS software such as Oracle or SQL Server, together with attendant Database Adminstrator (DBA) and System Adminstrator (SA) personnel costs. To spatially enable a relational pipeline database, an enterprise RDBMS is effectively required. Thus, for smaller operators, significant support staff headcount reduction and software capital expenditure savings can be achieved with an APDM implementation relative to a relational pipeline database implementation.

Reduced software development / software purchase expenditures – Spatially enabling a

relational pipeline database with ESRI technology calls for the use of extended stored procedures (utilizing ArcObjects or ArcSDE C API coding in the case of ArcSDE), database triggers and/or scheduled services to synchronize the database with the GIS. Also, relational pipeline databases have no built-in capability for long transaction management, or history management. Such funcitionality is not included out-of-the-box with any of the relational pipeline models, and therefore must either be developed in-house or purchased from a vendor. In-in-house development of such functionality may require several staff years (or more) of effort; purchase from a vendor requires some fraction thereof in equivalent capital software expenditure. This extra code requires maintenance, so some attendant support staff headcount is required. Because the APDM is a geodatabase, the need for such database synchronization software is eliminated; long transaction capability and history management (archiving) are built in. Relative to a relational pipeline database implementation, the APDM enables reduced support staff headcount and/or reduced capital expenditures for third-party software.

To equal out-of-the-box APDM geodatabase functionality requires excessive investment in in-house software development. Practically, the only viable way to an effective spatially enabled relational pipeline database implementation is through third-party vendor tools. However, with the APDM it is possible to maintain the geodatabase with out-of-the-box ESRI tools. This frees an operator to reserve capital and staff resources for higher value activities than simply maintaining the pipeline database.

3.2 The Technical Case

As discussed above, most pipeline operators have arrived at the conclusion that hardcopy-based and simple CAD-based data management systems are insufficient to meet the demands of today’s operating environment. Some kind of advanced database-driven data management system is required. Several database-database-driven data management

(17)

options are currently available to pipeline operators: 1) a pure relational database implementation using ISAT, PODS, ISPDM, or a proprietary model, 2) a spatially enabled implementation of one or the aforementioned relational models using GIS technology, and 3) a pure ESRI geodatabase implementation utilizing the APDM. ESRI geodatabase technology is still relatively new compared to traditional RDBMS technology. SQL access to a versioned geodatabase is somewhat complicated, and SQL edit capability is somewhat limited. Some feel that geodatabase implementations are more difficult to integrate with existing relational enterprise databases than an equivalent relational database implementation. The prime consideration in determining whether to select the APDM in lieu of a standard or GIS-enabled relational database model is this: Do the benefits of ESRI geodatabase technology– analytical, cartographic, and editing functionality– override the need to integrate the database with other enterprise relational applications and data access technologies? The primary advantage of the geodatabase over a relational model is summarized by the following observations:

• The RDBMS enforces referential data integrity, but not spatial data integrity. • The geodatabase enforces both referential and spatial data integrity.

The RDBMS cannot easily enforce the link between feature geometry and attribute data. To use a GIS with relational pipeline data models such as ISAT or PODS, the GIS is typically ‘grafted’ on to the relational model. When ESRI technology is used to spatially enable a relational ISAT or PODS database, spatial information is usually stored twice: once in the relational coordinate tables present in these models, and again in ArcSDE layers or feature classes derived from the relational coordinate tables. Editing operations in the RDBMS require application logic to drive updates of relational database attributes, which in turn are followed by feature geometry updates (or the reverse). Data

synchronization is a constant, error-prone, time-consuming, costly and troublesome issue for spatially enabled relational pipeline data models: feature geometries in ArcSDE are typically snapshots derived from the database; each time the database is modified, the feature geometries are potentially out of date and must be rebuilt.

The geodatabase seamlessly enforces the linkage between feature geometry and attribute data; in addition, it allows the construction of more complex relationships that simplify and streamline editing operations. Because of this, an APDM geodatabase

implementation avoids the problems with spatial data updates and synchronization that are typical of a GIS-enabled relational model. The geodatabase (and the APDM) offers less expensive data maintenance for interrelated spatial features and attributes as a function of the underlying data structure. As a result, the reliance on data integrity logic built into custom applications is minimized. Ultimately, these advantages result in lower data maintenance costs and greater data reliability.

Utilizing a geodatabase for storage of GIS data provides end user access to all the powerful ESRI GIS analytical technology. While a spatially enabled relational database

(18)

implementation can take advantage of some of ESRI’s advanced GIS capabilities, the same cannot be said for a pure relational implementation, and neither can take full

advantage of ESRI technology like a geodatabase. Compelling technology included in the geodatabase includes multi-user, long transaction versioned editing; coincident feature editing via topology; geoprocessing; raster-based spatial analysis; geo-statistical analysis; state-of-the-art map display/cartographic production tools; 3D Visualization using

ArcGIS Explorer®_{; integration with the Web via ArcIMS}®_{and ArcGIS Server}®_; disconnected editing via Tablet PC and handheld personal digital assistants (PDAs) running ArcPad®_{; and dynamic annotation. All of these factors combine to make an} APDM geodatabase implementation more efficient, more reliable and less costly than a relational database implementation.

Other ESRI data models could potentially be applied to pipeline; the ESRI Gas Distribution Model is one potential candidate. The APDM is designed for pipeline companies whose primary means of locating features is by linear referencing (or stationing). Ultimately, the ability to locate, edit, analyze, and organize features on or along a pipeline via stationing is what differentiates the APDM from the standard ESRI Gas Distribution Model. The APDM is developed for ESRI enterprise software

ArcGIS/ArcSDE technology, which is entirely predicated on the geodatabase. The APDM returns lower cost, more effective, efficient and reliable data creation and

management, and superior data analysis. All of these elements are important to the highly regulated and important transmission pipeline industry.

4.0 History of the APDM

The APDM is developed and maintained jointly by the ESRI APDM steering and technical committees. The technical committee is responsible for developing the structure, content, and technological aspects of the model. The steering committee is responsible for the organizational/promotional aspects of the model. Ultimately both committees fall under the umbrella of the ESRI Petroleum User Group. The core elements of the APDM embody many of the same concepts found in the ISAT, PODS, and ISPDM models. Every attempt is made to make the APDM open to data transfer between each model. The steering and technical committees strive to balance the interests of each pipeline model group, the pipeline companies, and the pipeline vendor

community. Participation in both committees is divided between operator and vendor communities, and ISAT/PODS data model members. Below is a brief chronology of the model's development:

• March 2002 – M.J. Harden starts the initial work on the model.

• July 2002 – The model is presented at the ESRI User Conference in San Diego, California. An open invitation to participate in the design of the model is extended to the pipeline community.

• August 2002 – The initial meeting of interested member groups occurs at ESRI, Redlands, California.

(19)

• October 2002 – The steering and technical committees are officially formed at the ESRI Electric/Gas Utility User Group Conference (EGUG), Coeur d'Alene, Idaho.

• December 2002–June 2003 – Monthly technical and steering committee

meetings occur at various member organizations. Development of the intellectual property agreement, steering committee charter, technical committee mandate, operational procedures, and APDM content and structure proceed.

• March 2003 – The APDM is released for public comment at the ESRI Petroleum Users Group (PUG) meeting in Houston, Texas.

• July 2003 – Version 1 of the APDM is officially released at the ESRI International User Conference in San Diego, California.

• October 2003 – The model is reviewed and Version 2 is proposed by the APDM technical committee at the ESRI EGUG Conference in Galveston, Texas.

• August 2004 – The model is reviewed and Version 3 is released by the APDM technical committee at the first APDM Pre-conference workshop at the 24th annual ESRI International User Conference in San Diego, California.

• March 2005 – The model is reviewed and Version 4 is proposed by the APDM technical committee at the ESRI PUG meeting in Houston, Texas.

• July 2005 – The second annual APDM pre-conference workshop held at the 25th annual ESRI International User Conference in San Diego, California.

• June 2006 – The model is reviewed and Version 4 is released for review by the APDM technical committee via the APDM web site (www.apdm.net).

• September 2006 – Work begins on APDM v5.0.

• May 2007 – The final draft of APDM v4.0 is released via the APDM web site (www.apdm.net).

Active members of the Pipeline Interest Group (PIG) elect the members of the APDM steering and technical committees. Elections occur at the annual PUG meetings (March of each year). Steering committee terms are one year in length; technical committee terms are two years in length.

5.0 APDM Steering Committee

A ten (10) person committee is charged with setting the organizational direction of the APDM within the context of the pipeline industry. The Steering Committee meets once per month via phone conference on the second Wednesday of the month. Craig Wilder ([email protected]) is the current chairperson of the APDM Steering Committee.

6.0 APDM Technical Committee

A ten (10) person committee charged with developing the technical content of the APDM model. The technical committee meets three times per year during the ESRI Petroleum User Group Conference (PUG) in February/March, the annual ESRI User Conference held in July/August and the GITA Oil & Gas Conference (September). Technical

(20)

the technical committee members are allowed to vote on changes to the APDM. Peter Veenstra ([email protected]) is the current chairperson of the APDM Technical Committee.

7.0 Difference Between a Standard and a Template

The APDM is intended to be a template, not a standard. There is no governing

organization that has officially approved the APDM as a standard. The features and relationships included in the model are deemed critical or common to 80 percent of all pipeline companies' typical implementations of geographic information system

technology. The APDM, similar to most other published models on the ESRI Web site, represents core features found in almost every pipeline system. The intent of the model is not to create a database standard, but rather to create a database template from which custom models can be created and evolved. However, one of the design criteria of the model is to create and delineate core elements that must be maintained in order to preserve a standard for data transfer, application development, and conversion efforts between APDM implementations.

8.0 Design Rationale

The APDM is a geodatabase model developed for managing transmission and gathering (gas and liquid) pipelines. This section outlines the design rationale considered at every stage in development of the APDM. These justifications served as guidelines for ensuring the model meets the needs of the pipeline industry. Each justification describes some of the considerations and background material measured and weighed to determine the final model.

This section is divided into the following parts, each of which describes the driving forces behind how the APDM was developed.

• Core Elements

• Stationing and Station Equations

• The Centerline (Routes, Measures, and Events) • Hierarchy

• Coincident Geometry • Events Versus Features

Later sections of this document describe in more detail the content and structure of the APDM. It is important to realize that no single pipeline data model can do everything for all organizations. Realizing the variation in how data is modeled between different pipeline companies, the technical committee developed the APDM according to four guiding principles:

1. The APDM is designed to provide a set of core elements that remain consistent for any APDM implementation. The core elements are designed to ease data

(21)

transfer between existing pipeline data models and for the development of portable APDM applications by third party vendors.

2. The APDM provides a mechanism for locating features on or along the pipeline centerline by both absolute positioning and by linear referencing (commonly referred to as stationing). It is not the purpose of the APDM to prescribe the approach to implementation for the model. These features can exist as geometric features in feature classes, dynamic events in event tables, or a combination of both.

3. Features (or tables or objects) are included in the APDM if they are required by 80 percent of all pipeline companies and by the United States government regulatory agencies.1

4. The APDM can be implemented and maintained within a geodatabase without the need for custom application code.

9.0 Core Elements

The prime object of the technical committee is to promulgate a small, well-defined set of core objects with required attributes. These core elements provide the mechanism for linear referencing to locate events as geometric features or dynamic events. The core also provides a foundation from which other features can be added to the model, or from which existing features in the model can be customized as required (provided that the core elements remain intact and immutable). The core elements are required for

maintenance of the centerline and stationing. The core elements are classified into a set of conceptual features (abstract classes) that provide an aid to determining how additional model elements can be classified and organized within the APDM.

If the core objects (tables, feature classes) and attributes are immutable, then the remainder of the geodatabase is optional and totally customizable. The feature classes, other than the core feature classes, that are distributed with the model provide examples of the most common features, rather than being an all-inclusive description of every possible feature found on or along a pipeline system. The purpose of the APDM is to allow pipeline companies to build geodatabases to suit their business needs. The core elements of the model provide a standard set of features– the rest is up to the end user. Users may pick and choose which elements to include, which to remove, and which to alter to suit their needs. Other than the core elements of the model, it is up to the user to determine what is or is not included in the model.

1

The APDM technical committee is aware the APDM will be implemented in international settings. Every attempt is made to avoid an American-centric view of the model. It is the carefully weighed opinion of the committee that transmission pipeline regulations in the United States are some of the most rigorous in the world. Many of the companies participating in the development of the model have holdings and operations outside of the United States and are consulted during model development to facilitate the requirements of the international pipeline community.

(22)

The amount of data that pipeline companies are able to access has exponentially increased within the last decade. In the historical paper world it was conceivable to manage thousands of features. With the advent of faster computers, better integration between disparate systems, and the proliferation of readily available digital data in a wide variety of formats, the potential for the management of millions, if not billions, of

features is quite conceivable for many large pipeline companies. By keeping a small core of required elements, the APDM is very open and flexible to integration with larger corporate or enterprise data systems. In this manner, the APDM can be implemented as the front door to the enterprise repository of data. By spatially modeling a detailed, rich set of features, the GIS can be seen as an extension of the entire enterprise data

warehouse.

9.1 Stationing and Station Equations

Traditionally, the location of pipeline features on a pipeline was determined by station series and station value. A station series is a linear path representing a portion of the centerline of the pipeline or the route that the pipeline follows across the surface of the earth. The cumulative measure of 'stationing values' from the start of the station series to the terminus of the station series is called station position. An infinite number of events can be located along a station series representing the location of a feature, or the start and end of a linear feature.

At each point along the station series (including the start and endpoints) where the centerline bends either horizontally or vertically, a control point is placed. Control points are known points of stationing (measured distance along the station series) and have known coordinate values. Each control point forms the vertex of a station series linear feature. Each station series is thus composed of two or more known points of stationing. Stationing monotonically increases or decreases without gaps from the begin point to the endpoint of a station series. Once stationing is assigned to the centerline, the stationing values for known points along the centerline usually do not change. When the pipeline is first built, the stationing measurements are uninterrupted and continuous along the length of the entire pipeline. When a pipeline is rerouted (i.e. the path of the centerline is

altered), discontinuities are introduced into the stationing. The points of the breaks in stationing are known as station equations. Once an equation is introduced into the

centerline, the stationing is altered for the portion of the centerline that has been rerouted with the addition of a new station series.

Any event occurring between two control points has a station value calculated by the interpolation of station values of the known control points on either side of the event. Traditional GIS implementations store point, linear, and polygon features by absolute coordinates for each vertex of the feature. Using stationing (linear referencing or relative positioning), a dynamic method for determining the location of a feature (or event) is available. The ESRI geodatabase supports both of these methods. Once the location of a feature is determined using either absolute or relative positioning, the alternative

(23)

features is available). It is important to realize that the ArcGIS Pipeline Data Model puts more emphasis on absolute rather than relative positioning. If the underlying control point and station series network is highly representative of the underlying terrain, with accurate positioning in sufficient density, then the calculation of relative position is easily obtained once the station values of known control points are determined and quantified. However, display performance for large numbers of dynamically positioned features is usually less than optimal.

Transmission pipeline stationing systems have been historically developed through field survey methods. Given the coordinates and an arbitrary station value for a known starting point, the surveyor delineates the centerline of the pipeline using a distance (measured by chains) and deflection angle from the last collected point of the centerline. The angle and distance traverse established from point to point creates what is known as the centerline. The known points created from the angle and distance measurements are the control points of the pipeline. Only recently, and in small instances, has absolute positioning– with the advent of the global positioning system (GPS) coordinates used in conjunction with highly accurate digital rectified orthophotography– become mainstream for creating the control points that define the centerline.

Stationing is based on traditional field survey and drafting methodology and is the historical method of conducting business for a pipeline. Stationing is the primary method for historical record keeping that pipeline companies are required to maintain for

regulatory purposes as required by the Federal Energy Regulatory Commission (FERC), the Office of Pipeline Safety (OPS) as part of the Department of Transportation (DOT), and the National Pipeline Mapping System (NPMS). Pipeline companies in North America are required to locate all facilities on or along the pipeline. Stationing is used to locate pipeline features on a foot-by-foot basis in the field by stepping off or pacing off locations of events from known points along the pipeline.

Stationing has historically been used in transmission pipelines for locating features along the pipeline centerline. With the advent of ubiquitous GPS and GIS technology, a case can be made for discontinuing the use of stationing as a location mechanism. However, the following list presents many valid reasons for continuing with stationing as a useful and effective mechanism for locating features:

• Historically features have been located along pipeline system by stationing. Large historical archives of stationed position exist, creating a valuable resource of location information.

• The field crews of pipeline operating companies are versant in the use of

stationing for referencing and rely on a repository of heuristic location methods to locate and map features.

(24)

• Despite the recent mainstream introduction of GIS systems to the pipeline industry, many operating companies lack sufficient land base style data to locate features by means other than stationing.

• It is cumbersome to repeatedly enter 15+ digit coordinate values to locate features. This is especially true considering that a point coordinate may not be unique in the case of large pipeline systems that span several map projection zones.

• Linear referencing and dynamic segmentation of spatially coincident linear features can be done rapidly when using features ordered by station values. ESRI has invested significantly in this core technology.

• Linear referencing (and the APDM implementation thereof) allows for a very powerful and flexible representation of multiple stationing systems that can be used in conjunction with each other to locate features in an ad-hoc fashion. • Stationing is the only mathematical mechanism to systematically account for any

given point along the pipeline system from beginning to end. Since stationing is mathematically based, features can be sorted by station value upstream and downstream along a centerline for the purposes of reporting and analysis. In this manner, pipeline operators can ‘walk the entire pipeline foot by foot’.

The more common forms of stationing measurement are described below.

9.1.1 Distance Based

• Slack Chain (also referred to as slope, vertical, or engineering) – The distance between two points is the three-dimensional distance along the earth's surface, rather than the two-dimensional distance between the points, and is used to determine station value along the pipeline (e.g., the distance of a chain draped over the ground rather than the surveyed vector distance).

• Horizontal – The two-dimensional map vector distance between two points, not taking into account any z changes in the surface between the two points, is used to determine station value along the pipeline (e.g. two-dimensional vector distance). • Continuous – Stationing starts at a set value and continuously and cumulatively

measures either slack or horizontal distance from the start to the end of a centerline along all station series.

(25)

• Mile Posting – Posts or other markers are placed in or on the ground at arbitrary intervals and are used as reference points for locating features.

• Offset Based – Measurements are taken as offset values from known points along the centerline (e.g., valve section– the feature is located 100 feet downstream from the mainline valve).

9.2 The Centerline (Routes, Measures, and Events)

The centerline of a pipeline system is composed of station series features, which in turn are composed of control points. The station series concept allows each and every station value (e.g., a point location) along the pipeline centerline route to be uniquely located at a specific geographic coordinate even when duplicate station values exist on a single pipeline. Duplicate station values usually occur after a section of an original line is relocated or rerouted, resulting in the creation of a station equation to compensate for the additional installed pipe length. It is also possible to have duplicate station values for different line loops in the pipeline. Duplicate station values may also be created intentionally at the time of original construction. To help differentiate the locations of duplicate station values, each station series record has a unique identifier, a begin and end station value, and belongs to a line loop.

Control points are points along the pipeline centerline with known geographic

coordinates and known station values. When a group of control points is assigned to a specific station series, the centerline of the pipeline can be graphically represented in its real-world geographic location based on the selected coordinate system and map

projection. Control points occur at changes in the centerline direction of the pipeline (i.e., points of inflection [PI]), at centerline ties where a distance and/or angle exists to an offline point event with known geographic coordinates (i.e., a section corner), or at any pipeline centerline location with known geographic coordinates, such as GPS survey points.

Conceptually, station series and control points are directly analogous to ESRI linear referencing routes and measures. A station series feature is an M- (measure) Aware polyline feature called a route. The measures of the route are defined at each vertex including the endpoints. Since control points are used to form the vertices of the station series feature, the measure value in the vertex is also the station value assigned to the control point. Events are point or line entities or objects that occur on, along, or beside the centerline. Each point event on, beside, or along the centerline has an absolute position and a relative position (or absolute/relative start and end position if a linear feature). The absolute position of an event is measured by the x,y coordinates of the feature once the relative position of the event has been determined. The relative position of an event is measured by identifying a unique route (station series) and a measure value (station) that represents an interpolated distance from the start of a station series through the known control points (that act as vertices of the station series) to the point where the event occurs. If the event falls along the station series in between two control points (each

(26)

with a different station value), the position of the event is interpolated along the station series relative to the station values of the bordering control points and the station value of the event. Point events are located on a single route feature. Currently, ESRI linear referencing technology dictates that linear events must also start and end on the same route.

Station series features are modeled as M-Aware and (optionally) Z- (elevation) Aware polyline features in the APDM. Control points are modeled as M-Aware and (optionally) Z-Aware point features in the APDM. Both station series and control points are

considered core elements of the APDM.

9.3 Hierarchy

Pipeline companies often organize or group features according to a hierarchy. Typically the hierarchy is based on where particular station series features are located. Usually, the hierarchy groups together the station series features belonging to a single line. Lines are then grouped into pipeline systems. Pipeline systems are then grouped by pipeline

company. Even a simple hierarchy can be broken down into more complex organizational structures such as main lines, discharge subsystems, valve sections, and branches. There is no standard hierarchy structure to which pipeline companies adhere, but almost all pipeline companies implement some kind of hierarchy for their pipeline systems.

The most ubiquitous unit of hierarchy in pipeline systems is the line loop (e.g. the PODS Route, or the ISA Line_Loop). The APDM implements basic hierarchy by assigning each and every station series to a line loop. Line loops associated with station series are

referred to as physical line loops. However, in the APDM a line loop can be more than just a physical entity. Line loops can also be used to logically organize pipeline segments into a complex hierarchy (through recursion in the LineLoop table structure). APDM physical line loops can be used to construct many types of pipeline hierarchy elements:

• A single pipeline from the source (the gathering fields or refineries) to the terminus of the line (connection at town border stations to distribution centers or refineries).

• A mainline lateral branch. • A gathering or flow line. APDM logical line loops can represent:

• Nested gathering systems.

• Transmission pipeline systems grouped by operator, product, diameter, etc. Often several physical line loops run parallel to each other. A logical line loop may have gaps along the pipeline as a whole, as pipes are often shared between several lines. In almost all cases a physical line loop is an aggregation of one or more station series

(27)

features without gaps; logical line loops are usually the aggregation of one or more physical and or logical line loops.

The APDM does not explicitly model logical or network connectivity of station series features. Each station series feature is uniquely identified in the model. The line loop construct is used at the simplest level to organize station series features into a flat hierarchy.

Line loop is modeled as an object class in the APDM and is considered to be one of the core elements. Other hierarchical elements in the model are line loop hierarchy,

subsystem, and subsystem hierarchy, all of which are used to define the hierarchy of a pipeline system. For more detailed information, refer to the 10.4.2 Core Object Classes section, below.

9.4 Coincident Geometry

An important consideration in the design of the APDM is the prevalence of coincident point and line features in a transmission pipeline. Any feature located by relative position (stationing) is coincident or offset from the centerline. Any change in the geometry and/or the underlying station (measures) of the centerline route system has ramifications on the geometric location of features or events whose positions are dependent on the applied measures and position of the centerline. Linear features, such as coating and pressure tests, are child features dependent on the presence of parent linear features such as pipe segments. The relationship between these features dictates that if the parent is removed or altered (partially removed, or vertex position changed) then the child must be similarly altered. The same relationship applies to pipe segment (child) and station series (parent). A goal of the APDM is to mitigate the effects of editing parent feature geometry or station (measure) attributes. Relationship classes are used to maintain the station (measure) relationships between the centerline and dependent child features. ArcGIS Topology is the recommended solution for handling the geometric relationships between coincident geometries from different feature classes.

9.5 Events Versus Features

The APDM can be implemented with features stored in feature classes (geometry is stored with x,y coordinates), event tables (geometry is dynamically generated from Route-ID and measure values), or a combination of both. Each implementation approach has costs and benefits. The benefits to using geometry are that performance is excellent, the features can be displayed quickly through the Internet via ArcIMS, and the features can be edited directly in ArcMap™_{. The problem that arises when using geometry is that} feature geometries are not automatically updated when the underlying Route-ID and measure values (or begin/end Route-ID and measure values) are updated.

The benefit of using events is that whenever the Route-ID and measure values are updated, then the geometry can be quickly refreshed. If an error occurs when the event

(28)

geometry is being created, then an error message can be appended to the row containing the feature. The problem with using events is that each feature does not have a permanent geometry and, thus, display performance is poor by comparison. In addition, the features are not available for display in real time through the Internet. Large volumes (more than 10,000 events) of data cannot be expected to perform in a timely manner given the current state of the technology.

The ideal situation within the model is to have features that act as events. In this desirable state of affairs, the geometry of a feature is automatically updated when the Route-ID and/or measure values are altered. Currently, the only way to obtain this behavior from the geodatabase is via custom application code. Ultimately the choice of implementation (event or feature) remains the decision of the end user and depends on the type of GIS being implemented.

10.0 APDM Conceptual Model

All the features in the APDM can be organized into one of three categories: • Abstract classes

• Core classes • Optional classes

The abstract classes define the framework of the APDM; all other classes in the APDM inherit properties, relationships and behaviors from one of the APDM abstract classes. The APDM abstract classes are required elements of the model. However, the APDM abstract classes are not ‘concrete’; they never actually appear physically in an

implemented APDM geodatabase. The APDM abstract classes appear only in the APDM logical and physical (UML) models.

The core classes are those object, feature and relationship classes, together with associated domains, that are required to maintain APDM compliance. The core classes define the APDM centerline features, stationing attributes, and supporting model elements. The core classes are concrete; unlike the abstract classes, the core classes physically appear in an implemented APDM geodatabase.

The optional classes are just that. The optional classes are described in a separate document, ArcGIS Pipeline Data Model Version 4.0 Optional Classes. They are distributed with the model as implementation examples, but none of them are required elements of the model. The optional classes are included to provide a starting template for companies with no existing pipeline data model. Companies that are currently users of a relational model such as PODS or ISAT, or a proprietary model, may desire to replace the optional APDM classes and domains with classes and domains that more closely resemble their existing data stores. As long as the modified classes and domains follow the rules defined by the APDM abstract classes and metadata, this is entirely permissible, and indeed, encouraged.

(29)

10.1 APDM Abstract Classes/Metadata Overview

The APDM is defined as a template, rather than as a standard. Aside from minimal constraints, implementers are free to modify the model to suit their business needs. As a result, the potential for APDM implementations with widely divergent attribution and data content exists. Despite the reality of content divergence, a major goal of the APDM is to maintain interoperability across implementations and between products offered by a variety of APDM application providers. To promote APDM interoperability the APDM Steering and Technical committees have developed compliance concepts based largely on defining the semantic behavior of the APDM classes, rather than their explicit data attribute content.

Off-the-shelf ESRI geodatabase technology exposes considerable functionality for defining the behavior of spatial layers relative to each other. For example, geometric networks can be used to define connectivity rules between features residing in different feature classes. Topology feature classes can be used to define editing behaviors for spatially coincident features from different feature classes. While powerful, the off-the-shelf capabilities of ESRI geodatabase technology are insufficient to fully define the semantic behavior of the pipeline and pipeline-related features modeled in the APDM. To fully define class and feature behaviors in the APDM, two conceptual constructs are employed extensively in the APDM architecture: 1) abstract classes, and 2) metadata. APDM abstract classes may be thought of as a collection of broad ‘data type’ categories, each of which has its own defined behaviors. Variations in behavior may occur within subsets (subtypes) of an abstract class; some behaviors may even manifest at the

individual feature level. Metadata constructs are used in the APDM to define these class- and feature-level behaviors.

The APDM abstract classes and metadata constructs define complex behavior beyond that governed by standard ESRI functionality. Out-of-the-box ArcMap has no knowledge of, nor pays any attention to, APDM abstract classes and metadata. Because of this, uneducated users in an unmanaged geodatabase could inadvertently break the rules defined by the APDM abstract classes and metadata. In general, the behaviors defined by the APDM abstract classes and metadata should be implemented via application and/or geodatabase software. When implementing the APDM, the user should be careful to build or select software applications that honor the APDM abstract classes and metadata. In the absence of such software, the database administrator should strongly consider limiting direct ArcMap edit access to the APDM geodatabase to those users with sufficient knowledge of the APDM to honor the behavioral rules embodied in the APDM abstract classes and metadata constructs.