arcgis pipeline data model version 4.0 - magpie-inc.commagpie-inc.com › wp-content › uploads ›...

ESRI 380 New York St., Redlands, CA 92373-8100, USA • TEL 909-793-2853 • FAX 909-793-5953 • E-MAIL [email protected] • WEB www.esri.com

ArcGIS® Pipeline Data Model

Version 4.0 - Core

Abstract and Core Classes

An ESRI ® Technical Paper • May 2007

May 2007

Copyright © 2007 ESRI All rights reserved. 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.

May 2007

ArcGIS Pipeline Data Model

Version 4.0 Abstract and Core Classes

An ESRI Technical Paper Contents Page

ESRI Technical Paper i

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 10.2.5.3 CenterlineObject ..................................................................................... 35

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

May 2007 ii

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


ESRI Technical Paper iii

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 Class Names ........................................................................................147


May 2007 iv

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 ConvertAPDM3to4 ...................................................................................182

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

ESRI Technical Paper 1

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.


May 2007 2

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



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.


May 2007 4

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.

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


May 2007 6

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.



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 increasingly encroached on by suburbia. This trend can dramatically increase One Call


May 2007 8

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



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.


May 2007 10

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-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-driven data management



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


May 2007 12

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.



• 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 committee meetings are open to anyone interested in furthering the model. However, only


May 2007 14

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



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.


May 2007 16

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 positioning values can be determined (provided an underlying centerline of station series



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.


May 2007 18

• 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.

9.1.2 Arbitrary (Pseudo-distance Based)



• 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


May 2007 20

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



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


May 2007 22

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.



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. 10.2 APDM Abstract Classes


May 2007 24

APDM abstract classes are used to coarsely define the semantic behavior of the various feature and object classes in the APDM. APDM abstract classes are defined by their ‘core’ data attribution, and by the types of relationships that are implemented between the various APDM abstract class types. The abstract class type of any APDM object or feature class is determined by the presence of required ‘core’ data attributes and relationship classes. 10.2.1 What is an abstract class? APDM abstract classes act as templates. The formal definition of a template is a pattern usually consisting of a thin plate of some material serving as a guide in mechanical work for the creation of many objects with similar shapes. In the APDM, a template is a pattern that defines an object or class containing known and predictable behavior. The pattern (in the context of the APDM) is defined as a set of attributes, including geometry, and relationships to other classes. APDM abstract classes do not become actual feature classes or object classes in the geodatabase. APDM abstract classes perform like a carpenter’s template which is used to outline many versions of the same shape. In APDM, the template is used to create many versions of the same class. In the carpentry example, each cut shape inherits the properties of the template, but retains its own individual material characteristics and can be modified to create a variation based on the original template. In a similar manner, a concrete class in the APDM geodatabase inherits certain base attributes and relationships from an APDM abstract class. The addition of specific attributes and or relationships result in the creation of an individual, concrete feature or object class within the geodatabase. 10.2.2 Why are abstract classes used? Abstract classes serve three purposes within the APDM. First, abstract classes define specific behavior for a set of objects within an APDM model. Of particular importance is the behavior of how a feature responds to an edit or modification of the pipeline centerline. The second purpose is for efficiency in documentation. It is simpler to describe the content and behavior of an abstract class in a single location and use inheritance to propagate behavior to concrete class definitions. The third purpose for including abstract classes is reuse. Reuse, in this context, binds the previous two reasons together. The description and documentation of standard behavior can be applied to many different concrete classes within an APDM geodatabase. The definition and documentation of behavior thus defines the rules by which abstract classes, and those classes that inherit from them, must behave. Because the APDM model is a collection of features, objects and their relationships, defining the behavior of abstract classes dictates the rules that govern the model. Relationship classes defined for abstract classes ultimately determine how concrete APDM feature and object classes interact. Class- and feature-level metadata attributes defined for abstract classes govern how entire concrete APDM feature classes, and/or individual feature or objects behave when certain edit events occur. The rules defined for



the APDM abstract classes govern for their concrete class inheritors the outcomes of the following types of feature and object events:

• Addition of a feature or object to a concrete class. • Deletion of a feature or object from a concrete class. • Update of any of the core or audit attributes of a feature or object (e.g. EventID,

GroupEventID, stationing, or operational status attribute values). • Update of the geometry of a feature. • Update of the centerline on which a feature resides (e.g. a control point is moved,

or its station value is altered, or a reroute is performed at the LineLoop level). • An activity and/or an external document is associated with a feature or object (i.e.

an audit record is associated with the feature or object). All feature and object classes contained within the APDM inherit attributes and behavior from one or more of the APDM abstract classes. The APDM is designed around these abstract classes. Abstract classes provide a framework for data editors and developers to capture abstract class behavior in workflows and software applications. The rules for abstract class behavior are formally defined in this section. To date, however, the enforcement of abstract class behavior is up to the end user and/or the third party application developer. Simply employing abstract classes to build an APDM geodatabase does not prevent an end user from manipulating the contents of a single row or column of data in contradiction to the abstract class rules. The APDM Technical Committee expended considerable effort in defining the APDM abstract classes for version 4.0. The APDM 4.0 abstract classes are somewhat more numerous and much more rigorously defined than the abstract classes found in earlier versions of the model. Aside from their primary purpose in defining model behavior, the carefully tailored abstract classes of the APDM 4.0 make it much simpler and safer for an implementer to extend or modify the model. An implementer can simply define a new custom class, have it inherit from the desired abstract class, and know that the custom class will behave properly within the context of the APDM. Achieving and maintaining APDM compliance is almost automatic when the APDM abstract classes are properly utilized. 10.2.3 Duplication of Attributes within APDM abstract classes The reader will note there is some duplication of attributes within the APDM abstract classes. The reason for this is that while multiple inheritance is implicit in the APDM abstract class structure, multiple inheritance is not supported within the ESRI object model. This means each object class or feature class that is implemented within the


May 2007 26

APDM can inherit from one and only one parent object. Attribution that would otherwise be propagated via multiple inheritance must therefore be propagated explicitly, giving rise to the observed attribute duplication. Within the APDM Visio UML diagram (the physical model), the APDM abstract classes are implemented on a separate Static Structure Diagram. The diagram is laid out as a cascading leaf diagram showing the lower level classes explicitly inheriting from the ancestry above them. As is standard with UML, attributes defined by a parent object are not explicitly shown in a child object. This is done to minimize the amount of work to update the model when attribute changes are made. Therefore, when reading the APDM Visio Physical model, one must be sure to look at all ancestors of an object to get a full list of the attributes defined on a single object. Concrete feature and object classes defined on the other static structure diagrams within the model are generalized using a single generalization connector to the appropriate abstract class. This approach makes all concrete class definitions extremely concise. Duplication of attributes is largely eliminated since core (common) attributes are defined within the abstract classes from which the concrete classes inherit. 10.2.4 Inheritance (How to read the APDM Logical Model Poster) The APDM Logical Model represents an object diagram of the APDM. The object diagram is used to depict the following: classes, attributes of classes, relationships between classes, and inheritance from classes. A class is defined as either an Abstract or Concrete class. An attribute is a property that helps define the class. In this context, a property is analogous to a database table attribute and is defined by name and data type properties including primary key, foreign key or domain. Relationships between classes are directly analogous to database relationships between entities in that they are described by optionality and cardinality (e.g. must-have, may-have and one-to-many, zero-to-one, many-to-many). Lastly, inheritance is defined as something, such as a quality or characteristic received from predecessors (i.e. parents) as if by succession. Inheritance allows attributes and relationships to pass from parent classes to child classes. This is analogous to the manner in which mannerisms, instincts and characteristics are passed from parents to their offspring in the natural world. As inheritance of attributes and relationships is passed down from parent to child, attributes and relationships accumulate as the process proceeds down the inheritance tree. At the lowest point in the inheritance tree, a child has inherited all the attributes and relationships from all of its ancestors. Inheritance is used in APDM to define class behavior at the top levels and more complex behavior at the lower levels of the inheritance tree. The APDM abstract classes in effect describe the core attributes within the APDM. Inheritance is denoted in the logical model poster by a white filled triangle and a solid line from a parent class to a child class. The triangle is placed under the parent class and the solid black line links the child classes to the parent. The diagram below showing inheritance reads in a similar fashion to the poster where many children are



grouped under a single parent and then more children are grouped under a child of the original parent, thus making the child a parent of other inheriting classes.


May 2007 28

The above diagram shows the inheritance tree of the APDM abstract classes. ESRI Simple Objects are the highest-level objects from which all classes located within a geodatabase inherit. Each APDM abstract class is defined as a child of one or more ESRI Simple Objects and potentially as a child of another APDM abstract class. Relationships between the APDM abstract classes and other APDM classes are defined using ‘wormholes’ (the pink balloons). The connectors show the cardinality of the relationships between the classes. Cardinality indicates the number of instances (one or many) of an entity in one class in relation to another entity in another class. Cardinality is illustrated by the ends of the connector lines; A single line indicates a single or ‘one’ entity and a ‘Crows Foot – Three part’ line indicates multiple or ‘many’ entities. The most important part of this diagram is the depiction of APDM core classes represented by the grey call-out boxes. Core APDM classes must be implemented in the APDM geodatabase to maintain APDM compliance. In some cases the core APDM classes are the only class within a model inheriting from a particular APDM abstract class. For example, StationSeries inherits from CenterlinePolyline and ControlPoint inherits from CenterlinePoint. It is important to recognize that relationships occur from abstract classes to the core classes. These relationships define key APDM behavior and must be maintained. Child concrete classes inheriting from an APDM abstract class that has a relationship with a core APDM class inherit and implement the same types of relationships.



The diagram above illustrates APDM abstract class inheritance from the top of the tree down to the example concrete class, Elbow.


May 2007 30

The APDM abstract classes represent the expected behavior of object and feature classes in the APDM. Behavior can be expressed as a function of three elements – the attributes of a class, the relationships of a class, and the inheritance of a class. The next section presents each APDM Abstract Class by describing the geometry, inheritance, attributes, and relationships for the class. In describing these properties for each class, the expected behavior for that class is defined. APDM Compliance is defined as follows:

• Every class in the APDM must inherit directly from an APDM Abstract Class • Inherited attributes and relationships must use the standard APDM names,

optionality and cardinality without deviation. • The core APDM classes must be implemented according to the inheritance tree

and they must use the names assigned to them. APDM Metadata classes and attributes are described in the 10.3 APDM Metadata section of the whitepaper. 10.2.5 Abstract Class Definitions The APDM abstract classes are described below, and illustrated in the following diagram (Note that instructions for reading the inheritance and logical model diagrams is outlined in Appendix A):


May 2007 32



10.2.5.1 APDMObject

Class Name: APDMObject Feature Class

Geometry:Not Applicable.

APDM Inheritance:

ESRI Simple Object (Ancestor) ObjectArchive (Child - Abstract) ActivityHierarchy (Child - Core) InstrumentParameter (Child - Example) LineLoopHierarchy (Child - Core) SubSystemHierarchy (Child - Core)

Attributes:(name, type, length, precision, scale,

domain, description)

EventID (GUID, String, 38) – A globally unique identifier for the class.

Relationships:(cardinality, optionality, attributes,

composite)

None

SubTypes: -- APDMObject is the highest-level ancestor APDM abstract class for object classes within the APDM. Its purpose is to propagate the EventID attribute. The EventID attribute is used as a globally unique identifier containing a GUID value (String, 38). All feature classes and object classes within the APDM must have an attribute named EventID. The EventID provides a mechanism for uniquely identifying each feature or object in the geodatabase and is independent of the feature or object class to which it belongs. Using GUIDS for unique identifiers ensures that all features maintain a unique key even if they are exported from and then imported back into a geodatabase. The ObjectID or OID attribute is provided to all registered classes within a geodatabase by ESRI. The OID is of long integer type and can change when features are exported from and then imported back into a class. Note that the term "event" in EventID does not denote that this attribute pertains to event tables or events only. “EventID” was chosen to represent a global ID for any event that occurred on or along a pipeline system, be it an online or offline feature. In a future version of APDM the term “EventID” may be replaced by a more descriptive term such as "FeatureID" or "GeoEntityID". LineLoopHierarchy, ActivityHierarchy and SubSystemHierarchy are all APDM Core and concrete classes that directly inherit from APDMObject. The three hierarchy classes comprise the APDM Core Classes. These classes do not require attributes beyond EventID because their existence and behavior is completely described by that of their parent classes (LineLoop, Activity and SubSystem, respectively). 10.2.5.2 ObjectArchive


May 2007 34

Class Name: ObjectArchive Feature Class


APDM Inheritance:

ESRI Simple Object APDMObject (Ancestors - Abstract) CenterlineObject (Child - Abstract) FacilityObject (Child - Abstract) NonFacilityObject (Child - Abstract)



OriginEventID (GUID, String, 38) – The original GUID for a feature. OriginEventID is set to be equal to EventID when a feature is first created. OriginEventID does not change with successive records representing different historical states of a feature. For example, consider the EventID attribute of an online polyline once it has been split into two new features. When the parent is split all child segments of the parent feature inherit the original OriginEventID of the parent (each child segment does receive a unique EventID).

CreatedBy (String, 45) – User ID of the operator who created the feature. A value is applied once to this attribute when the object is first created. CreatedBy does not change with successive updates or versions of this record representing different historical states of the object.

CreatedDate (Date) – The timestamp when the initial record for the object was created in the database. Because the CreatedDate is a database date, it does not necessarily correspond to the actual effective date of the feature or object in the real world. CreatedDate may be either earlier or later than EffectiveFromDate. In a similar manner as CreatedDate, CreatedBy does not change with successive updates or versions of this record representing different historical states of the object.

EffectiveFromDate (Date) – The date a particular record in the database went into effect in the real world. This date should not be confused with the CreatedDate. The EffectiveFromDate for the initial record for a feature should correspond to either the InServiceDate or the InstallationDate for the feature. The EffectiveFromDate is modified with each successive record documenting the historical state of a feature.

EffectiveToDate (Date) – The date at which a particular record in the database is no longer in effect. EffectiveToDate is modified with each successive record documenting the historical state of a feature. EffectiveToDate is null for a database record that is currently in effect,

LastModified (Date) – The timestamp for the last modification of the record in the database. LastModified is equal to the CreatedDate for the initial record of an object. The LastModified



timestamp is modified with each successive record documenting the historical state of a feature.

ModifiedBy (String, 45) – The User-ID of the operator who last modified the feature. ModifiedBy = CreatedBy for the initial record of a feature,. ModifiedBy changes with each successive record representing different historical states of a feature.

HistoricalState (Long Integer, 9) gnHistoricalState (required APDM domain) – Indicates whether the record represents the current state, or an historical state, of the referenced object or feature. HistoricalState is included in the model for those utilizing ‘inline’ history. In such implementations, multiple historical versions of a single feature or object may be stored; the HistoricalState attribute provide a simple means of distinguishing current vs. historical records.

ProcessFlag (String, 10) - A catch-all field for application developers used for temporarily storing values, tags, and codes required for application processing. The field is not meant to store information on a permanent basis and should be cleared after each procedure or operation that is performed using this field.

Remarks (String, 255) – Open field used for comments, remarks, or notes about the object.


composite)

None

SubTypes: -- The ObjectArchive object class contains object class level archival information including the user that created the object and the user or application that last modified the object or its attributes. The ObjectArchive also includes effective to and from dates and the standard APDM fields ProcessFlag and Remarks. All objects belonging to object classes below ObjectArchive in the inheritance tree require this information for operational and historical tracking purposes. The gnHistoricalState domain contains the following values: -1=Unknown (Verified), 0=Unknown, 1=Current, 2=Historical. 10.2.5.3 CenterlineObject

Class Name: CenterlineObject Feature Class


APDM Inheritance:

ESRI Simple Object APDMObject ObjectArchive (Ancestor - Abstract) AltRefMeasure (Child - Core) LineLoop (Child - Core) SubSystem (Child - Core)


May 2007 36



GroupEventID (GUID, String, 38) – For LineLoop and SubSystem, GroupEventID is used to aggregate or group all the children of a root-level LineLoop or SubSystem. The EventID of the root-level LineLoop or Subsystem is applied as the GroupEventID of all child (branch) LineLoop or SubSystem objects to facilitate query and reporting. The AltRefMeasure object class makes use of the GroupEventID attribute to group split online polyline features together.

OperationalStatus (Long Integer, 9) gnOperationalStatus (required APDM domain) – Domain value indicating the status of a feature that has some operational lifespan based on FERC/OPS definitions. Applied to centerline features or facility features with complex operational life spans. The gnOperationalStatus domain is considered a core APDM domain that inherits values from the gnStatus domain and must be implemented exactly as prescribed by the APDM.


composite)

None

SubTypes: -- The CenterlineObject APDM Abstract Class provides access to the Group and OriginEventID. These values are typically reserved for online polyline features that span station series equations and are often broken at series breaks. These attributes may be used to group hierarchy objects such as LineLoops and SubSystems together. As a best practice, the use of the OperationalStatus attribute as it pertains to LineLoop and SubSystem should affect all related child features. When changing the OperationalStatus value of these objects, such changes should be cascaded to all related StationSeries features and child features through the relationship tree (e.g. online features, offline features with online locations etc.). The OperationalStatus domain contains the following values: -1=Unknown (Verified), 0=Unknown, 1=Conceptual, 2=Proposed, 4=Active, 8=Inactive, 16=Idle, 32=Abandoned and 64=Removed. 10.2.5.4 NonFacilityObject

Class Name: NonFacilityObject Feature Class


APDM Inheritance:

ESRI Simple Object APDMObject ObjectArchive (Ancestors - Abstract) Activity (Child – Core) Address (Child – Example) CISReading (Child – Example) <classname>Audit (Child – Core) Company (Child – Core)



Contact (Child – Example) ExternalDocument (Child – Core) GeoMetaData (Child – Example) MeterReading (Child – Example) OwnerOperator (Child – Core) Product (Child – Core) StructureOrIDSite (Child – Example)



Status (Long Integer, 9) gnStatus (required APDM domain) – Defines the status of an object within the APDM. Status is used to describe the state of a non-facility object. These objects either have no operational significance or do not exist as a geographical or physical entity. The gnStatus domain is considered a core APDM domain and must be implemented using the specified values exactly as prescribed by the APDM.


composite)

None

SubTypes: -- The NonFacilityObject APDM Abstract Class provides a universal status field for non-operational and non-facility object classes. Status is provided to indicate rudimentary status values rather than a full set of operational status values. The values for the gnStatus domain applied to this field are: -1=Unknown (Verified), 0=Unknown, 1=Conceptual, 2=Proposed, 4=Active, and 8=Inactive. 10.2.5.5 FacilityObject

Class Name: FacilityObject Feature Class


APDM Inheritance:

ESRI Simple Object APDMObject ObjectArchive (Ancestors - Abstract) ValveOperator (Child – Example)



InServiceDate (Date) - Represents the date a piece of equipment is

actually put in service and is used primarily for accounting purposes. Note that the InServiceDate date may be later than the installation date.

InstallationDate (Date) - The date a piece of equipment is installed. InstallationDate is important for risk analysis.

OperationalStatus (Long Integer, 9) gnOperationalStatus (required APDM domain) – A domain value indicating the status of a feature that has some operational lifespan based on FERC/OPS definitions. Applied to centerline features or facility features with complex operational life spans. The gnOperationalStatus domain


May 2007 38

is considered a core APDM domain that inherits values from the gnStatus domain and must be implemented exactly as prescribed by the APDM.

SiteEventID (GUID, String, 38, FK) – Indicates the site (compressor station, meter station, custody transfer station, storage yard etc.) the facility belongs to or is contained within. By utilizing this attribute online features or FacilityObjects can be placed or located without the need for geometry. This concept is outlined in the section ‘Non Geometric Features’.


composite)

Site<FacilityObject class name> (core): Each FacilityObject class is M:1 with Site.

SubTypes: -- The FacilityObject APDM abstract class provides in-service, installation and operational status attributes for objects representing facilities. Compressors, compressor engines, and valve operators are facilities that are typically modeled as non-geometric objects. The SiteEventID field can be used to relate the object (e.g. a compressor station) to a particular site. The OperationalStatus domain contains the following values: -1=Unknown (Verified), 0=Unknown, 1=Conceptual, 2=Proposed, 4=Active, 8=Inactive, 16=Idle, 32=Abandoned and 64=Removed. 10.2.5.6 FeatureArchive

Class Name: FeatureArchive Feature Class


APDM Inheritance:

ESRI Simple Object ESRI Simple Feature (Optional) CenterlinePolyline (Child - Abstract) CenterlinePoint (Child - Abstract) OfflineFeature (Child - Abstract) OfflineFacility (Child - Abstract) OnlineFeature (Child - Abstract)



CreatedBy (String, 45) – User ID of the operator who created the feature. A value is applied once to this attribute when the feature is first created. CreatedBy does not change with successive updates or versions of this record representing different historical states of the object.

CreatedDate (Date) – The timestamp that the initial record for the object was created in the database. Because the CreatedDate is a database date, it does not necessarily correspond to the actual effective date of the feature or of the object in the real world. CreatedDate may be either earlier or later than EffectiveFromDate. In a similar manner as CreatedDate, CreatedBy does not change with successive updates or versions



of this record that represent different historical states of the object.

EffectiveFromDate (Date) – The date a particular record in the database went into effect in the real world. This date should not be confused with the CreatedDate. The EffectiveFromDate for the initial record for a feature should correspond to either the InServiceDate or the InstallationDate for the feature. The EffectiveFromDate is modified with each successive record that documents the historical state of a feature.

EffectiveToDate (Date) – The date at which a particular record in the database is no longer in effect. EffectiveToDate is modified with each successive record documenting the historical state of a feature. For a database record that is currently in effect, EffectiveToDate is null.

EventID (GUID, String, 38) – A globally unique identifier for the class.

OriginEventID (GUID, String, 38) – The original GUID for a feature. OriginEventID is set to be equal to EventID when a feature is first created. OriginEventID does not change with successive records representing different historical states of a feature. For example, consider the EventID attribute of an online polyline once it has been split into two new features. When the parent is split all child segments of the parent feature inherit the original OriginEventID of the parent (each child segment does receive a unique EventID).

LastModified (Date) – The timestamp for the last modification of the record in the database. LastModified is equal to the CreatedDate for the initial record of an object. The LastModified timestamp is modified with each successive record documenting the historical state of a feature.

ModifiedBy (String, 45) – The User-ID of the operator who last modified the feature. For the initial record for a feature, ModifiedBy = CreatedBy. ModifiedBy changes with each successive record that represents a different historical state of a feature.

HistoricalState (Long Integer, 9) gnHistoricalState (required APDM domain) – Indicates whether the record represents the current state, or an historical state, of the referenced object or feature. HistoricalState is included in the model for those utilizing ‘inline’ history. In such implementations, multiple historical versions of a single feature or object may be stored; the HistoricalState attribute provide a simple means of distinguishing current vs. historical records.

ProcessFlag (String, 10) - A catch-all field for application


May 2007 40

developers used for temporarily storing values, tags, and codes required for application processing. The field is not meant to store information on a permanent basis and should be cleared after each procedure or operation that is performed using this field.

Remarks (String, 255) – Open field used for comments, remarks, or notes about the object.


composite)

None

SubTypes: -- FeatureArchive is the highest-level ancestor APDM abstract class for feature classes within the APDM. One purpose for this abstract class is to propagate the EventID attribute. The EventID attribute is used as a globally unique identifier containing a GUID value (String, 38). All feature classes and object classes within the APDM must have an attribute named EventID. The second purpose of the FeatureArchive APDM Abstract Class is to store feature class level archiving information including who created the feature and who last modified the feature or its attributes. This class includes operational dates such as effective to and from dates and the APDM core fields ProcessFlag and Remarks. All features belonging to feature classes below this class in the inheritance tree require this information for operational and historical tracking purposes. In the above definition, FeatureArchive optionally implements ESRI Simple Feature. The reason for this is to accommodate those who wish to implement the APDM using events rather than features. However, both the logical model diagram and the physical model UML diagram depict FeatureArchive as implementing ESRI Simple Feature; this is the recommended best practice. 10.2.5.7 CenterlinePolyline

Class Name: CenterlinePolyline Feature Class

Geometry:M Aware polyline feature class.

APDM Inheritance:

ESRI Simple Object ESRI Simple Feature (Optional) FeatureArchive (Ancestors - Abstract) CenterlinePolylineEvent (Child - Abstract) StationSeries (Child - Core)



OperationalStatus (Long Integer, 9) gnOperationalStatus (required APDM domain) – A domain value indicating the status of a feature that has some operational lifespan based on FERC/OPS definitions. It is applied to centerline features or facility features with complex operational lifespans. The gnOperationalStatus domain is considered a core APDM domain that inherits values from the gnStatus domain and must be implemented exactly as



prescribed by the APDM. Relationships:

(cardinality, optionality, attributes, composite)

None

SubTypes: Reference Modes – each CenterlinePolyline feature must have subtypes equal to those in the CenterlinePoint, i.e. ControlPoint, feature class. Each subtype value represents a single reference mode.

The CenterlinePolyline APDM abstract class adds OperationalStatus to the FeatureArchive attributes for use by the one core class inheriting from it: StationSeries. As a best practice, the use of the OperationalStatus attribute as it pertains to StationSeries should affect all related child features. When changing the OperationalStatus value of station series features, such changes should be cascaded to all child features through the relationship tree (e.g. online features, offline features with online locations etc.). The OperationalStatus domain contains the following values: -1=Unknown (Verified), 0=Unknown, 1=Conceptual, 2=Proposed, 4=Active, 8=Inactive, 16=Idle, 32=Abandoned and 64=Removed. The APDM Core section of this paper explains the structure and purpose of the StationSeries feature class and how it interacts with other classes within the model. 10.2.5.8 CenterlinePolylineEvent

Class Name: CenterlinePolylineEvent Feature Class

Geometry:May be implemented as an M Aware polyline feature class or as an object class used to build ESRI event themes.

APDM Inheritance:

ESRI Simple Object ESRI Simple Feature (Optional) FeatureArchive CenterlinePolyline (Ancestors - Abstract) SubSystemRange (Child - Core)



StationSeriesEventID (GUID, String, 38, FK) – Foreign key to the primary reference mode (PRM) station series feature that addresses the location of the online feature.

BeginStation (Double, 15, 2) - A station value (measure) along a station series used to position and locate the start of the linear feature.

EndStation (Double, 15, 2) – A station value (measure) along a station series used to position and locate the end of the linear feature.

CLEditResponse (Long Integer, 9) clEditResponse (required APDM Domain) – Indicates how the geometry and/or stationing attributes of an online feature respond to a centerline edit such as a reroute. This attribute is further described in the section ‘Feature Level Metadata’.

CLValidityTolerance (Double 15,2) – Indicates how far the centerline can move away from an online event feature before


May 2007 42

the event becomes ‘invalid’. Expressed the distance units of the Transmission feature dataset. This attribute is further described in the section ‘Feature Level Metadata’.

GroupEventID (GUID, String, 38) – Used to aggregate or generalize two or more centerline features together as a single unit for the purposes of querying, reporting and calculating distances or lengths. Primarily used for features that are broken apart on interrupted style primary reference modes.


composite)

StationSeries<CenterlinePolylineEvent name> (core): CenterlinePolylineEvent is M:1 with StationSeries.

SubTypes: -- The CenterlinePolylineEvent APDM abstract class adds online polyline event attributes (StationSeriesEventID, BeginStation, EndStation and GroupEventID) and centerline edit metadata attributes (CLValidityEditResponse and CLValidityTolerance) to CenterlinePolyline for the one event class that inherits from it: SubSystemRange. The CenterlinePolylineEvent abstract class is distinguished from the OnlinePolylineFacility abstract class by the absence of the InstallationDate and InServiceDate attributes. GroupEventID and the inherited OriginEventID attributes have relevance for SubSystemRange features as they may span station equations in interrupted style reference modes. The APDM Core section of this paper explains the structure and purpose of the SubSystemRange feature class and how it interacts with other classes within the model. 10.2.5.9 CenterlinePoint

Class Name: CenterlinePoint Feature Class

Geometry:Implemented as an M Aware point feature class.

APDM Inheritance:

ESRI Simple Object ESRI Simple Feature (Optional) FeatureArchive (Ancestors - Abstract) ControlPoint – (Child - Core)


domained, notes)

CLControl (Long Integer, 9) gnYesNo (required APDM domain) – A Yes/No describing whether the control point participates in the construction of the centerline StationSeries feature. Some control points may represent offline points of inflection rather than a vertex of the station series.

CLStationEditResponse (Long Integer, 9) clStationEditResponse (required APDM domain) - Describes how the station values for the control point may be altered. This attribute is further described in the section ‘Feature Level Metadata’.

CLXYEditResponse (Long Integer, 9) clXYEditResponse (required APDM domain) - Indicates how the x,y portion of the geometry of a control point feature responds to a centerline edit such as a



reroute. This attribute is further described in the section ‘Feature Level Metadata’.

CLZEditResponse (Long Integer, 9) clZEditResponse (required APDM domain) - Indicates how the Z portion of the geometry of a control point feature responds to a centerline edit such as a reroute. This attribute is further described in the section ‘Feature Level Metadata’.

GroupEventID (GUID, String, 38) – For ControlPoint, GroupEventID used to aggregate or group control points found at a single physical location for the purposes of querying, reporting and calculations. The EventID of the PRM control point is used as the GroupEventID for all control points at that location.

OperationalStatus (Long Integer, 9) gnOperationalStatus (required APDM domain) – Status of the feature (e.g. active, abandoned, proposed).

StationSeriesEventID (GUID, String, 38, FK) - The foreign key of the Station Series feature to which the control point belongs.

SymbolRotation (Double, 15, 2), gnAngle (required APDM domain) - A rotation angle from 0–360o for a point symbol (uses gnAngle domain). This allows operators to preserve rotation information for point symbols imported from external systems such as Computer Aided Drafting (CAD) applications. Allows all point symbols within the APDM to be rotated as needed; manually, or in relation to other features. This is used primarily for display in mapping applications such as alignment sheets.

Relationships:(cardinality, optionality, composite,

inheritance)

StationSeries<CenterlinePoint class name> (core): <CenterlinePoint class name> is M:1 with StationSeries.

SubTypes: Reference Modes – each CenterlinePoint feature must have subtypes equal to those in the CenterlinePolyline (StationSeries) feature class. Each subtype value represents a single reference mode.

The CenterlinePoint APDM abstract class encapsulates and describes the behavior of points that participate in the construction of the centerline. Currently, only the ControlPoint class serves this purpose in the APDM. The attributes of this class describe the behavior and relationships of control points within the centerline and to the StationSeries feature class. Each control point can have an operational status reflecting the status of the parent station series. Control points can be placed in proposed or conceptual states indicating route planning or new pipeline construction activities. More information regarding the role of control points in the APDM is described in the ‘APDM Core’ section. 10.2.5.10 OfflineFeature


May 2007 44

Class Name: OfflineFeature Feature Class

Geometry:Implemented as an Non-M-Aware Polyline or Non-M-Aware Polygon feature class

APDM Inheritance:

ESRI Simple Object ESRI Simple Feature (Optional) FeatureArchive (Ancestors - Abstract) AlignmentSheet – (Child - Example) HighConsequenceArea – (Child - Example) LineCrossing – (Child - Example) RemovedLine – (Child - Example) StructureOutline – (Child - Example) IDSiteArea – (Child - Example)


domained, notes)

Status (Long Integer, 9) gnStatus (required APDM domain) – Defines the status of an object within the APDM. Status is used to describe the state of a non-facility or centerline object (i.e. an object that has no operational significance or does not exist as a geographical or physical entity). The gnStatus domain is considered a core APDM domain and must be implemented using the specified values exactly as prescribed by the APDM.


inheritance)

Each and every Offline Feature may have zero or more online locations stored in a class inheriting from the OnlinePoint or the OnlinePolylinesForOfflineClass APDM Abstract Classes.

SubTypes: -- The OfflineFeature APDM abstract class stores polyline and polygon features that are primarily located by x,y coordinate position and have no impact on the location of the centerline or the stationing values contained therein. Offline features comprise any feature that is ancillary to the operations and description of the pipeline system and the underlying geography. Most land base or supporting features possessing polyline or polygon geometry are stored in feature classes inheriting directly from this abstract class. OfflineFeatures such as Alignment Sheets and Line Crossings may be related to features in classes inheriting from OnlinePolylineForOfflineFeature or OnlinePointForOfflineFeature. Features in these classes are located on the centerline and represent the online location or stationed position of an OfflineFeature. These relationships are captured in the geodatabase as relationship classes and as rows in the OnlineLocationClass APDM Metadata table. 10.2.5.11 OfflinePoint

Class Name: OfflinePoint Feature Class

Geometry:Implemented as an Non-M-Aware Point feature class

APDM Inheritance:

ESRI Simple Object ESRI Simple Feature (Optional) FeatureArchive OfflineFeature (Ancestors - Abstract) DocumentPoint – (Child - Example)



FieldNote – (Child - Example) RemovedPoint – (Child - Example) SitePoint – (Child - Example) NearestPointToLine – (Child - Example)


domained, notes)

SymbolRotation (Double, 15, 2), gnAngle (required APDM domain) - A rotation angle from 0–360o for a point symbol (uses gnAngle domain). This allows operators to preserve rotation information for point symbols imported from external systems such as CADD. Allows all point symbols within the APDM to be rotated as needed; manually, or in relation to other features. This is used primarily for display in mapping applications such as alignment sheets.


inheritance)

None

SubTypes: -- The OfflinePoint APDM abstract class stores point features that are primarily located by x,y coordinate position and have no impact on the location of the centerline or the stationing values contained therein. Most land base or supporting point features are stored in feature classes inheriting directly from this abstract class. OfflinePoints such as Field Notes and Structures may be related to features in classes inheriting from OnlinePolylineForOfflineFeature or OnlinePointForOfflineFeature. Features in these classes are located on the centerline and represent the online location or stationed position of an OfflinePoint feature. These relationships are captured in the geodatabase as relationship classes and as rows in the OnlineLocationClass APDM Metadata table. The SymbolRotation property is added to allow for cartographic control over the representation of OfflinePoint features. 10.2.5.12 OfflineFacility

Class Name: OfflineFacility Feature Class

Geometry:Implemented as an Non-M Aware Polygon feature class

APDM Inheritance:

ESRI Simple Object ESRI Simple Feature (Optional) FeatureArchive (Ancestors - Abstract) Site – (Child - Core)


domained, notes)

InServiceDate (Date) - Represents the date a piece of equipment is actually put in service and is used primarily for accounting purposes. The InServiceDate date may be later than the installation date.

InstallationDate (Date) - The date a piece of equipment is installed. Note that InstallationDate is important for risk analysis.

OperationalStatus (Long Integer, 9) gnOperationalStatus (required APDM domain) – A domain value indicating the status of a


May 2007 46

feature that has some operational lifespan based on FERC/OPS definitions. Applied to centerline features or facility features with complex operational life spans. The gnOperationalStatus domain is considered a core APDM domain that inherits values from the gnStatus domain and must be implemented exactly as prescribed by the APDM.


inheritance)

Each and every OfflineFacility may have zero or more online locations stored in a class inheriting from OnlinePoint or OnlinePolylinesForOfflineClass APDM Abstract Classes.

SubTypes: -- The OfflineFacility APDM abstract class provides the facility logic for all offline facilities features by adding the InServiceDate, InstallationDate and OperationalStatus attributes. Similar to OfflineFeatures, OfflineFacilities are used for storing features that are primarily located by x,y coordinate position and have no impact on the location of the centerline or the stationing values contained therein. OfflineFacility features may be related to features in classes inheriting from OnlinePolylineForOfflineFeature or OnlinePointForOfflineFeature but this is unlikely. The only class that inherits directly from OfflineFacility is Site. Sites represent the boundaries of stations, storage areas, or large buildings that possibly contain other features, and facilities. Sites are put into service and have installation dates representing the time that they were built. 10.2.5.13 OfflineNonPointFacility

Class Name: OfflineNonPointFacility Feature Class

Geometry:Implemented as a Non-M Aware Polygon or Non-M Aware polyline feature class

APDM Inheritance:

ESRI Simple Object ESRI Simple Feature (Optional) FeatureArchive OfflineFacility (Ancestors - Abstract) CPCable – (Child - Example) PIGStructure – (Child – Example)


domained, notes)

SiteEventID (GUID, String, 38, FK) – Indicates the site (e.g. compressor station, meter station, custody transfer station, storage yard, etc.) the facility belongs to or is contained within. By utilizing this attribute online or offline facilities features can be placed or located without the need for geometry. This concept is outlined in the section ‘Non Geometric Features’.


inheritance)

Site<OffilneNonPointFacility class name> (core): <OfflineNonPointFacility class name> is M:1 with Site.

SubTypes: -- The OfflineFacility APDM abstract class further divides the behavior of offline facility classes into NonPoint and Point. OfflineNonPointFacility is intended for use with offline facilities features that are best represented by polyline or polygon shapes (e.g.



PigStructure). The OfflineNonPointFacility abstract class inherits the in-service date, installation date and operational status attributes of the OfflineFacility APDM Abstract class and thus is treated as a facility. The OfflineNonPointFacility class enables a relationship to the Site class through the SiteEventID attribute. This relationship allows OfflineNonPointFacility features to be located within a Site. Once stored in a Site, the geometry for the features becomes optional. The Site becomes the container for these features and the relationship between the Site and the features provides the ability to generate a manifest of all features contained within the Site. 10.2.5.14 OfflinePointFacility

Class Name: OfflinePointFacility Feature Class

Geometry:Implemented as an Non-M Aware Point feature class

APDM Inheritance:

ESRI Simple Object ESRI Simple Feature (Optional) FeatureArchive OfflineFacility (Ancestors - Abstract) CPAnode – (Child - Example) CPBond – (Child – Example) CPGroundBed – (Child – Example) CPRectifier – (Child – Example) CPTestStation – (Child – Example) Marker – (Child – Example)


domained, notes)

SiteEventID (GUID, String, 38, FK) – Indicates the site (e.g. compressor station, meter station, custody transfer station, storage yard, etc.) the facility belongs to or is contained within. By utilizing this attribute online or offline facilities features can be placed or located without the need for geometry. This concept is outlined in the section ‘Non Geometric Features’.



inheritance)

Site<OfflinePointFacility class name> (core): <OfflinePointFacility class name> is M:1 with Site.

SubTypes: -- The OfflineFacility APDM abstract class further divides the behavior of offline facility classes into NonPoint and Point. Intended for use with offline facilities classes best represented with point shapes (e.g., CPTestStation), OfflinePointFacility add the SymbolRotation attribution to control the orientation of point features during display. The


May 2007 48

OfflinePointFacility abstract class inherits the in service date, installation date and operational status attributes of the OfflineFacility abstract class and thus is treated as a facility. Like OfflineNonPointFacility, the OfflinePointFacility class enables a relationship to the Site class through the SiteEventID attribute. This relationship allows OfflinePointFacility features to be located within a Site. Once stored in a Site, the geometry for the features becomes optional. The Site becomes the container for these features and the relationship between the Site and the features provides the ability to generate a manifest of all features contained within the Site. 10.2.5.15 OnlineFeature

Class Name: OnlineFeature Feature Class

Geometry:Implemented as an M-Aware Polyline feature or an M Aware Point feature class or an Object Class representing an event table.

APDM Inheritance:

ESRI Simple Object ESRI Simple Feature (Optional) FeatureArchive (Ancestors – Abstract)


domained, notes)

CLEditResponse (Long Integer, 9) clEditResponse (required APDM Domain) – Indicates how the geometry and/or stationing attributes of an online feature respond to a centerline edit such as a reroute. This attribute is further described in the section ‘Feature Level Metadata’.

CLValidityTolerance (Double 15,2) – Indicates how far the centerline can move away from an online event feature before the event becomes ‘invalid’. Expressed the distance units of the Transmission feature dataset. This attribute is further described in the section ‘Feature Level Metadata’.

StationSeriesEventID (GUID, String, 38, FK) – Foreign key to the primary reference mode (PRM) station series that addresses the location of the online feature.


inheritance)

StationSeries<OnlineFeature class name> (core): <OnlineFeature class name> is M:1 with StationSeries.

<OnlineFeature class name>AltRefMeasure (core): <OnlineFeature class name> is M:N with AltRefMeasure.

SubTypes: -- The OnlineFeature APDM abstract class defines the core behavior of online features. Online features represent a classification of features that are found as events on the centerline. Online features are primarily located on the centerline using a measure or station value. This position represents a certain distance from the begin point of a linear route feature (e.g. a primary reference mode station series feature). Online features can only be point or line features. Online features must be geometrically coincident and geometrically constrained to the centerline features (i.e. station series) of the pipeline. Features that are geometrically coincident are point or linear features that share the same edge as the station series features that comprise the centerline. Features that are



geometrically constrained are linear features that share not only the edge of the centerline but also every intervening vertex between the start and endpoint of the linear feature which is shared with the station series feature. All online features must have a StationSeriesEventID attribute that identifies a unique route feature (i.e. station series) on which the feature is located. The StationSeriesEventID attribute is a foreign key to the StationSeries feature class. The related parent station series feature must belong to the PRM (or default subtype) of the StationSeries feature class. The CLEditResponse and CLValidityTolerance attributes describe what happens to the online feature when the underlying station series feature is edited at the LineLoop level. These attributes define how and if the feature is re-built on the centerline during a reroute. The abstract classes that inherit from OnlineFeature describe the stationing attributes required for online point and polyline features. 10.2.5.16 OnlinePolyline

Class Name: OnlinePolyline Feature Class

Geometry:Implemented as an M-Aware Polyline feature or an Object Class representing an Event table.

APDM Inheritance:

ESRI Simple Object ESRI Simple Feature (Optional) FeatureArchive OnlineFeature (Ancestors – Abstract) DOTClass – (Child - Example) HCARange – (Child - Example) HCASegment – (Child - Example) CouldAffectSegment – (Child – Example) InspectionRange – (Child - Example) OperatingPressure – (Child - Example) PressureTest – (Child - Example) RightOfWay – (Child - Example) RiskAnalysis – (Child - Example)


domained, notes)

BeginStation (Double, 15, 2) - A station value (measure) along a station series used to position and locate the start of the linear feature.

EndStation (Double, 15, 2) – A station value (measure) along a station series used to position and locate the end of the linear feature.

GroupEventID (GUID, String, 38) – Used to aggregate or generalize two or more online polyline features together as a single unit for the purposes of querying, reporting and calculating distances or lengths. Primarily used for online polyline features that are broken apart on interrupted style primary reference modes.


May 2007 50



inheritance)

Each and every OnlinePolyline may have zero or more OnlinePolyline or OnlinePoint features (M-1)

SubTypes: -- The OnlinePolyline APDM abstract class encapsulates the stationing and status behavior of non-facility online polyline features. The term non-facility means representative phenomena opposed to actual phenomena. Representative phenomena are organizational or categorical features as defined by an operator. An InspectionRange is an arbitrarily assigned reach along the pipeline defined by a start and stop position. The feature itself does not exist in reality other than as a designation. Alternately, online facility objects do exist in reality and can be visually examined and manipulated in the real world. To this end, the Status of OnlinePolyline features is tracked as opposed to the OperationalStatus that is used for facility features. Online linear features are stored in an M Aware (optionally Z-Aware) polyline feature class or as an Event table containing events that are geometrically constrained and coincident with the centerline. Online linear features are located by linear referencing using a StationSeriesEventID that is inherited from OnlineFeature and two station value fields. OnlinePoint and OnlinePolyline features may be derived from other online point or polyline features. In this case, the OnlinePolyline represents an additional location or alternate geometric representation of the other online feature. Two good examples of this are the representation of a valve as both a point and polyline feature. Valves often have a length attribute which may be required for calculation of Maximum Allowable Operating Pressure (MAOP). In this example the Valve inherits from the OnlinePointFacility class but has a related set of features stored in a feature class that inherits from the OnlinePolyline abstract class. The attributes describing the valve are stored in the Valve point feature class but the visual and graphic representation of the length of the valve is stored in a separate ValveLength feature class. The ValveLength feature class inherits from OnlinePolyline and is related (M-1) to the Valve feature class. Similarly, a Leak feature inheriting from the OnlinePoint Abstract Class may be related to a LeakAreaOfEffect feature class that inherits from the OnlinePolyline abstract class. Relationships between online feature classes and offline feature classes representing alternate or additional locations for those classes are defined in the APDM Metadata table OnlineLocationClass. 10.2.5.17 OnlinePolylineForOfflineFeature



Class Name: OnlinePolylineForOfflineFeature Feature Class


APDM Inheritance:

ESRI Simple Object ESRI Simple Feature (Optional) FeatureArchive OnlineFeature OnlinePolyline (Ancestors – Abstract) LineCrossingEasement (Child – Example)


domained, notes)

BeginOffsetAngle (Double, 15, 2) - The angle of the vector from the end point of an online polyline on the centerline to an offline feature. The angle is measured from the upstream vector of the centerline. BeginOffsetAngle is only used if the online feature is acting as an online location for an offline point or offline linear feature.

BeginOffsetDistance (Double, 15, 2) - The distance of the end point of an online polyline to the offline feature. BeginOffsetDistance is only used if the polyline feature is acting as an online location for an offline point or linear feature.

EndOffsetAngle (Double, 15, 2) - The angle of the vector from the end point of an online polyline on the centerline to an offline feature. The angle is measured from the upstream vector of the centerline. EndOffsetAngle is only used if the online feature is acting as an online location for an offline point or offline linear feature.

EndOffsetDistance (Double, 15, 2) - The distance of the end point of an online polyline to the offline feature. EndOffsetDistance is only used if the polyline feature is acting as an online location for an offline point or linear feature.

<OfflineFeature>EventID (GUID, String, 38, FK) – Indicates the EventID value of the related offline feature class for which the OnlinePolyline is representing an online location. The <OfflineFeature> represents the name of the offline feature class.


inheritance)

Each and every OnlinePolylineForOfflineFeature must be the online location for one and only one offline feature (M-1).

SubTypes: -- The OnlinePolylineForOfflineFeature (OPFOF) APDM abstract class encapsulates the attributes and relationships that define the online polyline location for an offline feature. The OPFOF abstract class inherits from OnlinePolyline and therefore has the default begin and end station positions to store the start and stop positions of the online location along the centerline. Online linear features can act as online locations for both offline polyline and offline polygon features. For the former, the online polyline location feature might represent the easement to either side of where the offline linear feature intersects the centerline; for the latter, the online polyline location feature represents the overlap of the polygon on the centerline or the range of intersection of the centerline by the polygon.


May 2007 52

The OPFOF class contains begin and end offset angle and distance information as well. Often an online location can be generated from an offline feature that does not intersect the centerline, or is not located within a specific distance from the centerline and therefore requires an offset bearing and distance from the centerline to define the begin and end positions of the offline feature. 10.2.5.18 OnlinePoint

Class Name: OnlinePoint Feature Class

Geometry:Implemented as an M-Aware Point feature or an Object Class representing an Event table.

APDM Inheritance:

ESRI Simple Object ESRI Simple Feature (Optional) FeatureArchive OnlineFeature (Ancestors – Abstract) Anomaly – (Child - Example) AnomalyCluster – (Child - Example) ElevationPoint – (Child - Example) Leak – (Child - Example)


domained, notes)

Station (Double, 15, 2) – A station value (i.e. measure) along a station series used to position and locate the point feature.




inheritance)

Each and every OnlinePoint may be represented by zero or more OnlinePolyline or OnlinePoint alternative geometries (M-1)

SubTypes: -- The OnlinePoint APDM abstract class encapsulates the stationing and status behavior of non-facility online point features. The term ‘non-facility’ means representative phenomena opposed to actual phenomena. Representative phenomena are organizational or categorical features as defined by an operator. An ElevationPoint is an arbitrarily assigned point along the pipeline defined by a start position where an elevation measurement occurred. The feature itself does not exist in reality other than as a



designation. Alternately, online facility objects do exist in reality and can be visually examined and manipulated in the real world. To this end, the Status of OnlinePoint features is tracked as opposed to the OperationalStatus that is used for facility features. Online point features are stored in an M-Aware (optionally Z-Aware) point feature class that is geometrically coincident with the centerline. Online point features are located by linear referencing using a StationSeriesEventID (inherited from OnlineFeature) and a Station value. Online point features can be used to model concrete features that occur along the centerline or as online locations for offline point or offline polyline features. OnlinePoint features can represent the online location for other online location features. An example of this is given in the descriptive notes for the OnlinePolyline APDM Abstract Class. 10.2.5.19 OnlinePointForOfflineFeature

Class Name: OnlinePointForOfflineFeature Feature Class


APDM Inheritance:

ESRI Simple Object ESRI Simple Feature (Optional) FeatureArchive OnlineFeature OnlinePoint (Ancestors – Abstract) CPLocation (Child – Example) FieldNoteLocation (Child – Example) LineCrossingLocation (Child – Example) MarkerLocation (Child – Example) StructureLocation (Child – Example)


domained, notes)

<OfflineFeature>EventID (GUID, String, 38, FK) – Indicates the EventID value of the related Offline feature class for which the OnlinePoint is representing a online location. The <OfflineFeature> represents the name of the Offline feature class.

OffsetAngle (Double, 15, 2) – The angle of the vector from the online point location on the centerline to the offline feature. The angle is measured from the upstream vector of the centerline. This is only used if the online feature is acting as an online location for an offline point or offline linear feature.

OffsetDistance (Double, 15, 2) – The distance from the online point to the offline feature This is only used if the point feature is acting as an online location for an OfflinePoint or linear feature.

StationLocated (Long Integer, 9) gnYesNo – Indicates whether the online location representation of the offline feature is based on a reported station value (as opposed to, for instance, being based on a closest distance calculation). When StationLocated is ‘Yes’, the station value of the online location feature must be retained (regardless of centerline edits, etc.).


May 2007 54


inheritance)

Each and every OnlinePointForOfflineFeature must be the online location for one and only one Offline feature (M-1).

SubTypes: -- The OnlinePointForOfflineFeature (OPtFOF) APDM abstract class encapsulates the attributes and relationships that define the online point location for an offline feature. The OPtFOF abstract class inherits from OnlinePoint and therefore has the station position defined by the online location of the point along the centerline. Online point features can act as online locations for offline polyline, point and polygon features. The online point location feature might represent the intersection of the offline polyline and the centerline or the closest point on the centerline to an offline point, polyline, and/or polygon. The OPtFOF class contains offset angle and distance information as well. Often an online location can be generated from an offline feature that does not intersect the centerline, or is not located within a specific distance from the centerline. This scenario requires an offset bearing and distance from the centerline to define the position of the offline feature. The offset angle is the angle of the line drawn from the point on the centerline to the offline feature. The offset angle is measured from the centerline, looking toward the increasing station values. 10.2.5.20 OnlineFacility

Class Name: OnlineFacility Feature Class

Geometry:Implemented as an M-Aware Polyline feature class, an M-Aware Point feature class or an Object class representing an Event table.

APDM Inheritance:

ESRI Simple Object ESRI Simple Feature (Optional) FeatureArchive OnlineFeature (Ancestors - Abstract)


domained, notes)

InServiceDate (Date) - Represents the date a piece of equipment is actually put in service and is used primarily for accounting purposes. The date in the InServiceDate field may be later than the installation date.

InstallationDate (Date) - The date a piece of equipment is installed. Note that InstallationDate is important for risk analysis.

OperationalStatus (Long Integer, 9) gnOperationalStatus (required APDM domain) – A domain value indicating the status of a feature that has some operational lifespan based on FERC/OPS definitions. OperationalStatus is applied to centerline features or facility features with complex operational life spans. The gnOperationalStatus domain is considered a core APDM domain that inherits values from the gnStatus domain and must be implemented exactly as prescribed by the APDM.

SiteEventID (GUID, String, 38, FK) – Indicates the site (i.e. compressor station, meter station, custody transfer station, storage yard, etc.) that the facility belongs to or is contained



within. By utilizing this attribute online or offline facilities features can be placed or located without the need for geometry. This concept is outlined in the section ‘Non Geometric Features’.


inheritance)

Site<OnlineFacility class name>: <OnlineFacility class name> is M:1 with Site.

SubTypes: -- The OnlineFacility APDM abstract class encapsulates the attributes and relationships that define an online feature representing a facility. Facility objects are those representing real features in the world such as pipes, coatings, taps, tees and valves. Facilities are primarily defined by the InServiceDate, InstallationDate and OperationalStatus attributes which determine the operational and lifespan properties of the feature. The foreign key attribute SiteEventID provides the capability for facilities to be stored or contained as objects with or without geometry within a Site feature. The OnlineFacility abstract class also incorporates inherited online behavior such as a relationship with the StationSeries feature class. 10.2.5.21 OnlinePolylineFacility

Class Name: OnlinePolylineFacility Feature Class


APDM Inheritance:

ESRI Simple Object ESRI Simple Feature (Optional) FeatureArchive OnlineFeature OnlineFacility (Ancestors – Abstract) Casing – (Child - Example) Coating – (Child - Example) PipeSegment – (Child - Example) Sleeve – (Child - Example)


domained, notes)

BeginStation (Double, 15, 2) - A station value (i.e. measure) along a station series used to position and locate the start of the linear feature.

EndStation (Double, 15, 2) – A station value (i.e. measure) along a station series used to position and locate the end of the linear feature.

GroupEventID (GUID, String, 38) – Used to aggregate or generalize two or more online polyline features together as a single unit for the purposes of querying, reporting and calculating distances or lengths. Primarily used for online polyline features that are broken apart on interrupted style primary reference modes.


inheritance)

None.

SubTypes: --


May 2007 56

The OnlinePolylineFacility APDM abstract class differentiates the stationing requirements for a polyline from those required by an OnlinePointFacility. OnlinePolylineFacility features act as OnlinePolylines with inherited OnlineFacility properties such as InServiceDate, InstallationDate, OperationalStatus and SiteEventID. 10.2.5.22 OnlinePointFacility

Class Name: OnlinePointFacility Feature Class


APDM Inheritance:

ESRI Simple Object ESRI Simple Feature (Optional) FeatureArchive OnlineFeature OnlineFacility (Ancestors – Abstract) Appurtenance – (Child - Example) Instrument – (Child - Example) PipeJoinMethod – (Child - Example) Tap – (Child - Example) Valve – (Child - Example) Vessel – (Child, Example)


domained, notes)

Station (Double, 15, 2) – A station value (i.e. measure) along a station series used to position and locate the point feature on the centerline.

SymbolRotation (Double, 15, 2), gnAngle (required APDM domain) - A rotation angle from 0–360o for a point symbol (uses gnAngle domain). This allows operators to preserve rotation information for point symbols imported from external systems such as CAD. Allows all point symbols within the APDM to be rotated as needed; manually, or in relation to other features. This is used primarily for display in mapping applications such as alignment sheets.


inheritance)

None

SubTypes: -- The OnlinePointFacility APDM abstract class is used to differentiate the stationing and symbology requirements for a point from those required by an OnlinePolylineFacility. OnlinePointFacility inherits the facility attributes such as InServiceDate, InstallationDate, OperationalStatus and SiteEventID from the OnlineFacility abstract class. OnlinePointFacility has the Station attribute used to locate the point feature on the centerline and the SymbolRotation attribute used for cartographic purposes. 10.2.5.23 Fitting



Class Name: Fitting Feature Class

Geometry:Implemented as an M-Aware Point feature or an Object class representing an Event table.

APDM Inheritance:

ESRI Simple Object ESRI Simple Feature (Optional) FeatureArchive OnlineFeature OnlineFacility OnlinePointFacility (Ancestors – Abstract) Closure – (Child - Example) Elbow – (Child - Example) Meter – (Child - Example) Reducer – (Child - Example) Tee – (Child - Example)


domained, notes)

DateManufactured (Date) – The date the fitting or facility was manufactured.

Grade (Long Integer, 9) fcGrade - The grade at which the fitting material is rated (e.g. SMYS 40 KSI)

InletConnectionType (Long Integer, 9) fcConnectionType - The inlet connection type (e.g. weld, thread).

InletDiameter (Long Integer, 9) fcDiameter - The diameter of the inlet opening.

InletWallThickness (Long Integer, 9) fcWallThickness - The wall thickness around the inlet opening.

Manufacturer (Long Integer, 9) fcManufacturer - The manufacturer of the fitting.

Material (Long Integer, 9) fcMaterial - The material the material from which the fitting is made (e.g. PVC, steel).

PressureRating (Long Integer, 9) fcPressureRating - The pressure rating of the fitting.

Specification (Long Integer, 9) fcSpecification - The machine specification of the fitting (e.g. ANSI, API 5).


inheritance)

None

SubTypes: -- The Fitting abstract class adds attributes common to manufactured fittings (e.g. Grade, Material, Specification, etc.) to the OnlinePointFacility abstract class. Any feature that qualifies as a fitting should implement the Fitting abstract class. 10.3 APDM Metadata The goal of interoperability can only be achieved if sufficient information is recorded describing the semantic behavior, schema, and data content of an APDM geodatabase. APDM abstract classes define semantic behavior only at a high level. Metadata extends the semantic information embodied in the APDM abstract classes by further describing the behavior, structure and content of an APDM geodatabase. Metadata imbues an APDM geodatabase with sufficient ‘intelligence’ to allow applications to deal consistently with schema and data content variation.


May 2007 58

To extend behavioral definitions, two types of metadata constructs are implemented in the APDM: 1) class-level metadata, and 2) feature-level metadata. Class-level metadata stores additional behavioral information for an object or feature class that applies to all objects in the class, or to all objects within a subtype of the class. Class-level metadata is stored externally to the APDM class itself. Feature-level metadata applies to individual objects within a class. Feature-level metadata is stored internally within an APDM object or feature class in the form of metadata attributes. Several methods are suitable for storing class-level metadata. Viable candidates for class-level metadata storage include: 1) extensions to XML-based ESRI class metadata (as exposed in ArcCatalog), 2) object classes implemented within the geodatabase itself, and 3) simple relational tables stored in the database hosting the APDM. The APDM technical committee chose to implement class-level metadata as geodatabase object classes because they are easily maintained with out-of-the-box ESRI tools. In addition, at ArcGIS 9.2, geodatabase object classes can be queried and updated directly via SQL. Because the APDM class-level metadata object classes store information intrinsic to the behavior of the database, they should not be registered as versioned. Indeed, class-level metadata should not be altered after the geodatabase is initially populated. 10.3.1 Class-level Metadata Three metadata tables (object classes) are implemented in the APDM schema: ReferenceMode, APDMClass and OnlineLocationClass. These tables are required classes in the APDM. ReferenceMode stores metadata pertaining to the reference modes common to the ControlPoint, StationSeries and AltRefMeasure classes. (Reference modes represent different methods of recording station values and how these values are applied at the LineLoop level.) APDMClass stores which APDM abstract class is associated with every object and feature class in the geodatabase. While it is possible to determine which abstract class an APDM object or feature class belongs to by examining attribute and relationship content, the APDMClass table stores this information permanently for ready access. OnlineLocationClass stores the relationships of ‘online location’ classes to their parent ‘offline’ classes. Again, while it is possible to traverse these relationships on-the-fly, OnlineLocationClass stores this information permanently for ready access. 10.3.1.1 ReferenceMode

Class Name: ReferenceMode Feature Class

Geometry:Object Class

Feature Dataset: -- APDM Class

Type:--

Attributes: CalculateARM (Long Integer, 9) – gnYesNo (Default 1=Yes) –



(name, type, length, precision, scale, domained, notes) Indicates whether AltRefMeasure values are populated for the

reference mode for features stored in a class inheriting from the ‘OnlineFeature’ APDM abstract class.

RefModeSubTypeValue (Long Integer, 9) – The value of the ControlPoint/StationSeries SubType representing the reference mode.

RefModeSubTypeDescription (string, 45) – The description or name of the reference mode equal to the description of the subtype value for the ControlPoint/StationSeries feature classes.

RefModeUnits (Long Integer, 9) – gnRefModeUnits (Default 0=esriUnknownUnits) – describes the units that the stationing values for a reference mode represent.

RefModeBasis (Long Integer, 9) – gnRefModeBasis (Default 0=Unknown) – Describes the basis from which station values are specified or derived for a given reference mode.

RefModeType (Long Integer, 9) – gnRefModeType (Default 1=Uninterrupted and Adjustable) – Describes the behavior of the centerline stationing when a reroute is performed on a LineLoop. Also defines if station equations can exist for a given reference mode.


inheritance)

ReferenceModeControlPoint (core): ReferenceMode is 1:M with ControlPoint.

ReferenceModeStationSeries (core): ReferenceMode is 1:M with StationSeries.

ReferenceModeAltRefMeasure (core): ReferenceMode is 1:M with AltRefMeasure.

SubTypes: -- The ReferenceMode table stores the metadata defining each reference mode implemented in an APDM geodatabase. Reference mode subtypes are found in ControlPoint, StationSeries and AltRefMeasure. Reference modes are applied to the entire geodatabase. Each StationSeries feature must belong to one and only one LineLoop object and must implement one of the defined reference modes. Each ControlPoint feature must belong to one and only one StationSeries feature and must implement one of the defined reference modes. Each StationSeries feature must be composed of two or more related ControlPoint features to establish the stationing for the reference mode defining the StationSeries feature. The default subtype value for ControlPoint, StationSeries and AltRefMeasure must all be the same; this reference mode is designated as the ‘Primary Reference Mode’ (PRM). Other implemented reference modes are referred to as ‘Alternate Reference Modes’ (ARM’s). Any ARM ControlPoint feature must have a corresponding PRM ControlPoint feature. All online event features in the geodatabase must be stored using the PRM and related to appropriate PRM StationSeries features.


May 2007 60

Reference mode distance units are stored in the RefModeUnits field of ReferenceMode. They are stored explicitly because the reference mode distance units do not necessarily conform to the units of the spatial reference for the Transmission feature dataset. For instance, the spatial reference units of the Transmission feature dataset might be decimal degrees whereas the distance units of one of the references modes might be meters. The contents of the gnRefModeUnits domain correspond to the values found in the ArcObjects esriSRUnitType enumeration. This facilitates easy programmatic manipulation of data based on the information stored in RefModeUnits. RefModeBasis stores a coded value defining the physical basis upon which station values (measures) are accumulated for a particular reference mode. Station values are most commonly collected in the field during construction by physically measuring the length of the pipeline (3D Slack Chain basis). However, using ArcToolbox geoprocessing tools it is possible to calculate station values using a variety of methods. The most common method in the industry for calculating stationing is to compute it as 2D horizontal distance in a specified projection system, i.e. ‘horizontal stationing’ (2D Projected basis). Station values may also be calculated by draping the pipeline over a Digital Elevation Model (DEM) (3D Projected basis), or by calculating distances on the geoid (3D Geoid basis). Some reference modes may start with a defined physical basis, but because of their behavior during reroute operations, become fundamentally ‘arbitrary’ in terms of physical basis (Arbitrary basis). An example of a reference mode with an arbitrary basis is Milepost. Milepost markers are placed at fixed locations; each time a pipeline reroute is performed the physical distance between affected mileposts changes. The Milepost measurement system is therefore ‘arbitrary’. Examples of all of the currently defined ReferenceModeBasis codes are illustrated below:


May 2007 62

RefModeType stores coded values that determine how the StationSeries features in each reference mode behave during a reroute. The four possible values of the gnRefModeType domain are: • Uninterrupted and Adjustable • Uninterrupted and Not Adjustable • Interrupted and Adjustable • Interrupted and Not Adjustable

The four RefModeType code values store the four possible combinations of two independent properties: Uninterrupted/Interrupted and Adjustable/Not Adjustable. Both properties describe the reference mode (stationing) behavior of StationSeries features relative to their related LineLoop object during a two-point reroute:

• Uninterrupted – StationSeries features employing a reference mode with the ‘Uninterrupted’ RefModeType property cannot be split into multiple station series features during a reroute operation (i.e. station equations are not introduced during a reroute operation).

• Interrupted – StationSeries features employing a reference mode with the ‘Interrupted’ RefModeType property can be split during reroute operations (i.e. station equations are introduced during a reroute operation).

• Adjustable – Station values may be recalculated ‘downstream’ (down station value) of a two-point reroute to accommodate changes in pipeline length introduced by the reroute.

• Not Adjustable – Station values may not be recalculated ‘downstream’ of a two-point reroute to accommodate changes in pipeline length introduced by the reroute. Rather, station values must be recalculated (rescaled) over the length of the reroute itself.



Examples of reference modes that are Uninterrupted and Adjustable include PODS Continuous Measure and ISAT NET stationing, as depicted below:


May 2007 64

An example of an Uninterrupted and Not Adjustable reference mode is Milepost, as shown below:



Valve Section (valve + offset) is an example of an Interrupted and Adjustable reference mode, as illustrated below:


May 2007 66

The ubiquitous Engineering Stationing reference mode is an example of an Interrupted and Not Adjustable reference mode, as shown below:



10.3.1.2 APDMClass

Class Name: APDMClass Feature Class



Type:--


domained, notes)

ClassEventID (GUID, String 38) – A unique identifier for the class. ClassName (String, 28) – The name of the class as derived from the

ESRI.ArcGIS.Geodatabase.IDataset.Name property for the ObjectClass or FeatureClass.

APDMClassType (Long Integer, 9) – gnAPDMClassType – Denotes the APDM Abstract class that is the direct ancestor of the object/feature class.

RequiresGeometry (Long Integer, 9) – gnRequiresGeometry – Indicates whether the class is stored using geometry, or as an object for use as a route event.


inheritance)

APDMClassOriginClass (core): APDMClass is 1:M with OnlineLocationClass

APDMClassOnlineClass (core): APDMClass is 1:M with OnlineLocationClass

APDMClassAltRefMeasure (core): APDMClass is 1:M with AltRefMeasure

APDMClassCPLocation: APDMClass is 1:M with CPLocation APDMClassRemovedPoint: APDMClass is 1:M with

RemovedPoint APDMClassRemovedLine: ADPMClass is 1:M with RemovedLine

SubTypes: -- APDMClass stores metadata describing the abstract class type of each object and feature class in the APDM schema. The primary purpose of the table is to provide a permanent repository for this information so that users and application developers are spared the task of parsing the attribute and relationship content of the APDM classes to determine their abstract class type. The gnRequiresGeometry domain is core and includes the following values: -1=Unknown (Verified), 0=Unknown, 1=Must Have, 2=Must Not Have, 3=Optional. The APDMClassOriginClass and APDMClassOnlineClass relationships do not completely embody the restrictions on the relationships of APDM offline classes to online location classes. In practice, while an APDM offline class can have multiple online location classes associated with it, an online location class can only be associated with one parent APDM offline class,


May 2007 68

The following class types are codes that are delineated for the APDMClassType field: • APDMObject • CenterlineObject • NonFacilityObject • CenterlinePolyline • CenterlinePolylineEvent • CenterlinePoint • OfflineFeature • OfflinePoint • OfflineFacility • OfflinePointFacility • OfflineNonPointFacility

• OnlineFeature • OnlinePolyline • OnlinePolylineForOfflineFeature • OnlinePoint • OnlinePointForOfflineFeature • OnlineFacility • OnlinePolylineFacility • OnlinePointFacility • Fitting • Audit

10.3.1.3 OnlineLocationClass

Class Name: OnlineLocationClass Feature Class



Type:--

Other Notes: -- Attributes:

(name, type, length, precision, scale, domained, notes)

OriginClassEventID (GUID) – A unique identifier for the ‘offline’ parent class.

OnlineClassEventID (GUID) – A unique identifier for the ‘online location’ child class.

OnlineLocationMechanism (Long Integer, 9) - gnOnlineLocationMechanism (Default 0=Unknown) – The mechanism used to derive the ‘online location’ feature(s) for an ‘offline’ feature.


inheritance)

APDMClassOriginClass (core): OnlineLocationClass is M:1 with APDMClass

APDMClassOnlineClass (core): OnlineLocationClass is M:1 with APDMClass

SubTypes: -- OnlineLocationClass stores the ClassEventID for the offline and online classes involved in an ‘offline’ and ‘online location’ relationship. As noted above, the APDMClassOriginClass and APDMClassOnlineClass relationships do not completely embody the restrictions on the relationships of APDM offline classes to online location classes. First, only offline classes should appear in OriginClassEventID. Second, while an



APDM offline class can have multiple online location classes associated with it, an online location class can only be associated with one parent APDM offline class, The offline class must inherit from the OfflineFeature or OfflineFacility APDM abstract classes, or their descendants. The online class must inherit from either the OnlinePolylineForOfflineFeature or OnlinePointForOfflineFeature APDM abstract classes. The relationship of online location feature classes to offline feature classes is depicted below:


May 2007 70

The OnlineLocationMechanism attribute contains coded values indicating how the location of the ‘online location’ feature is derived from the ‘offline’ feature. Choices include:



• ClosestPoint – the closet point on a centerline from an offline point or polygon.

• DistanceAzimuth – the online point, angle and distance used to locate an offline feature and vice versa.

• BufferIntersection – the intersection of the centerline with a buffer derived from an offline point, polygon or polyline.

• PolygonIntersection – the intersection of an offline polygon and the centerline.

• PointIntersection – the intersection of an offline polyline and the centerline.

• PolylineEasement – the easement calculated from either side of the intersection point of an offline polyline and the centerline.

• PointEasement – the easement calculated on either side of an online point feature.

• PolylineEndpoint – an online point location calculated to cover the endpoint(s) of an online polyline feature.

• PolylineCenterpoint – an online point location calculated at the midpoint (as determined by station value) of an online polyline feature.

• AggregatePoint – an online point location calculated at the midpoint (as determined by the average or mean station value) of a collection of online point features.

• AggregatePolyline – an online polyline feature calculated as an aggregation of a collection of online polyline features.

The behavior of each of the above OnlineLocationMechanism codes is depicted in the following diagrams:


May 2007 72


May 2007 74


May 2007 76



10.3.2 Feature-level Metadata Feature-level metadata stores information that defines the behavior of individual features within a feature class. Because feature-level metadata affects individual features, these metadata elements can be stored with the features themselves (as data attributes of the features). Feature-level metadata in the APDM is used to define the behavior of online events and ControlPoint features during centerline editing operations that change the shape of the centerline or alter station values.


May 2007 78

10.3.2.1 Online Event Feature-Level Metadata Attributes Two feature-level metadata attributes define the behavior of online event features during centerline edits: CLEditResponse and CLValidityTolerance. CLEditResponse describes how the location of a stationed feature responds to a centerline edit. CLValidityTolerance describes how far the centerline can move away from an event located by X/Y before the event location becomes ‘invalid’ relative to the centerline. These two attributes are defined for the OnlineFeature APDM abstract class and are inherited by its descendents (OnlinePolyline, OnlinePoint, OnlinePolylineForOfflineFeature, OnlinePointForOfflineFeature, OnlinePolylineFacility, OnlinePointFacility, and Fitting). CLEditResponse contains coded values that determine how the position of an online feature is calculated in response to a centerline edit that changes the shape of the centerline or alters the station values of ControlPoint features in the vicinity of the affected feature. The following CLEditResponse codes and resulting behaviors are defined:

• Relative – The location of an event is determined solely by Station value(s). If the centerline moves, the event moves with it. If Station values on the nearest surrounding ControlPoint features are altered, the position of the event slides up or down the centerline accordingly. This is the default behavior for any event where the only source data for positioning is stationing.

• Proportional – The location of an event must fall on the centerline, but its position is determined by its proportional distances from the nearest surrounding ControlPoint features. If the centerline moves, the event moves with it. The event’s proportional distances from the nearest surrounding ControlPoint features remain constant. If the Station value(s) of the nearest surrounding ControlPoint features change, the Station value(s) of the event changes accordingly, but its proportional distances from the nearest surrounding ControlPoint features remain constant. (The event’s proportional distances from the nearest surrounding ControlPoint features always remain constant.) Example – data captured from originally non-stationed systems, or from systems where stationing was unclear or missing on source documents. ControlPoint station values may be adjusted over a long period of time; events should not necessarily slide around when this occurs. But events should move with the centerline if the centerline is moved.

• Absolute – The location of an event is determined solely by its X/Y position. If the centerline moves, the event location remains unchanged, even if that means the event no longer falls on the centerline (see CLValidityTolerance). Station value is always determined by interpolation from surrounding ControlPoint features. Station value(s) for the event changes both when the centerline moves and when Station values for surrounding ControlPoint features are adjusted. Example – data positioned by GPS. In the case that the feature no longer falls on the centerline then the feature could be ‘retired’ or ‘deleted’.



The behavior of the ‘Relative’ and ‘Proportional’ CLEditResponse values with respect to online features are illustrated in the following diagram:


May 2007 80

CLValidityTolerance applies only to online events with spatially fixed locations (CLEditResponse = ‘Absolute’). Centerline edits may cause such events to no longer be spatially coincident with the centerline. CLValidityTolerance defines the distance tolerance between an event and the centerline beyond which the event’s location becomes spatially ‘invalid’ by virtue of being positioned too far away from the centerline. Distance units for CLValidityTolerance are the same as RefModeUnits of the Primary Reference Mode. With respect to the ‘Absolute’ value for CLEditResponse, one example of a use for it is for ElevationPoint features derived from a Digital Elevation Model (DEM). The X/Y locations of such points are known exactly and should not move with the centerline when the centerline is edited. If the centerline is moved significantly then the DEM-derived ElevationPoint features should become ‘invalid’, as depicted in the following illustration:


May 2007 82

10.3.2.2 ControlPoint Feature-Level Metadata Attributes Four feature-level metadata attributes define the behavior of ControlPoint features during centerline edits: CLXYEditResponse, CLStationEditResponse, CLZEditResponse, and CLControl. These attributes are defined in the CenterlinePoint APDM Abstract class. The ControlPoint metadata attributes come into play during centerline edit operations that change the locations or station values of ControlPoint features. ControlPoint metadata attributes play no role in pipeline reroute operations (where a section of the centerline is ‘cut’ out or replaced. Reroute behavior is governed by class-level reference mode metadata.) The behavior of online features during centerline edit operations is governed according to their CLEditResponse codes and CLValidityTolerance values. A ControlPoint feature is defined by its X position, Y position, Z (elevation) position, and station value. Each of these properties represents a ‘degree of freedom’. If a ControlPoint’s X, Y, Z and station values are freely altered, the ControlPoint enjoys four basic degrees of freedom. The ControlPoint metadata attributes (excepting CLControl) serve to define limits on the degrees of freedom available to a particular ControlPoint feature. CLXYEditResponse stores coded values that define how a ControlPoint feature is allowed to move in the X/Y plane. Because the X/Y position of a ControlPoint feature has relationships to the X/Y positions of the surrounding ControlPoint features, delineating controls on the X/Y position of a ControlPoint is considerably more complex than simply defining whether the ControlPoint is allowed to move in X or Y. The domain for CLXYEditResponse has six values:

1. Assigned – The X/Y position of the ControlPoint may be freely adjusted. 2. Fixed Distance – For Fixed Distance, a ControlPoint can be moved, but the

distances to the surrounding ControlPoints must held constant. Deflection angle at the ControlPoint in question can vary, though. FixedDistance can be applied to a single ControlPoint or a group of two or more adjacent ControlPoints.

3. Fixed Deflection – With Fixed Deflection, a ControlPoint can be moved, but the

deflection angle at the ControlPoint relative to surrounding ControlPoints must remain constant. Fixed deflection allows the preceding and following control points to be translated in or out (in terms of distance from the FixedDeflection ControlPoint). FixedDeflection can be applied to a single ControlPoint or a group of two or more adjacent ControlPoints.

4. Fixed Inline – The ControlPoint can be moved, but it must always be inline with

surrounding ControlPoints. This addresses the concern about a Geographic Positioning System (GPS) ControlPoint surrounded by Points of Inflection (P.I.s). In this situation deflection must remain 0 for the point since it is a GPS



ControlPoint. Fixed Inline is a special case of Fixed Deflection where the deflection angle must be zero.

5. Fixed Geometry – The ControlPoint can be moved, but only as a unit with the

surrounding ControlPoint features. In other words, the ControlPoint belongs to a segment of the centerline with a fixed shape; the segment can be moved, but the segment's shape is constant. For data retrieved from old as-built drawings the position of ControlPoints relative to each other is well known, although the absolute location may not be. ‘Fixed Geometry’ allows a group of adjacent ControlPoints to be treated as a single unit for X/Y translations. A ControlPoint with FixedGeometry can be moved, but the adjacent ControlPoints must move as a unit with it. FixedGeometry must be applied to two or more adjacent ControlPoint features to be meaningful.

6. Fixed – The X/Y position of the ControlPoint is fixed and cannot be altered.

Fixed can be applied to a single ControlPoint if desired. These CLXYEditResponse values are ordered according to decreasing degree of freedom in the X/Y plane. Fixed Deflection and Fixed Distance may be thought of as less restrictive subsets of Fixed Geometry. While Fixed Geometry must be applied to two or more contiguous control points, Fixed Distance and Fixed Deflection may both be applied to individual control points. The above two properties are useful for adjusting as-built survey traverses. For instance, a user can 'stretch' a traverse in such a way that all deflection angles are preserved, but the distances between control points are increased. Alternatively, a user can 'stretch' a traverse such that the distances between control points remain constant, but all deflection angles become shallower. (Note that ArcMap provides an out-of-the-box tool for 'stretching' polyline shapes, but it affects both distances and angles between vertices.) The behavior of CLXYEditResponse values are illustrated below:


May 2007 84



CLStationEditResponse stores coded values that define how the station value of a ControlPoint may be altered. Again, because the station value of a ControlPoint feature is related to the station values of surrounding control points, defining degrees of freedom on the ControlPoint station value is more complex than simply stating whether the station value can be modified. The domain for CLStationEditResponse has five values:

1. Assigned – The station value for the ControlPoint may be freely adjusted within the station range of the surrounding ControlPoints.

2. Offset Downstream – The station value of the ControlPoint is set relative

and constant to the first ControlPoint that has a CLStationEditResponse of either ‘Fixed’ or ‘Assigned’ downstream (up station). If the station value of the fixed ControlPoint relative to the current ControlPoint is updated, then the station value of the current ControlPoint is likewise updated.

3. Offset Upstream – The station value of the ControlPoint is set relative and

constant to the first ControlPoint that has a CLStationEditResponse of either ‘Fixed’ or ‘Assigned’ upstream (down station). If the station value of the fixed ControlPoint relative to the current ControlPoint is updated, then the station value of the current ControlPoint is likewise updated.

4. Interpolated – The station value for the ControlPoint is interpolated linearly

between surrounding ControlPoints that have CLStationEditResponse set to Fixed or Assigned. For example, Interpolated is applied to intermediate milepost ControlPoints situated between ControlPoints actually associated with actual mileposts.

5. Fixed – The station value for the ControlPoint is fixed and may not be altered.

The CLStationEditResponse code values are listed in order of decreasing degree of freedom. The behavior of CLStationEditResponse codes are shown below:


May 2007 86

CLZEditResponse stores coded values that define how the elevation (Z) value of a ControlPoint may be altered. ControlPoint feature elevation values may be partially dependent on the elevations values of surrounding ControlPoints, as well as on topography, thus complicating the definition of degrees of freedom for ControlPoint elevation values. Because elevation values are optional in the APDM, one valid option is to not assign elevation values, period. The domain for CLZEditResponse has five values:



• Not Applicable – The ControlPoint has no elevation value or elevation is not

applicable. Since APDM supports a two-dimensional model this becomes the default for control point elevation edits because they are not applicable in this context.

• Assigned – The elevation of the ControlPoint may be freely adjusted. • Derived – The elevation of the ControlPoint is derived from a topographic

surface. If the ControlPoint is moved, elevation must be recalculated. • Interpolated – The elevation of the ControlPoint is interpolated linearly between

surrounding ControlPoints. • Fixed – The elevation of the ControlPoint is fixed and may not be altered.


May 2007 88

CLZEditResponse behavior is depicted below:



CLControl stores a Yes/No value defining whether the ControlPoint participates in the construction of the centerline StationSeries feature. The principal reason for implementing CLControl is to handle the transition from traditional surveying methods to modern differential GPS control in defining the centerline. Traditionally, the centerline is represented as a traverse defined by a series of Points of Inflection (P.I.’s). P.I.’s are actually survey artifacts with respect to the true location of the centerline; the centerline does not actually pass through P.I.’s. Rather, the pipe bends that occur at the locations of P.I.’s define an arc whose radius is inside the P.I. GPS points derived from field survey or a geo-pig inline inspection can be used to approximate the arc to a greater degree of precision than the P.I. does. As time goes by, one can expect to replace P.I. ControlPoint features with differential GPS ControlPoint features. By setting CLControl to ‘No’ one can maintain a P.I. ControlPoint for historical value, but not allow it to participate in the construction of StationSeries features. CLControl behavior is illustrated below:

10.4 APDM Core Classes and Relationships The APDM is designed to allow end users to modify the content of the model to meet GIS, organizational, and business requirements. The model has core elements that must remain consistent for each implementation of the APDM. These core elements are required to maintain the semantic framework and behavior of the model, particularly with respect to the centerline and the methodology for applying and using linear referencing along the centerline.


May 2007 90

The feature/object classes and relationship classes described below are considered to be the core elements of the APDM. For a particular APDM implementation to be considered compliant, the APDM core classes must be implemented with the same names, attributes and relationships as described here. (Naturally, the relationships associated with a particular core class are required only if the object/feature class on the other side of the relationship is implemented.) In some cases, a core class implements a certain type of relationship class with one or more classes of a particular type (i.e. the target class inherits from a given APDM abstract class). As such, the associated relationship classes may be thought of as belonging to a particular relationship type that in effect inherits from a species of abstract relationship class. While the target classes of these relationship types may be optional, if such a class is implemented, then a relationship of the associated relationship type must also be implemented. In these situations, the relationship classes themselves are core to the model and must be implemented in the way specified. For example, the core class StationSeries implements a one-to-many relationship with all online feature classes. None of the online feature classes are core to the model, but any time an online feature class is implemented, the requisite relationship class with StationSeries must also be implemented. Required relationship classes and relationship class types are clearly identified by the designations: (core) and (core relationship type), respectively. The core classes may be extended with additional attribute content or relationships as desired, but their core attributes and relationship classes as described here must not be removed. Beyond the core elements there are no required or mandated elements in the model. End users are free to remove, add, or modify any of the suggested feature classes and attributes except the core elements to build a model that meets their business needs. The following APDM feature, object and attributed many-to-many relationship classes are considered core elements of the model:

• Object classes: o Activity o ActivityHierarchy o AltRefMeasure o <class name>Audit o Company o ExternalDocument o LineLoop o LineLoopHierarchy o OwnerOperator o Product o SubSystem o SubSystemHierarchy

• Feature classes:



o ControlPoint o Site o StationSeries o SubSystemRange

Core relationship classes and relationship class types are discussed within the context of the above core object and feature classes. The APDM core feature, object and relationship classes are depicted below:


May 2007 92


May 2007 94

10.4.1 EventID All feature classes and object classes must have an attribute named EventID. This attribute is defined as a Globally Unique Identifier (GUID), stored in the APDM as a string field (string, 38). The purpose of the EventID attribute is to provide a mechanism for uniquely identifying each feature or object in the geodatabase independent of the feature or object class to which it belongs. EventID is specified in the Microsoft registry GUID format ({xxxxxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx}) to make each object in any class globally unique from all other features. Using GUIDs for unique identifiers ensures that all features maintain a unique identifier even if they are exported from and imported back into a geodatabase. Note that using a long integer or the Object ID does not necessarily ensure global uniqueness or the preservation of a unique ID value assigned to each feature on export and import. (Typically, long integer IDs are incremented from zero in each database implementation, so primary key collision can easily occur during database merges and imports.) Also note that the term "event" in EventID does not denote that this attribute pertains to event tables or events only. EventID was chosen to represent a global ID for any event that occurred on or along a pipeline system, be it an online or offline feature. EventID may be thought of as synonymous with such terms as "Feature ID" or "GeoEntityID". 10.4.2 Core Object Classes 10.4.2.1 Activity Class Name: Activity Feature Class Geometry:

Implemented as an Object Class

APDM Inheritance:

ESRI Object APDM Object Object Archive NonFacilityObject (Ancestors – Abstract)

Attributes: (name, type, length, precision, scale, domained, notes)

ActivityDate (date) – The date on which the activity occurred. ActivityDescription (String, 120) – A description or categorization

of the activity. ActivityName (String, 90) – A title or description of the activity. ActivityType (Long Integer, 9) – gnActivityType – The type of

activity. Relationships: (cardinality, optionality, composite, inheritance)

ActivityChildActivity (core): Activity is 1:M with ActivityHierarchy

ActivityParentActivity (core): Activity is 1:M with ActivityHierarchy

InspectionRangeActivity: InspectionRange is M:N with Activity ActivityExternalDocument (core): Activity is M:N with

ExternalDocument Activity<Object/feature class name>Audit (core relationship type):

Activity is 1:M with <Object/feature class name>Audit



SubTypes: -- The Activity object class is used to track regular pipeline activities and the events that are affected by those activities. Specifically, the rows in the Activity object class store information pertaining to activities conducted on the pipeline that affect one or more events or features on or along the pipeline. Common activities include work orders, inspections, excavations, and tests. The Activity object class has a one-to-many relationship with each <object/feature class name>Audit object class. This relationship type is core to the model. Any object or feature class that needs to be associated with Activity should implement an <object/feature class name>Audit object class and the attendant Activity<object/feature class name>Audit relationship class. These relationships model the fact that one activity can be related to one or more events (of different types) that were affected by or participated in the activity. Activity has a many-to-many relationship with ExternalDocument, whereas many documents might provide source materials to the activity. In turn, a single document might be related to many activities. Activity has a one-to-many relationship with InspectionRange indicating that a given inspection-related activity can occur over many linear areas of the pipeline system. The two one-to-many relationships of the Activity object class to the ActivityHierarchy object class allows activities to be organized within an arbitrarily recursive hierarchy (that is, the activity hierarchy can have as many levels as desired). For more information on how this relationship structure works, see 10.4.2.2 ActivityHierarchy. 10.4.2.2 ActivityHierarchy Class Name: ActivityHierarchy Feature Class Geometry:


APDM Inheritance:

ESRI Object APDM Object (Ancestors – Abstract)


ParentActivityEventID (String, 38) – A foreign key to Activity storing the EventID of an activity that represents a “parent” hierarchy level to the activity identified by ChildActivityEventID.

ChildActivityEventID (String, 38) – A foreign key to Activity storing the EventID of an Activity that represents a “child” hierarchy level to the activity identified by ParentActivityEventID.

Relationships: (cardinality, optionality,

ActivityChildActivity (core): Activity is 1:M with ActivityHierarchy


May 2007 96

composite, inheritance) ActivityParentActivity (core): Activity is 1:M with ActivityHierarchy

SubTypes: -- Note that the construction of Activity, LineLoop and SubSystem hierarchies in the model are all identical; the relationship of Activity to ActivityHierarchy is mirrored by the relationship of LineLoop to LineLoopHierarchy and SubSystem to SubSystemHierarchy. The ActivityHierarchy object class is used to establish a hierarchy of activities. Recursion in the activity hierarchy is unlimited; a given APDM implementation may establish as many activity hierarchy levels as desired. The activity hierarchy is facilitated by the two relationship classes that tie ActivityHierarchy to Activity: 1) ActivityParentActivity and 2) ActivityChildActivity. Each record in ActivityHierarchy stores a parent and child activity record in the activity hierarchy. As an example, consider an activity hierarchy with three levels: The first (root) level is occupied by activities ‘A’ and ‘B’. Activity ‘A’ is a parent to activities ‘C’ and ‘D’; activity ‘B’ has no children. Activity ‘C’ is a parent to activities ‘X’ and ‘Y’; activity ‘D’ is a parent to activity ‘Z’. A tree view of the activity hierarchy has the following appearance:

• A o C

X Y

o D Z

• B The ActivityHierarchy table for the hypothetical activity hierarchy is populated with the following records (GUIDs are replaced with the above letter designations for clarity):

ParentActivityEventID ChildActivityEventID A C A D C X C Y D Z

Note that no record for activity ‘B’ appears in the ActivityHierarchy table. By convention, root level activities that have no children do not appear in the ActivityHierarchy table. This facilitates the following model behavior: if the activity hierarchy consists of only one level (flat), ActivityHierarchy need not be populated.



10.4.2.3 AltRefMeasure Class Name: AltRefMeasure Feature Class Geometry:


APDM Inheritance:

ESRI Object APDM Object Object Archive CenterlineObject (Ancestors – Abstract)


BeginStationSeriesEventID (String, 38) – The foreign key to the Station Series feature associated with the begin station value

BeginStation (Double, 15, 2) – The station value for the beginning of an Online Polyline feature, or the station value of an Online Point feature.

EndStationSeriesEventID (String, 38) – The foreign key to the Station Series feature associated with the end station value.

EndStation (Double, 15, 2) – The station value for the end of an Online Polyline feature. For Online Point features, the value for this attribute is the same as that for BeginStation.

TotalLength (Double, 15, 2) – The length (in measurement system units) of an Online Polyline feature. For split Online Polyline features, the aggregate length.

ClassEventID (String 38) – A unique identifier to the APDMClass object class storing the feature class associated with the AltRefMeasure record.

SubtypeCD (Long Integer, 9) – The subtype field. Each subtype denotes a different type of stationing measurement.

Relationships: (cardinality, optionality, composite, inheritance)

ReferenceModeAltRefMeasure (core): ReferenceMode is 1:M with AltRefMeasure

APDMClassAltRefMeasure (core): APDMClass is 1:M with AltRefMeasure

BeginStationSeriesAltRefMeas (core): StationSeries is 1:M with AltRefMeasure

EndStationSeriesAltRefMeas (core): StationSeries is 1:M with AltRefMeasure

<Feature class name>AltRefMeasure (core relationship type): <Feature class name> is M:N with AltRefMeasure

SubTypes: 1 = Continuous 2 = Engineering 3 = Horizontal 4 = Milepost 5 = Slack Chain 6 = Valve Section 7 = Unspecified


May 2007 98

The AltRefMeasure object class is designed to store stationing information for all measurement systems for online feature classes. The Station attribute in Online Point feature classes, and the BeginStation and EndStation attributes in Online Polyline feature classes, store stationing values for the primary measurement system only. AltRefMeasure provides a means for storing stationing values for alternative measurement systems, as well as for the primary measurement system. AltRefMeasure is related to each Online Point and Online Polyline feature class via a many-to-many relationship class in the form <Feature class name>AltRefMeasure. For each online feature, AltRefMeasure stores one record per APDM reference mode. In the general case, each record in a feature class has many records in AltRefMeasure. When the Primary Reference Mode is interruptible, Online Polyline features must be split into multiple features if they cross one or more station equations (two or more Station Series features). The GroupEventID attribute can be used to aggregate the split features. AltRefMeasure is used to store the begin and the end station values for the aggregate feature. In this case, one row in AltRefMeasure is related to many features in the <Feature class name>AltRefMeasure relationship. StationSeries implements one-to-many relationships with AltRefMeasure via the BeginStationSeriesAltRefMeas and EndStationSeriesAltRefMeas relationship classes. APDMClass implements a one-to-many relationship to AltRefMeasure via the APDMClassAltRefMeasure relationship; this foreign key relationship allows the user to easily query records in AltRefMeasure by feature class. AltRefMeasure is subtyped in the same fashion as ControlPoint and StationSeries; each subtype denotes a different reference mode. ReferenceModeAltRefMeasure ties AltRefMeasure to the ReferenceMode object class through the SubtypeCD attribute; ReferenceMode stores behavioral metadata for the reference mode. 10.4.2.4 <class name>Audit Class Name: <class name>Audit Feature Class Geometry:

Implemented as an Object Class.

APDM Inheritance:



ActivityDate (Date) – The date on which an activity for this particular feature/object occurred. This date does not necessarily correspond to the activity date stored in the related Activity record.

ActivityEventID (String, 38) – A foreign key to Activity storing the EventID of the activity with which this <class name>Audit record is associated.



<class name>EventID – A foreign key to the <class name> object/feature class storing the EventID of the object/feature with which this <class name>Audit record is associated.


Activity<class name>Audit (core relationship type): Activity is 1:M with <class name>Audit

<class name>Audit (core relationship type): <class name> is 1:M with <class name>Audit

<class name>AuditDocument (core relationship type): <class name>Audit is M:N with ExternalDocument

SubTypes: -- The Audit object classes represent a singular type of entity within the APDM. The Audit object classes are physically implemented within the model and are required (core) whenever a class requires a relationship with Activity or ExternalDocument. However, <class name>Audit is documented as a ‘template’ class from which multiple concrete classes may be implemented. In this sense, <class name>Audit behaves like an APDM abstract class. The classification of <class name>Audit as either ‘core’ or ‘abstract’ is largely arbitrary. <class name>Audit is documented with the core classes primarily because the Audit classes are physically implemented in the model, unlike the other APDM abstract classes. The Audit object classes record historical events or comments about a feature within a <parent>class. The <x> nomenclature is used to denote the name of a class that is participating in a 1-M relationship with the Audit class. For example, the feature class PipeSegment may have a PipeSegmentAudit object class where the EventID (primary key) value of the PipeSegment is recorded in the PipeSegmentEventID attribute of the PipeSegmentAudit table. Using this relationship many historical events can be recorded for a given PipeSegment feature. The relationship between the audit object class and the parent class is required and an audit record cannot exist without the parent class. A 1-M relationship class must exist between the activity class and the audit class; however the value of the ActivityEventID attribute is not required to be populated for each record in the audit class. The purpose of this mechanism is to relate many features to a single activity via the feature’s audit class. For example, a pipe inspection exposes a pipe segment and two valve features. Each of the three features has an audit record created to signify the inspection and each audit record has the EventID value of the activity. If the user browses the activity in the ArcMap attribute editor, it would become apparent that related records exist in the ValveAudit and PipeSegmentAudit tables for the current feature. These related audit records would then relate to the parent features in the valve and pipe segment tables respectively. In this manner, an activity can ‘link’ or tie together many features from disparate feature and object classes. The audit class relationship can be created for almost every class within the APDM. This construct supplies the mechanism for advanced reporting and historical archiving functionality with the APDM.


May 2007 100

Technically, the <class name>Audit object class provides the mechanism that relates features to activities. The <class name>Audit object class mediates what is actually a many-to-many relationship between the <class name> object/feature class and Activity. That is, a given feature may be associated with many activities, but a given activity may also be related to many features. The <class name>Audit object class type is defined this way because it also facilitates a many-to-many relationship with ExternalDocument. The <class name>AuditDocument relationship ties a related document to both a feature and an activity. This type of specific relationship cannot be supported simply by implementing separate many-to-many relationships from the <class name> object/feature class to Activity and from the <class name> object/feature class to ExternalDocument. A <class name>Audit object class must be created for any feature class or object class within the APDM geodatabase that needs to be associated with activities or external documents. 10.4.2.5 Company Class Name: Company Feature Class Geometry:


APDM Inheritance:



CompanyLabel (String, 45) – Additional label, acronym, or designation used for the company.

CompanyName (String, 45) – Company name. CompanyType (Long Integer, 9) – gnCompanyType – Describes

the services the company provides (pipeline, contractors, etc.) Relationships: (cardinality, optionality, composite, inheritance)

CompanyOwnerOperator (core): Company is 1:M with OwnerOperator

LineCrossingCompany: LineCrossing is M:N with Company CompanyContact: Company is M:N with Contact CompanyAddress: Company is M:N with Address CompanyMeterReading: Company is 1:M with MeterReading CompanyCISReading: Company is 1:M with CIS Reading

SubTypes: -- The Company object class is designed to store information about any company that owns, operates, services, supplies, repairs, and/or maintains any features or events that occur on or along the pipeline system. The Company object class has a many-to-many relationships with Address and Contact. A company often has many addresses; occasionally the same address may be shared by multiple companies (usually subsidiaries). A company typically has many contacts that represent it; occasionally a single individual may represent multiple companies (usually an independent contractor).



The Company object class implements a many-to-many relationship with the LineCrossing feature class, reflecting potential multiple ownership of the crossing line. The Company object class has a many-to-many relationship with the LineLoop object class reflecting the roles that multiple companies may play in the ownership and operation of the actual line loops comprising a pipeline system. 10.4.2.6 ExternalDocument Class Name: ExternalDocument Feature Class Geometry:


APDM Inheritance:



DocumentDescription (String, 120) – A textual description of the document.

DocumentType (Long Integer, 9) – gnExternalDocumentType – Describes type of external document (e.g., CAD drawing, document, map)

FilePath (String, 255) – UNC or mapped drive path to directory containing file.

FileName (String, 255) – Name of file including extension. HyperLink (String, 255) – Optional URL hyperlink to the

document. Relationships: (cardinality, optionality, composite, inheritance)

ExternalDocumentGeoMetaData: ExternalDocument is 1:M with GeoMetaData

<class name>AuditDocument (core relationship type): <class name>Audit is M:N with ExternalDocument

ActivityExternalDocument (core): Activity is M:N with ExternalDocument

DocumentPointExternalDoc: DocumentPoint is M:N with ExternalDocument

SubTypes: -- The ExternalDocument object class stores information describing the location and content of an external file object stored on a disk drive, web folder or document management system. The purpose of the ExternalDocument object class is to link features and events with external documentation using a similar method to that of the ArcMap Hyperlink tool, but it stores the information within the underlying object class so that external applications can access the information. Assuming the appropriate application is installed on the workstation, simply clicking on a properly populated FileName or HyperLink field in the ArcMap Identify tool window causes the referenced document to open.


May 2007 102

The many-to-many <class name>AuditDocument relationship type allows multiple documents to be related to multiple features. The ExternalDocument object class has a one-to-many relationship with the GeoMetaData object class, modeling the fact that an external document can contain metadata pertaining to the origin/provenance of positional information recorded in a GeoMetaData object class record. The ExternalDocument object class has a many-to-many relationship with the DocumentPoint feature class – one DocumentPoint feature can be associated with multiple external documents; a single external document may be referenced by multiple DocumentPoint features. Conceivably, one DocumentPoint feature could reference one or more documents that might in turn reference additional DocumentPoint features or other locations. (See the DocumentPoint feature class description.) ExternalDocument has a many-to-many relationship with Activity such that a single document can provide information about many activities, and a single activity can be associated with many documents. This relationship allows documents to be related directly to an Activity record without requiring any intermediary association with a feature via the <class name>AuditDocument relationship type. 10.4.2.7 LineLoop Class Name: LineLoop Feature Class Geometry:

Implemented as an Object class.

APDM Inheritance:



LineName (String, 45) – Name of the pipeline. LineType (Integer, 3) – clLineServiceType – Classification of the

line type, e.g. ‘Gathering’, ‘Transmission’. Relationships: (cardinality, optionality, composite, inheritance)

LineLoopStationSeries (core): LineLoop is 1:M with StationSeries LineLoopChildLineLoop (core): LineLoop is 1:M with

LineLoopHierarchy LineLoopParentLineLoop (core): LineLoop is 1:M with

LineLoopHierarchy LineLoopOwnerOperator (core): LineLoop is M:N with

OwnerOperator LineLoopProduct (core): LineLoop is M:N with Product LineLoopAudit (core): LineLoop is 1:M with LineLoopAudit

SubTypes: -- The LineLoop object class is designed to store information describing both physical segments of pipe (line loops), and also their logical groupings (pipelines). Line loop records defined on physical segments of pipe are referred to as physical line loops. Line loop records defined on the basis of higher level logical groupings of physical line loops are referred to as logical line loops. (Logical line loops may also be defined by grouping together other, lower level logical line loops.) The LineLoop object class is used in



concert with the LineLoopHierarchy object class to organize pipelines into a pipeline system hierarchy. In the APDM, the pipeline hierarchy may have an arbitrary, unlimited number of levels. (See 10.4.2.8 LineLoopHierarchy for information on pipeline system hierarchies.) The definition of a physical line loop is inherently arbitrary, but most operators understand a line loop to be a continuous, non-branching run of pipe. The APDM follows this convention. To be designated as a physical line loop in the APDM, a physical segment of pipe must be continuous and non-branching. The behavior of APDM reference modes are defined at the level of the physical line loop (for more information, see ReferenceMode). In a transmission system, the most granular physical line loop is simply a continuous run of pipe between facilities (e.g. pumping or compressor stations). Continuous segments of pipe that branch off from the main transmission line loops (e.g. laterals, take offs, interconnects, etc.) are also designated as physical line loops. In a gathering system, well lines, gathering lines and trunk lines are typically designated as individual physical line loops. Most pipeline companies logically group a collection of connected physical line loops (usually with common diameter and other attributes) under a single line name or line number as a pipeline. In the APDM such a grouping corresponds to a logical line loop. In a transmission system, a pipeline implemented as a logical line loop may stretch for tens, hundreds, or even thousands of miles. In a gathering system, logical line loops are usually implemented based on subsets of the gathering system network. For instance, all the well lines feeding into a given trunk line could be grouped under a single logical line loop record.


May 2007 104



The line loops from the two examples shown above are recorded in the LineLoop table as follows (GUIDs are replaced with the integer IDs from the diagrams for clarity):

EventID LineName LineType 1 ACME System Transmission 2 ACME 12” Transmission 3 ACME 10” Transmission 4 10” Lateral Transmission 5 ACME Gathering System Gathering 6 6” Trunk Line Gathering 7 4” Gathering Line Gathering 8 Well #1 Gathering 9 Well #2 Gathering 10 Well #3 Gathering

Note there is no distinction between physical and logical line loop records in the LineLoop table (Although it is possible to add an additional attribute to the LineLoop Object Class to denote this distinction between different LineLoops). The LineLoop object class has a one-to-many relationship with the StationSeries feature class. Each physical LineLoop object may be comprised of one or more connected StationSeries features; logical line loop records should not be related to StationSeries features. The relationship between LineLoop and OwnerOperator is many-to-many and models the percentage ownership/operatorship of each LineLoop in the pipeline system. LineLoop institutes two one-to-many relationships with LineLoopHierarchy, which


May 2007 106

models a hierarchy between parent and children LineLoops. A single line loop may be the parent to one or more child line loops (see 10.4.2.8 LineLoopHierarchy). LineLoop has a many-to-many relationship with Product. A liquids pipeline may carry many products in batches; a single product may be carried by many lines. 10.4.2.8 LineLoopHierarchy Class Name: LineLoopHierarchy Feature Class Geometry:


APDM Inheritance:



ParentLineLoopEventID (String, 38) - Foreign key to a parent LineLoop object.

ChildLineLoopEventID (String, 38) - Foreign key to a child LineLoop object.


LineLoopChildLineLoop (core): LineLoop is 1:M with LineLoopHierarchy

LineLoopParentLineLoop (core): LineLoop is 1:M with LineLoopHierarchy

SubTypes: -- Note that the construction of LineLoop, Activity and SubSystem hierarchies in the model are all identical; the relationship of LineLoop to LineLoopHierarchy is mirrored by the relationship of Activity to ActivityHierarchy and SubSystem to SubSystemHierarchy. The LineLoopHierarchy object class models relationships between parent and child LineLoops and is used to establish a hierarchy of LineLoops. The LineLoop hierarchy groups LineLoops as sets of LineLoops belonging to higher sets of LineLoops. All LineLoops can be grouped under a single or small set of LineLoops, which in effect represents a pipeline or gathering system. Recursion in the line loop hierarchy is unlimited; a given APDM implementation may establish as many line loop hierarchy levels as desired. The line loop hierarchy is facilitated by the two relationship classes that tie LineLoopHierarchy to LineLoop: LineLoopParentLineLoop and LineLoopChildLineLoop. Each record in LineLoopHierarchy stores a parent and child line loop record in the line loop hierarchy. As an illustration, consider a line loop hierarchy derived from the transmission and gathering system examples presented above (see 10.4.2.7 LineLoop). In the transmission system, let the ‘ACME System’ be the parent of the ‘ACME 12”’ and ‘ACME 10”’ pipelines. Let the ‘ACME 10”’ pipeline in turn be a parent of the ‘10” Lateral’ line. In the gathering system, let the ‘ACME Gathering System’ be the parent of the ‘6” Trunk Line’,



which is in turn the parent to the ‘4” Gathering Line’ and the ‘Well #1’ line. Let the ‘4” Gathering Line’ be parent to the ‘Well #2’ and ‘Well #3’ lines. A tree view of the hypothetical line loop hierarchy has the following appearance (the integer line IDs are included in parentheses for clarity):

• (1) ACME System o (2) ACME 12” o (3) ACME 10”

(4) 10” Lateral • (5) ACME Gathering System

o (6) 6” Trunk Line (7) 4” Gathering Line

(9) Well #2 (10) Well #3

(8) Well #1 Note that the line loop hierarchy as presented is completely arbitrary; many other groupings of the example line loops are possible and equally valid. The LineLoopHierarchy table for the hypothetical line loop hierarchy is populated with the following records (GUIDs are replaced with the above integer designations for clarity):

ParentLineLoopEventID ChildLineLoopEventID 1 2 1 3 3 4 5 6 6 7 6 8 7 9 7 10

In the above example all root level entities have children. Note that by convention, root level line loops that have no children do not appear in the LineLoopHierarchy table. This facilitates the following model behavior: if the line loop hierarchy consists of only one level (flat), LineLoopHierarchy need not be populated. The relationships between LineLoop and LineLoopHierarchy facilitate the concept of a single line loop having more than one parent (i.e. a single line loop appears more than once in the ChildLineLoopEventID column of LineLoopHierarchy). This allows a single line loop to appear multiple times in a tree view constructed from the line loop hierarchy. This scenario is useful for representing interconnect lines between two different pipelines. In this case, both connecting pipelines may be considered parents of the interconnect line.


May 2007 108

10.4.2.9 OwnerOperator Class Name: OwnerOperator Feature Class Geometry:


APDM Inheritance:



CompanyEventID (String, 38) – Foreign key to the Company object class.

OwnerPercentage (Long Integer, 9) – (Default = 0) – clOwnershipPercent – Percentage (0–100%) of ownership.

OwnerType (Long Integer, 9) – (Default = 0) – clOwnershipType – Type of participation, e.g. ‘Ownership’, ‘Operator’.


LineLoopOwnerOperator (core): LineLoop is M:N with OwnerOperator

CompanyOwnerOperator (core): Company is 1:M with OwnerOperator

SubTypes: -- The OwnerOperator object class is used to define the percentage ownership and/or operatorship for a LineLoop. The OwnerOperator object class has a many-to-many relationship with LineLoop. One owner can have the same type of participation and percentage in multiple line loops; a single line may have many participants (‘owners’). The OwnerOperator object class has a many-to-one relationship with the Company object class reflecting that one company can have multiple ownership/operatorship percentages (varying by line loop) in a pipeline system. 10.4.2.10 Product Class Name: Product Feature Class Geometry:


APDM Inheritance:



Product (Integer, 3) – clProduct – Product type, e.g. ‘Oil’, ‘Natural Gas’


LineLoopProduct (core): LineLoop is M:N with Product

SubTypes: -- The Product object class is used to store information about the types of products carried in the pipeline. Product participates in a many-to-many relationship with LineLoop.



A single product (such as natural gas can be carried by many lines and conversely a single line can carry many products at the same time but distributed in batches (eg. Highly Volative Liquids or Crude Oil). 10.4.2.11 SubSystem Class Name: LineLoopHierarchy Feature Class Geometry:


APDM Inheritance:



SubSystemName (String, 45) – The name or label that identifies the subsystem.


SubSystemChildSubSystem (core): SubSystem is 1:M with SubSystemHierarchy

SubSystemParentLineLoop (core): SubSystem is 1:M with SubSystemHierarchy

SubSystemRange (core): SubSystem is 1:M with SubSystemRange SubSystemSite (core): SubSystem is M:N with Site SubSystemAudit (core): SubSystem is 1:M with SubSystemAudit SubSystemContact: SubSystem is M:N with Contact

SubTypes: -- The SubSystem object class is used to categorize, organize, and group pipeline segments into logical groupings that may cut across line loops and station series. A subsystem can be defined to represent virtually any grouping of pipe segments for business purposes. A common use of SubSystem is to define organizational boundaries (e.g., divisions, districts, and operating areas). Another common use is to record administrative boundaries such as taxing districts. The SubSystem object class is used in concert with the SubSystemHierarchy object class to organize subsystems into a hierarchy. A subsystem hierarchy may have an arbitrary, unlimited number of levels. Different types of subsystem hierarchies can exist side by side within the SubSystem and SubSystemHierarchy object classes. (See 10.4.2.12 SubSystemHierarchy for information on defining subsystem hierarchies.) As is the case with line loops, SubSystem records can be classified as representing either physical or logical subsystems. A physical subsystem corresponds directly to a collection of physical pipeline segments (as defined by one or more 10.4.3.4 SubSystemRange features). These pipe segments may cross line loop and station series boundaries. Unlike a physical line loop, a physical subsystem need not be continuous, and may branch. A logical subsystem is a grouping of physical subsystems and/or lower level logical


May 2007 110

subsystems. As is the case with LineLoop, there is no distinction between physical and logical subsystem records in the SubSystem table.



The subsystems from the two examples illustrated above are recorded in the SubSystem table as follows (GUIDs are replaced with the integer IDs from the diagrams for clarity):

EventID SubSystemName 1 Operating Divisions 2 Western Division 3 Eastern Division 4 District 1 5 District 2 6 District 3 7 District 4 8 Tax Authorities 9 Washington County 10 Jefferson County


May 2007 112

SubSystem implements two one-to-many relationships with SubSystemHierarchy, modeling a hierarchy of parent and child subsystems. A single subsystem may be the parent to many child subsystems. SubSystem participates in a one-to-many relationship with SubSystemRange; a physical subsystem is comprised of one or more SubSystemRange features. SubSystem participates in a many-to-many relationship with Site. A SubSystem may encompass multiple sites; a site may be associated with multiple subsystems. SubSystem implements a one-to-many relationship with SubSystemAudit; this relationship ties SubSystem to both Activity and ExternalDocument. Through SubSystemAudit records a subsystem may be associated with multiple activities and/or documents, and vice versa. SubSystem implements a many-to-many relationship with Contact. Multiple contacts may be defined for a subsystem; a single contact may serve multiple subsystems. Optionally, an implementation may institute relationships between one or more polygon feature classes and the SubSystem object class. Polygons in such related feature classes represent the spatial extents of corresponding subsystems. 10.4.2.12 SubSystemHierarchy Class Name: SubSystemHierarchy Feature Class Geometry:


APDM Inheritance:



ParentSubSystemEventID (String, 38) - Foreign key to a parent SubSystem object.

ChildSubSystemEventID (String, 38) - Foreign key to a child SubSystem object.


SubSystemChildSubSystem (core): SubSystem is 1:M with SubSystemHierarchy

SubSystemParentLineLoop (core): SubSystem is 1:M with SubSystemHierarchy

SubTypes: -- Note that the construction of SubSystem, Activity and LineLoop hierarchies in the model are all identical; the relationship of SubSystem to SubSystemHierarchy is mirrored by the relationship of Activity to ActivityHierarchy and LineLoop to LineLoopHierarchy. The SubSystemHierarchy object class models the hierarchy between different subsystem features in the model. It is common to have organizational groupings or areas contain sub areas that, in turn, could contain other sub areas. The SubSystemHierarchy object class has two one-to-many relationships with the SubSystem object class modeling parent to child relationships between subsystem objects.



The SubSystemHierarchy object class models relationships between parent and child subsystems and is used to establish a hierarchy of subsystems. The subsystem hierarchy groups subsystems as sets of subsystems belonging to higher level subsystems. All subsystems can be grouped under a single or small set of subsystems. Multiple, independent subsystem hierarchies can be established to model different types of business-related pipeline groupings, e.g. operating districts, emergency response areas, tax authorities, etc. Recursion in the subsystem hierarchies is unlimited; a given APDM implementation may establish as many subsystem hierarchy levels as desired. The subsystem hierarchy is facilitated by the two relationship classes that tie SubSystemHierarchy to SubSystem: 1) SubSystemParentSubSystem and 2) SubSystemChildSubSystem. Each record in SubSystemHierarchy stores a parent and child subsystem record in the subsystem hierarchy. As an illustration, consider a subsystem hierarchy derived from the operational and tax district examples presented above (see 10.4.2.11 SubSystem). In the operational subsystem, let ‘Operating Divisions’ be the parent of the ‘Western Division’ and ‘Eastern Division’ subsystems. Let the ‘Western Division’ subsystem in turn be the parent of the ‘District 1’ and ‘District 2’ subsystems. Let the ‘Eastern Division’ subsystem be the parent of the ‘District 3’ and ‘District 4’ subsystems. In the tax district subsystem, let the ‘Tax Authorities’ subsystem be the parent of the ‘Washington County’ and ‘Jefferson County’ subsystems. A tree view of the hypothetical subsystem hierarchy has the following appearance (the integer subsystem IDs are included in parentheses for clarity):

• Operating Divisions o (2) Western Division

(4) District 1 (5) District 2

• (3) Eastern Division (6) District 3 (7) District 4

• (8) Tax Authorities o (9) Washington County o (10) Jefferson County

Note that the example subsystem hierarchy actually consists of two independent subsystem hierarchies, one for operating units and one for tax authorities. The SubSystemHierarchy table for the hypothetical subsystem hierarchy is populated with the following records (GUIDs are replaced with the above integer designations for clarity):


May 2007 114

ParentSubSystemEventID ChildSubSystemEventID

1 2 1 3 2 4 2 5 3 6 3 7 8 9 8 10

In the above example all root level entities have children. Note that by convention, root level subsystems that have no children do not appear in the SubSystemHierarchy table. This facilitates the following model behavior: if the subsystem hierarchy consists of only one level (flat), SubSystemHierarchy need not be populated. 10.4.3 Core Feature Classes 10.4.3.1 ControlPoint Class Name: ControlPoint Feature Class Geometry:

Implemented as an M-Aware (and optionally Z-Aware) Point Feature class.

APDM Inheritance:

ESRI Feature FeatureArchive CenterlinePoint (Ancestors – Abstract)


ControlPointAngle (Double, 15, 2) – The magnitude of direction angle marking the change in vector direction (deflection) of the centerline from one control point to the next (e.g., 45° left deflection).

ControlPointType (Integer, 3) – clControlPointType – The type of control point (e.g., point of inflection, monument, line crossing.

PIDirection (Integer, 3) – clControlPointDirection – The direction of the centerline deflection at the control point relative to the vector of the last centerline segment of which the control point is the endpoint (e.g., ‘R’ for right, ‘L’ for left, ‘None’).

StationValue (Double, 15, 2) – The known station value (measure) along a station series at the control point location.

SubTypeCD (Integer, 3) – The subtype, or reference mode (measurement system) of the control point.


StationSeriesControlPoint (core): StationSeries is 1:M with ControlPoint

ReferenceModeControlPoint (core): ReferenceMode is 1:M with ControlPoint

ControlPointAudit (core): ControlPoint is 1:M with ControlPointAudit



ControlPointGeoMetaData: StationSeries is M:N with GeoMetaData

SubTypes: 1 = Continuous 2 = Engineering 3 = Horizontal 4 = Mile Post 5 = Slack Chain 6 = Valve Section 7 = Unspecified

The ControlPoint feature class lies at the heart of the APDM. The ControlPoint feature class stores points of known x,y position and known station value (measure) along the pipeline centerline. Control point features define the pipeline centerline. The ControlPoint feature class has a many-to-one relationship with the StationSeries feature class. Within a given reference mode (subtype), each station series feature is composed of two or more control point features of the same reference mode. Each control point corresponds to a vertex (including the endpoints) of an associated station series feature. The station (or measure) value stored with the control point feature defines the M value of the vertex at the same location in the associated station series feature. The subtypes of the ControlPoint feature class represent the different types of linear referencing measurement systems (reference modes) that are used for stationing along the pipeline centerline. By convention, each control point location must be occupied by at least one control point feature for each reference mode present in the model. (In the case of station series endpoints on connected station series, a control point location is occupied by two control points of the same reference mode.) The reason for this convention is that different reference modes may not share a common physical basis for the system of measurement (see ReferenceMode). During some centerline edit operations (for instance, reroutes), spatial integrity between the different reference modes can only be maintained if the measure value is known in all reference modes at each control point location. The APDM requires that one subtype be defined as the primary reference mode (default measurement system) for the pipeline centerline. Other control point subtypes, or measurement systems, present in the model are considered secondary measurement systems. All secondary measurement systems must be geometrically coincident and geometrically constrained to the primary measurement system control points and station series features. Representations for all control point (and station series) features must be present in all reference modes. The default measurement system (or subtype) becomes the stationing method applied to all online features; online features are stored only in the primary reference mode. The ControlPoint feature class has a many-to-many relationship with GeoMetaData. This relationship models the provenance of the location information for the control point feature. GeoMetaData stores original coordinate information and metadata describing


May 2007 116

how the control point feature was initially obtained in the field. A control point may have more than one GeoMetaData record (i.e. it was surveyed by more than one method); a single GeoMetaData record applies to all the control points at a control point location (one or two for each reference mode). ControlPoint implements a one-to-many relationship with ControlPointAudit; this relationship ties ControlPoint to both Activity and ExternalDocument. Through ControlPointAudit records a control point may be associated with multiple activities and/or documents, and vice versa. 10.4.3.2 Site Class Name: Site Feature Class Geometry:

Implemented as a Polygon Feature class.

APDM Inheritance:

ESRI Feature FeatureArchive OfflineFacility (Ancestors – Abstract)


SiteName (String, 45) – The name of the site. SiteType (Long Integer, 9) – opSiteType – (Default = 0) –The type

of site contained within the boundary (e.g., meter station, compressor station)


SiteAudit (core): Site is 1:M with SiteAudit Site<Online or Offline Facility classname> (core relationship type):

Site is 1:0..M with < Online or Offline Facility classname> SubSystemSite (core): SubSystem is M:N with Site SiteContact: Site is M:N with Contact

SubTypes: -- The Site feature class is designed to store the polygonal boundaries of the various stations and other properties housing facilities owned by a pipeline company. Site features might be used to define the boundaries of properties, easements, temporary work areas, and large pipeline complexes such as meter stations, compressor stations, refineries, custody transfer stations, and valve stations. Site features may also be used to demarcate the limit of stationed pipes and non-stationed pipes. Site implements an optional one-to-many relationship with all online and offline facility feature classes. This core relationship type allows facility features to be associated with a site as desired. It may not always be possible to associate online facilities features with a station series feature, or provide such features with a shape. This may occur when facilities equipment at a site is known only through a site equipment manifest. In this situation, the pieces of equipment may still be stored in the APDM and can be tracked by their relationship to a site. Site implements a one-to-many relationship with SiteAudit; this relationship ties Site to both Activity and ExternalDocument. Through SiteAudit records, a site may be associated with multiple activities and/or documents and vice versa.



10.4.3.3 StationSeries Class Name: StationSeries Feature Class Geometry:

Implemented as an M-Aware (and optionally Z-Aware) Polyline Feature class.

APDM Inheritance:

ESRI Feature FeatureArchive CenterlinePoint (Ancestors – Abstract)


SeriesName (String, 45) – An operational label or name applied to the station series feature for query and labeling purposes.

SeriesOrder (Long Integer, 9) – An arbitrary number used to order station series features for querying and connectivity purposes.

BeginStation (Double, 15, 2) – The station value assigned to the start of the station series feature.

EndStation (Double, 15, 2) – The station value assigned to the end of the station series feature.

FromSeriesEventID (String, 38) – A foreign key pointing to the EventID of the StationSeries feature connected to the ‘starting’ end of the current StationSeries feature.

FromConnectionStationValue (Double, 15, 2) – The station value on the station series at which the ‘From’ station series connects.

ToSeriesEventID (String, 38) – A foreign key pointing to the EventID of the StationSeries feature connected to the ‘ending’ end of the current StationSeries feature.

ToConnectionStationValue (Double, 15, 2) – The station value on the station series at which the ‘To’ station series connects.

LineLoopEventID (String, 38) – The foreign key to a record in the LineLoop class. Each StationSeries feature must be associated with a LineLoop object. As a best practice, a set of StationSeries features associated with a particular LineLoop should be physically connected to each other.

SubTypeCD (Long Integer, 9) – The subtype of the station series defining the system of linear referencing or stationing.


StationSeriesControlPoint (core): StationSeries is 1:M with ControlPoint

LineLoopStationSeries (core): LineLoop is 1:M with StationSeries StationSeries<Online Feature class name>: StationSeries is 1:M

with <Online Feature class name> BeginStationSeriesAltRefMeas (core): StationSeries is 1:M with

AltRefMeasure EndStationSeriesAltRefMeas (core): StationSeries is 1:M with

AltRefMeasure ReferenceModeStationSeries (core): ReferenceMode is 1:M with

StationSeries StationSeriesAudit (core): StationSeries is 1:M with


May 2007 118

StationSeriesAudit SubTypes: 1 = Continuous

2 = Engineering 3 = Horizontal 4 = Mile Post 5 = Slack Chain 6 = Valve Section 7 = Unspecified

The StationSeries feature class stores the routes that comprise the pipeline centerline. All online features in the APDM are referenced against primary reference mode station series features. Each station series feature is an ESRI Route with an assigned begin and end measure (or station) value. Each vertex in the station series feature has a measure (or station) value assigned to it. Point and linear events are located along the station series route by assigning the Route-ID (StationSeriesEventID) and a measure value as attributes of the feature (linear events require both begin and end measure values). Linear events must start and end on the same station series (route). The FromSeriesEventID, FromConnectionStationValue, ToSeriesEventID, and ToConnectionStationValue attributes model station series connectivity in the pipeline system. Usually, the From- and ToConnectionStationValue entries reference the first and last (Begin- and EndStation) station values in the station series feature. In some implementations, however, this may not be the case. Consider the case where pig launchers and receivers are modeled as online features. In this situation, the From- and ToConnectionStationValue entries may not occur at station series ends. Because the APDM does not allow line loops to branch, whenever From- and ToConnectionStationValue entries do not occur at the ends of the station series feature, the connecting station series feature(s) must be placed on separate line loops. The APDM implements a one-to-many relationship between the StationSeries feature class and each referenced online feature class; this relationship type is core to the model. Each online feature is referenced to a station series feature; the location and measure (station) values of online features are defined and constrained by their underlying related station series feature. The StationSeries feature class also has a one-to-many relationship with the ControlPoint feature class. This relationship embodies the concept that a station series is comprised of two or more control points, with each related control point corresponding to a vertex in the station series feature. StationSeries implements a many-to-one relationship with LineLoop; each physical line loop is comprised of one or more connected station series features (for uninterrupted reference modes, each physical line loop is comprised of a single station series feature). StationSeries implements two one-to-many relationships with AltRefMeasure; each BeginStation and EndStation value in AltRefMeasure is tied to the associated station series feature. StationSeries implements a one-to-many relationship with StationSeriesAudit; this relationship ties StationSeries to



both Activity and ExternalDocument. Through StationSeriesAudit records, a station series may be associated with multiple activities and/or documents and vice versa. The StationSeries feature class has the same subtypes as the ControlPoint feature class: continuous, engineering, horizontal, milepost, slack chain, valve section, and unspecified. The APDM requires that one subtype be chosen as the primary stationing or referencing method (the default subtype). Engineering stationing is the reference mode most commonly recognized by pipeline operators. Engineering stationing is usually implemented with the ‘Interrupted and Not Adjustable’ reference mode type and the ‘3D Slack Chain’ reference mode basis. In Engineering Stationing, station series features are bounded by ‘station equations’ representing the discontinuity in stationing from one Engineering station series to the next. (Note that station equations are not explicitly modeled in the APDM.) Continuous stationing is usually implemented with the ‘Uninterrupted and Adjustable’ reference mode type and the ‘3D Slack Chain’ reference mode basis. Using this definition, Continuous stationing is simply Engineering stationing with station equation discontinuities removed. Conceptually, Continuous station corresponds to Measure in PODS, or NET stationing in ISAT. In the geodatabase, Continuous stationing allows for the creation of linear event features that are not artificially split at station equations (unlike Engineering linear event features, which are split at station equations). Most APDM implementations use either Continuous or Engineering as the primary reference mode. The Unspecified reference mode allows some flexibility for importing control points that have no assigned or calculated stationing, which may be the case for preliminary pipeline routing, new construction, or proposed pipeline reroutes. Unspecified may not serve as the primary reference mode. By accommodating many different methods of stationing, the APDM remains very flexible and open to the varying needs of many pipeline companies importing data from other pipeline models. The position of events and features on or along the centerline can be easily determined by matching the position of these features along station series storing different station values. Core ESRI geodatabase tools allow for simple comparison and calibration of different reference systems' station values. The primary stationing method is the ultimate arbitrator of an event's position on or along the pipeline centerline. 10.4.3.4 SubSystemRange Class Name: SubSystemRange Feature Class Geometry:

Implemented as an M-Aware (and optionally Z-Aware) Polyline Feature class.

APDM Inheritance:

ESRI Feature FeatureArchive CenterlinePolylineEvent (Ancestors – Abstract)

Attributes: SubSystemEventID (String, 38) - Foreign key to a SubSystem


May 2007 120

(name, type, length, precision, scale, domained, notes)

object.


SubSystemRange (core): SubSystem is 1:M with SubSystemRange StationSeriesSubSystemRange (core): StationSeries is 1:M with

SubSystemRange SubSystemRangeAltRefMeasure (core): SubSystemRange is M:N

with AltRefMeasure SubTypes: -- SubSystemRange stores the actual physical extent of a subsystem as one or more online polyline event features. Building on the example used in 10.4.2.11 SubSystem, each station series segment in a subsystem corresponds to a SubSystemRange feature:

The SubSystemRange features from the two examples are recorded in the SubSystemRange feature table as follows (GUIDs are replaced with the integer IDs from the diagrams for clarity). SubSystemRange implements a many-to-one relationship with SubSystem; each subsystem is comprised of one or more SubSystemRange feature. SubSystemRange implements a many-to-one relationship with StationSeries; the location and station values for each SubSystemRange feature are constrained by the associated station series. SubSystemRange implements a many-to-many relationship with AltRefMeasure. Each SubSystemRange feature has one AltRefMeasure record for each reference mode; several SubSystemRange features representing one SubSystemRange event that has been artificially split due to the use of an interrupted primary reference mode will have one AltRefMeasure record.

EventID SubSystemEventID (Name) 1 4 (District 1) 2 4 (District 1) 3 5 (District 2) 4 5 (District 2) 5 6 (District 3) 6 6 (District 3) 7 6 (District 3) 8 7 (District 4) 9 7 (District 4) 10 7 (District 4) 11 9 (Washington County) 12 9 (Washington County) 13 9 (Washington County) 14 9 (Washington County) 15 9 (Washington County) 16 10 (Jefferson County) 17 10 (Jefferson County) 18 10 (Jefferson County)



10.5 APDM Core Domains All domains in the APDM model use a long integer numeric value for the code. Each code corresponds to a textual description of the coded value. There are two codes and descriptions that are common to most domains, -1 and 0. The –1 code value is described as ‘Unknown (Verified)’ meaning the attribute value is unknown and this fact has been verified against source material, other existing data sources, and/or field survey. The 0 code is described as ‘Unknown’ and is the standard default value for most domains in the model. A value of 0 within a coded value domain indicates that the user does not know the contents of the attribute and this has not been verified by research or investigation. Some long integer domains incorporate a logical structure to the numeric values in the domain. Increasing domain values are used to indicate less restrictive behavior. The following domains incorporate this logic:

• gnOperationalStatus • gnStatus • clStationEditResponse • clXYEditResponse • clZEditResponse

There are a number of reasons numeric values are used for domain codes. One reason is that behavior domains have been defined such that as the code value increases from 1, the level of behavior restriction decreases. This rule applies to numbers greater than 0.

Code Brief Description -1 Unknown (Verified) 0 Unknown Default


May 2007 122

10.5.1 Required Domains The following is a listing of the domains that are considered core to the APDM. These domains are used to populate attributes in the APDM abstract classes, which are used to explicitly define behavior in the APDM. Core domains must be implemented exactly as defined using the values and descriptions described below to maintain APDM compliance. Core domains may be expanded with additional values, but the user should be aware that this may cause interoperability issues. 10.5.1.1 gnOperationalStatus Indicates the status of a feature that has some operational lifespan based on FERC/OPS definitions. OperationalStatus is applied to centerline and facility features with complex operational life spans. The gnOperationalStatus domain is a coded value domain containing the following long integer values:

=1 = Unknown (Verified) 0 = Unknown Default 1 = Conceptual 2 = Proposed 4 = Active 8 = Inactive 16 = Idle 32 = Abandoned 64 = Removed

10.5.1.2 gnStatus Status is used to describe the state of a non-facility or centerline object (i.e. an object that has no operational significance or does not typically exist as a geographical or physical entity). The gnStatus domain is a coded value domain containing the following long integer values:

-1 = Unknown (Verified) 0 = Unknown Default 1 = Conceptual 2 = Proposed 4 = Active 8 = Inactive



10.5.1.3 clStationEditResponse Describes how the station values for the control point may be altered. The clStationEditResponse domain is a coded value domain containing the following long integer values:

-1 = Unknown (Verified) 0 = Unknown Default 1 = Assigned 2 = Offset Downstream 3 = Offset Upstream 4 = Interpolated 5 = Fixed

10.5.1.4 clXYEditResponse Indicates how the x,y portion of the geometry of a control point feature responds to a centerline edit such as a reroute. The clXYEditResponse domain is a coded value domain containing the following long integer values:

-1 = Unknown (Verified) 0 = Unknown Default 1 = Assigned 2 = Fixed Distance 3 = Fixed Deflection 4 = Fixed Inline 5 = Fixed Geometry 6 = Fixed

10.5.1.5 clZEditResponse Indicates how the Z portion of the geometry of a control point feature responds to a centerline edit such as a reroute. The clZEditResponse domain is a coded value domain containing the following long integer values:

-1 = Unknown (Verified) 0 = Unknown Default 1 = Not Applicable 2 = Assigned 3 = Derived 4 = Interpolated 5 = Fixed


May 2007 124

10.5.1.6 gnOnlineLocationMechanism Describes the various spatial operations used to generate online location features of offline or online features. The gnOnlineLocationMechanism domain is a coded value domain containing the following long integer values:

-1 = Unknown (Verified) 0 = Unknown Default 1 = ClosestPoint 2 = DistanceAzimuth 3 = BufferIntersection 4 = PolygonIntersection 5 = PointIntersection 6 =- PolylineEasement 7 =- PointEasement 8 = PolylineEndpoint 9 = PolylineCenterpoint 10 = AggregatePoint 11 = AggregatePolyline

10.5.1.7 gnHistoricalState Describes the current representation of an online feature as a means of differentiating from previous historical feature representations. The gnHistoricalState domain is a coded value domain containing the following long integer values:

-1 = Unknown (Verified) 0 = Unknown Default 1 = Current 2 = Historical

10.5.1.8 gnAngle A rotation angle from 0–360o for a point symbol. This allows operators to preserve rotation information for point symbols imported from external systems such as CAD. Allows all point symbols within the APDM to be rotated as needed; manually, or in relation to other features. This is used primarily for display in mapping applications such as alignment sheets. The gnAngle domain is a range value domain containing the following double values:

MinValue = 0.00 Default MaxValue = 360.00



10.5.1.9 clEditResponse Indicates how the geometry and/or stationing attributes of an online feature responds to a centerline edit such as a reroute. The clEditResponse domain is a coded value domain containing the following long integer values:

-1 = Unknown (Verified) 0 = Unknown Default 1 = Relative 2 = Proportional 3 = Absolute

10.5.1.10 gnAPDMClassType Lists the different types of APDM abstract classes. Used to define the immediate parent abstract class from which an object or feature class inherits behavior. The gnAPDMClassType domain is a coded value domain containing the following long integer values:

-1 = Unknown (Verified) 0 = Unknown Default 1 = APDMObject 2 = CenterlineObject 3 = FacilityObject 4 = NonFacilityObject 5 = CenterlinePolyline 6 = CenterlinePolylineEvent 7 = CenterlinePoint 8 = OfflineFeature 9 = OfflinePoint 10 = OfflineFacility 11 = OfflinePointFacility 12 = OfflineNonPointFacility 13 = OnlineFeature 14 = OnlinePolyline 15 = OnlinePolylineForOfflineFeature 16 = OnlinePoint 17 = OnlinePointForOfflineFeature 18 = OnlineFacility 19 = OnlinePolylineFacility 20 = OnlinePointFacility 21 = Fitting 22 = Audit


May 2007 126

10.5.1.11 gnRefModeBasis Describes the basis for determining the origin of distance measurements for a particular stationing method. The gnRefModeBasis domain is a coded value domain containing the following long integer values:

-1 = Unknown (Verified) 0 = Unknown Default 1 = Arbitrary 2 = 3D Projected 3 = 3D Slack Chain 4 = 3D Geoid 5 = 2D Projected

10.5.1.12 gnRefModeType Describes the basis for determining how the stationing values within a LineLoop react in the event of an upstream centerline reroute. The gnRefModeType domain is a coded value domain containing the following long integer values:

-1 = Unknown (Verified) 0 = Unknown Default 1 = Uninterrupted and Adjustable 2 = Uninterrupted and Not Adjustable 3 = Interrupted and Adjustable 4 = Interrupted and Not Adjustable

10.5.1.13 gnRefModeUnits Describes the possible units used for stationing values for a particular reference mode. This gnRefModeUnits domain is a coded value domain containing the following long integer values:

-1 = Unknown (Verified) 0 = Unknown Default 9001 = esriSRUnit_Meter 9002 = esriSRUnit_Foot 9003 = esriSRUnit_SurveyFoot 9030 = esriSRUnit_NauticalMile 9033 = esriSRUnit_SurveyChain 9034 = esriSRUnit_SurveyLink 9035 = esriSRUnit_SurveyMile 9036 = esriSRUnit_Kilometer



10.5.1.14 gnYesNo A domain used to depict a yes or no value while accounting for the possibility of unknown values. This gnYesNo domain is a coded value domain containing the following long integer values:

-1 = Unknown (Verified) 0 = Unknown Default 1 = Yes 2 = No

10.5.1.15 gnRequiresGeometry A domain used to indicate if the rows in a feature class can allow the SHAPE column to contain a null value. This gnRequiresGeometry domain is a coded value domain containing the following long integer values:

-1 = Unknown (Verified) 0 = Unknown Default 1 = Must Have 2 = Must Not Have 3 = Optional

The following domains are applied to attributes of the APDM Fitting abstract class. To conserve space within the whitepaper document and because many of the actual domain values can vary between implementations, the contents of these domains are not listed here. However these domains are considered core parts of the APDM and must be implemented using the default values for ‘Unknown (Verified)’ and ‘Unknown’.

• fcFittingGrade • fcConnectionType • fcDiameter • fcWallThickness • fcFittingManufacturer • fcMaterial • fcPressureRating • fcSpecification

10.5.2 APDM Compliance The APDM is designed as a template that can be expanded or modified to meet the specific requirements of any given pipeline organization. Although the APDM is designed with customization in mind, it is important to recognize that there are elements (classes, attributes and relationships between classes) within the object model that are considered core and must be implemented as specified. In addition, modifications to the APDM must be made within the context of the APDM abstract class definitions (i.e. any


May 2007 128

custom class added to the model in a particular implementation must inherit from one of the APDM abstract classes). Correct implementation of the APDM core elements and abstract classes is the benchmark for APDM compliance. The goal of APDM compliance is to define a common data model framework that facilitates consensus and interaction between various pipeline interests, and yet allows wide latitude for data model modification, innovation and experimentation. Achieving such a broad goal requires a nontraditional approach to compliance. Traditional RDBMS data model compliance is achieved through absolute conformance to the tabular structure of a predefined database construct. APDM compliance is primarily concerned with the behavioral aspects of the data construct. APDM compliance minimizes strict structural conformance to a relatively small base set of fundamental features referred to as the Core APDM. APDM compliance is understood to be the following:

• All object and feature classes within the model must implement (and therefore inherit) from one of the APDM abstract classes.

• Some APDM abstract classes define associated relationship types; all object and

feature classes inheriting from such an abstract class must also implement the inherited relationship types.

• Core APDM Feature and Object Classes (their attributes and the relationships

between them and other classes) must be retained and implemented precisely as specified.

• Class names of Core APDM Feature and Object Classes must be implemented

precisely as specified. • Attributes inherited from APDM Abstract Classes must be implemented precisely

as specified. • Standard APDM domains (including the default –1 = Unknown (Verified) and 0 =

Unknown (Default Value) must be implemented precisely as specified. • Relationships (including relationship names, origin and destination classes,

optionality and cardinality) must be implemented precisely as specified. Core APDM features and objects and their attribute names must be retained precisely for APDM compliance. The inclusion of additional attribution or domain values into the Core APDM is acceptable (and expected; defined attribution for the core classes is minimal).



Behavioral rules are established in the Core APDM and abstract classes. These rules are extended to the larger model template via the concept of inheritance. Behavioral compliance is based upon the adherence to abstract class definitions including abstract class attribution and relationship class behavior. The abstract classes define rules for what constitutes online and offline point, line, and polygon features as well as the online locations for offline features. The APDM abstract classes define compliance within the semantic context of a behavioral construct. This construct provides the necessary organizational framework to permit virtually limitless flexibility and expansion of the model to suit the individual needs of operators, while maintaining the required commonalities to facilitate software interoperability within the user community. APDM compliance is intended to promote interoperability through the enforcement of standardized object behavior. APDM compliance is not intended to be a measuring stick used to enforce standard data model content. Rather, APDM compliance is intended to aid in the definition and understanding of object behaviors that occur during loading, editing and archiving operations. This is particularly true for editing operations that are peculiar to the pipeline industry including, for example, pipeline reroutes and centerline modifications. APDM compliance allows a flexible implementation of feature and object classes to meet the specific business requirements of any pipeline operator. 10.5.3 Non Geometric Features APDM 4.0 supports the concept of 'non-geometric' facility features. This behavior can apply to any feature class that inherits from the ‘OfflineNonPointFacility’, ‘OfflinePointFacility’ or ‘OnlineFacility’ APDM Abstract Classes. This mechanism removes the need to represent geometric features and non-geometric objects as separate classes sharing identical attributes, subtypes and domains. A feature class implementing the ‘non-geometric’ behavior has a foreign key attribute relating the feature class to the ‘Site’ APDM Core feature class. By relating a feature to a Site, the feature may exist without geometry but is now ‘contained’ within the Site and can be located via the hierarchy (e.g. sites are related to SubSystems and SubSystems are related to SubSystemRanges, which in turn are related to StationSeries and LineLoops and so on). A manifest or listing of features ‘contained’ within a Site is obtained by searching the relationship classes from Site to any class implementing a ‘facility’ parent abstract class. This mechanism has additional implications for feature classes inheriting from the ‘OnlineFacility’ APDM Abstract Class. Online features must have geometry that is derived from an underlying PRM station series; however, using the ‘SiteEventID’ mechanism allows online features to be stored without requiring an underlying station series. A combination of values from SiteEventID, StationSeriesEventID, and Begin/End Station Value determines whether geometry is created for the feature. The chart below explains the various combinations of how these attributes can be used to define and store features contained within a Site.


May 2007 130

APDM Abstract Class

SiteEventID

(fk)* StationSeriesEID Station Value Geometry

OnlineFacility [Optional] Has value Has value Is created The feature has a shape geometry and is located on a station series via a station value (or values). It may also be located in or associated with a Site. If the feature has a SiteEventID value, then it is assumed that the underlying PRM StationSeries is located in the Site as well. This row denotes the default ‘Online’ feature behavior.

OnlineFacility Has value Does not have value

Does not have value Is not created

The feature is located in or associated with a Site. The exact spatial location of the feature is unknown. No shape geometry is generated, nor does the online feature have a reference to a StationSeries.

OnlineFacility Has value Has value Does not have value Is not created

The feature is located in or associated with a Site. The exact location of the feature is unknown, but it is known to exist on a particular line (StationSeries) within the Site. No shape geometry is generated, but the feature can be located in the LineLoop hierarchy via its reference to the associated StationSeries.

OnlineFacility Has value Does not have value

Does not have value Is created

The feature is located in or associated with a Site. The exact spatial location of the feature is known, so shape geometry is generated. However, the relationship of the online feature to any particular StationSeries is unknown. OfflinePointFacility OfflineNonPointFacility

Does not have value -- -- Is created

The feature has a shape geometry and has no relation to a Site. The feature may lie within a Site boundary, but if it does not have a relate item in the ‘SiteEventID’ column then the feature is not referenced to a Site. This row denotes the default ‘Offline’ feature behavior. OfflinePointFacility OfflineNonPointFacility Has value -- -- Is created

The feature is located in or associated with a Site and has a shape geometry. The feature is tied to the hierarchy via the Site. The feature could exist outside the actual Site boundary and still be related to the Site. OfflinePointFacility OfflineNonPointFacility Has value -- -- Is not created

The feature is located in or associated with a Site, but its exact location is unknown. The feature does not have any shape geometry. Associating facilities features with Sites and allowing storage of features without geometry, provides numerous possibilities for managing facilities within the APDM. Using the chart above, various scenarios for modeling facilities within a Site are available. For example, many companies do not fully model the ‘plumbing’ within a Site; often the centerline (StationSeries features) stops at the border of a site and does not traverse the site. However, many active features may be known to exist within the site (e.g. via a facility equipment manifest). These features can be represented in the APDM as features with null shapes that reference the Site. Alternatively, sometimes companies map the station series and facilities within a site using a ‘false’ un-connected station series. The station series and the site are then used to locate the “in-site” features, but those features are not located via stationing on the ‘false’ station series. The features are represented in the APDM with null shapes, but are referenced to both the site and the ‘false’ station series. As a result, some companies accurately map the station series within a site, but still do not know the locations of all site facilities on the site station series.



Again, these features are represented in the APDM with null shapes, but are referenced to both the site and the site station series. The following two explicit examples depict how Sites can be used to track facilities:

• Uninstalled stockpiles of pipe are stored within a site. These pipe stock piles employ the same attributes as in-service pipes, including MillTestPressure and HeatNumbers. They can be tracked for inventory purposes by storing them as PipeSegment features without shapes, but with a reference to the site.

• A company may be responsible for operating meter stations (together with other

associated features such as instruments, valves etc.) located off the main line (from 100ft to 1-2 miles). Tracking the information (inspection and reading activities, history, audit trail etc.) about these offline meter stations (sites) is required. Again, facilities and equipment in these offline meter stations may be managed by storing them as null-shape features in the APDM incorporating a reference to the site.

In both of these examples, no station series or line loop traverses the site locations. In APDM 3.0, it is impossible to store such features without creating new non-stationed object classes corresponding to the stationed online feature classes. In APDM 4.0, adding the SiteEventID to facilities classes inheriting from the ‘OnlineFacility’ APDM Abstract Class creates several data management and display options:

• If an online facilities feature has a StationSeriesEventID, station value(s) and SiteEventID value, then the feature shows up in ArcMap as a geometric feature within or associated with the site.

• If an online facilities feature has a StationSeriesEventID and SiteEventID value,

but no station value, it has no geometry and thus does not display directly in ArcMap. However, the feature is still a child of the station series and is displayed in the feature attribute table, or by traversing the station series’ or site’s relationship classes using the Identify tool.

• If an online facilities feature has a SiteEventID only (and no geometry), it is thus

associated with the site as a non-geometric feature. It is not slaved directly to the pipeline centerline (and hierarchy) by virtue of not having a StationSeriesEventID, but is nonetheless associated with the site. The feature does not display directly in ArcMap, but is displayed in the feature attribute table, or by traversing the site’s relationship classes using the Identify tool.

• If an online facilities feature has a SiteEventID and a geometry, but no

StationSeriesEventID, it is thus associated with the site as a geometric feature. It is not slaved directly to the pipeline centerline (and hierarchy) by virtue of not


May 2007 132

having a StationSeriesEventID, but is associated with the site. The feature displays directly in ArcMap.

With respect to bullet 4 above, note that ‘online’ facility features can be digitized within a site boundary (such as a compressor station) without any relationship to a station series. If the feature has a geometry and a SiteEventID value, but no StationSeriesEventID or station value, it in effect acts as a ‘NonStationed’ facilities feature. This construct is valid in APDM 4.0. For this reason the ‘NonStationedPipe’ feature class has been deprecated from APDM 3.0. One other benefit to tracking facility features in this manner is that it allows for flexible integration with external asset management systems. Examples of the various situations where non-geometric features are viable are displayed in the following diagrams:


May 2007 134

10.5.4 Topology The APDM is designed to incorporate topology rather than the geometric network to ensure data quality and to maintain relationships between features of different feature classes. A complete discussion of topology and the geometric network is provided under Implementation Issues. Topology requires that all feature classes that participate with the topology be present in the same feature dataset. The centerline feature classes– Control Points and Station Series– are the core of the topology. Therefore, all referenced feature classes must participate in the topology as well. The APDM stores all feature classes in the model in the Transmission feature dataset. 10.5.5 Centerline This section outlines some of the rules or assumptions about the APDM centerline features.

• Control points represent the vertices of station series linear features. • A station series must be composed of a minimum of two control points (one at the

beginning and one at the end of the station series).



• Control points and the vertices of station series features share the same measure

values (if the control point and the station series features share the same subtype value).

• As vertices of a station series, control points represent distinct and known values

of stationing along a station series. All other stationing values in between control points are interpolated.

• Both station series and control points must have the same subtypes.

• No control point can be related to a station series of a different subtype.

• The default subtype for control points and station series must be the same. • Each default subtype station series must have a control point at every vertex with

a valid station value. • Station series are M-Aware simple (non-multipart) polyline features. • Station series can be joined at station series endpoints (equation) and along station

series edges (branch). • More than one control point can exist at one location (x,y coordinate) in space. • More than one control point can exist at one location in space, each having the

same subtype, but each with a different StationSeriesEventID (station equations). • Stationing must increase or decrease in value from one end of a station series to

the other without breaks or gaps. • Stationing values between two control points on a station series may not be equal

to the calculated 2 or 3 dimensional distance between the two points. However, it is assumed that the station values can be interpolated as a proportional function of the distance between the two points.

• All referenced events (features) have their geometry derived from the geometry of

the station series feature on which they are located. • Each control point must belong to one and only one station series of the same

reference mode.


May 2007 136

• Since each reference mode may have a different physical basis for determining and calculating station values, coincident station series within a LineLoop must have coincident control points to avoid interpolation errors. Control points must be propagated to/from all reference modes to each other to reliably locate events using PRM and ARM station values.

10.5.6 Structure The APDM contains one feature dataset named Transmission. The technical committee is convinced, at this point in ESRI's software life cycle, that topology is the most effective method for managing data integrity and consistency. If topology is implemented for the APDM, then all feature classes that participate in the topology must be stored in the same feature dataset. At present, all core and optional feature classes are located in the Transmission feature dataset. 11.0 Implementation Issues The following section describes some issues that need to be addressed by an organization planning to implement the APDM as a geodatabase. The technical committee strives to provide a data model that can be implemented out of the box using the tools found in ArcToolbox™, ArcCatalog™, and ArcMap. However, some implementation decisions require the use of custom code to achieve desired behavior of objects and classes within the model. Every effort is made to mitigate the need for custom code. The APDM does encapsulate behavior through the abstract and metadata feature classes, but standard ESRI geodatabase technology is not currently capable of fully enforcing this behavior out-of-the-box. The APDM does not include custom feature classes or class extensions to implement advanced pipeline behaviors. The choices of how the APDM is to be implemented determine if and when custom code is required to create desired object behavior. The optimal platform for the APDM 4 is ArcGIS 9.1 and 9.2. All design and implementation considerations are based on the technology available at these releases of ArcGIS. 11.1 The APDM and ‘Inline’ History The ability to audit the historical state of the pipeline is a regulatory requirement. The APDM provides mechanisms for storing the history of individual APDM features in the geodatabase. Collectively these mechanisms are referred to as ‘inline’ history. With the advent of ArcGIS 9.2, enterprise ArcSDE provides the ability to manage feature history via Archiving functionality. ArcGIS 9.2 archiving functionality supersedes much of the APDM’s inline history functionality, but those who are not utilizing enterprise ArcSDE or archiving may still find APDM inline history useful. APDM inline history is implemented via a variety of ‘audit’ attributes and data management practices. These attributes and associated data management practices allow



the storage of multiple historical states for a given feature, together with the current state of the feature, in the same feature class. (If desired, historical versions of features can be segregated into separate features classes, as well. See below for a discussion of inline history physical implementation options.) The audit attributes that are used to implement inline history are:

• EventID (String, 38) – The globally unique identifier (GUID) for a feature at a particular historical state. EventID changes with each successive record representing a different historical state of a feature.

• OriginEventID (String, 38) – The original GUID for a feature.

OriginEventID is set to be equal to EventID when a feature is first created. OriginEventID does not change with successive records representing different historical states of a feature.

• CreatedBy (String, 50) – User-ID of the operator who created the feature.

CreatedBy does not change with successive records representing different historical states of a feature.

• CreatedDate (Date) – The timestamp the initial record for a feature or object

was created in the database. Because CreatedDate is a database date, it does not necessarily correspond to the actual effective date of the feature or object in the real world. CreatedDate may be either earlier or later than EffectiveFromDate. CreatedDate does not change with successive records representing different historical states of a feature.

• EffectiveFromDate (Date) – The date a particular record in the database

went into effect in the real world. EffectiveFromDate should not be confused with CreatedDate or LastModified. For facility classes, EffectiveFromDate for the initial record for a feature should correspond to either the InServiceDate or the InstallationDate for the feature. EffectiveFromDate is modified with each successive record documenting the historical state of a feature.

• EffectiveToDate (Date) – The date at which a particular record in the

database is no longer in effect. EffectiveToDate is modified with each successive record documenting the historical state of a feature. For a database record that is currently in effect, EffectiveToDate is null.

• LastModified (Date) – The timestamp for the update of the record in the

database. For the initial record for a feature, LastModified = CreatedDate. The LastModified timestamp is modified with each successive record documenting the historical state of a feature.


May 2007 138

• ModifiedBy (String, 50) – User-ID of the operator who last modified the feature. For the initial record for a feature, ModifiedBy = CreatedBy. ModifiedBy changes with each successive record representing different historical states of a feature.

• HistoricalState (Integer, gnHistoricalState) – A logical flag used to indicate

whether the record represents the current, or a historical state of the feature/object the record represents. Possible values for HistoricalState are: Unknown (Verified) – -1, Unknown – 0, Current – 1, Historical – 2. “Current” is the default value. HistoricalState is included to simplify queries used to return either current or historical records.

11.1.1 Inline History Implementation The implementation of inline history is governed by two simple rules:

1. No feature or record is ever deleted from the geodatabase.

2. Each time a significant change in state of a feature occurs, a new record is generated to reflect the change in state.

Changes in state include the following types of events:

• Spatial edits o A feature is moved o An online polyline feature is split as the result of a reroute operation o An online polyline feature is split or truncated as the result of a new,

overlapping feature of the same type being inserted • Attribute edits

o Status changes o Data changes o Data corrections

A ‘significant change in state’ is left for the user to define. Some users of the APDM are concerned primarily with spatial edits and regard only those as significant changes of state. Others record every attribute edit as a change of state. EventID, OriginEventID, CreatedDate, LastModified, EffectiveFromDate, EffectiveToDate and HistoricalState are required to facilitate audit (history) tracking in the APDM. These fields store and distinguish multiple records for a single feature that represent the changing state of the feature over time. For all successive historical records for a feature, CreatedDate (and CreatedBy) remain constant. LastModified (and ModifiedBy), EffectiveFromDate and EffectiveToDate change with each successive record for a feature.



As an example, consider a valve that is installed on 8/1/2005, put into service on 1/1/2006, and recorded in the geodatabase on 2/1/2006 by User1. Initially, PresentPosition is Open. The pertinent values for the initial record for the valve are (note that integers are substituted for GUIDs for clarity):

EventID OriginEventID CreatedDate CreatedBy EffectiveFromDate EffectiveToDate 1 1 2/1/06 2:32 PM User1 8/1/2005 <NULL>

LastModified ModifiedBy HistoricalState InstallationDate InServiceDate PresentPosition

2/1/06 2:32 PM User1 Current 8/1/2005 1/1/2006 Open Three years after the valve is put in service the configuration of the pipeline is changed and the valve is closed, on 2/5/2009. This change in state is recorded in the database on 2/9/2009 by User2. This is considered a significant change of state for the valve, so a new record is created and the valve (and valve history) is now represented in the geodatabase by two records. Both records have their own unique EventID, but the fact that the two records store different historical states of the same feature is indicated by the common OriginEventID. The current record is indicated by having EffectiveToDate = <NULL>.

EventID OriginEventID CreatedDate CreatedBy EffectiveFromDate EffectiveToDate 1 1 2/1/06 2:32 PM User1 8/1/2005 2/5/2009 2 1 2/1/06 2:32 PM User1 2/5/2009 <NULL>

LastModified ModifiedBy HistoricalState InstallationDate InServiceDate PresentPosition

2/1/06 2:32 PM User1 Historical 8/1/2005 1/1/2006 Open 2/9/06 4:15 PM User2 Current 8/1/2005 1/1/2006 Closed

Note that when the second record for the valve is created, the EffectiveToDate value for the original record is modified and set equal to the EffectiveFromDate value for the new record. HistoricalState for the original record is set to “Historical”; HistoricalState for the second record is set to “Current”. These steps are critical in maintaining a pristine audit trail. The simplest implementation of APDM inline history is to store all records for the historical states of a feature in the same feature class as the record representing the current state of the feature (hence the term ‘inline’ history). A variety of queries facilitate the extraction of pertinent information from the APDM geodatabase:

• To retrieve only the current records from a feature class: o SELECT * FROM <class> WHERE HistoricalState = 1

• To retrieve only the historical records from a feature class:

o SELECT * FROM <class> WHERE HistoricalState = 2


May 2007 140

• To retrieve all historical states from a feature class, sorted by EffectiveFromDate: o SELECT EffectiveFromDate FROM <class> ORDER BY

EffectiveFromDate • To retrieve only the previous state of feature with OriginEventID = ‘X’:

o SELECT * FROM <class> WHERE OriginEventID = ‘X’ AND EffectiveToDate = (SELECT EffectiveFromDate FROM <class> WHERE OriginEventID = ‘X’ AND HistoricalState = 1)

One possible modification to the default 'inline' history implementation is to segregate historical records into a series of ‘archive’ feature classes (into a separate Transmission feature dataset and feature classes, or even into a separate geodatabase). This may be desired to maximize query performance on 'current' features, or simply to avoid the necessity of implementing definition queries in ArcMap to access only current records for features. This type of implementation is referred to as 'offline' history storage. If implementing 'offline' history storage, one should make sure to duplicate the entire 'online' schema for the 'offline' historical features. There are two basic implementations of offline history storage. In both implementations, the main geodatabase stores only current records, and the offline archive stores historical records. In the first variation, the offline archive is actually a complete implementation of inline history, storing both current and historical records in the offline archive. In this variation, current records are duplicated, being stored in both the main geodatabase and the offline archive. In the second variation of offline history storage, only historical records are stored in the offline archive. Offline history storage has one potential advantage over inline history storage. With inline history storage, multiple historical versions of a single feature may be present in the geodatabase. When a topology feature class is used to manage coincident geometries in the APDM, bear in mind that the topology feature class cannot distinguish between current and historical records. Historical records may accidentally be modified when using the out-of-the-box topology edit tools. The use of offline history storage can help ameliorate this situation. At ArcSDE 9.2 and higher, Archiving functionality is available to maintain audit history on features. This functionality makes 'inline' and 'offline' history implementations largely superfluous. However, the APDM audit fields are still useful as defined. The reason for this is that Archiving tracks the times at which modified records are posted to SDE.Default and at which original or deleted records are rolled into the archive tables. The archiving time stamp is not the exact equivalent of any of the APDM audit date fields.



If taking advantage of ArcSDE 9.2 Archiving, one will not be able to make use of EffectiveToDate and HistoricalState. The reason for this is that modified and deleted records are automatically rolled from SDE.Default to the archive tables during the geodatabase ‘post’ operation. There is no opportunity to update either EffectiveToDate or HistoricalState on the original record in SDE.Default. Similarly, Archiving functionality users will find OriginEventID largely superfluous. While one may choose to continue using this attribute, ArcSDE Archiving functionality automatically maintains the relationship between successive records for a feature. Therefore, one additional advantage of ArcSDE Archiving functionality is that EventID for a feature can remain constant. 11.2 Using the APDM in a Versioned Geodatabase Environment Because of its heavy reliance on ESRI linear referencing technology, the APDM is a ‘relationship-rich’ data model. For instance, StationSeries implements a 1:M relationship with every online feature class in the model. In practical terms, this means that a single station series feature could conceivably be related to hundreds of thousands of online features. The relationships between station series and online features have profound implications for centerline editing in a versioned geodatabase environment. Great care should be taken to ensure that centerline (StationSeries) edits are not performed in sibling geodatabase versions, or in any version that is a parent to outstanding child versions. The reason for this is that reconcile and post operations on dependent sibling or child versions could potentially result in extremely large numbers of spurious data conflicts. Bear in mind that when editing a station series feature with large numbers of related online features, ArcSDE has no knowledge of which portion of the station series feature was edited; all ArcSDE knows is that the station series feature was edited. If a child or sibling version is outstanding during such an edit, every online feature related to the station series will be flagged as a potential data conflict when the child or sibling version is reconciled with the parent version. In practice, centerline edits should be performed on geodatabase versions that inherit directly from SDE.Default. A separate geodatabase version should be created for each centerline editing activity on a particular line segment (line loop or station series).While this ‘centerline edit version’ is in existence, no edits (centerline or otherwise) should be performed on the same line segment in any other outstanding geodatabase version. This type of logic can be implemented either through business practices, or through application software, but it is important to note that ArcMap does not implement this type of functionality out-of-the-box.


May 2007 142

11.3 Features as Events, Events as Features Point and linear events occur along routes at specified measures along the routes. Event layers/tables are considered "dynamic feature classes." The position of each event in an event table can be recalculated dynamically when the Route-ID and/or Measure value for the event are updated in the underlying event table. The advantage of this approach is that the geometry of features is updated when the underlying linear referencing information is changed. The disadvantage of the event model is that performance can become untenable for events layers with tens of thousands of features. Not all the analytical functionality of ArcGIS can be applied to event layers. Another approach to implementing the APDM is to use feature classes rather than event tables to store the geometry. Using feature classes allows access to all the analytical functionality of ArcGIS. However, there is no dynamic response that rebuilds the geometry of the features when the linear referencing information is altered. Custom code is required to implement "features as events" behavior. 11.4 Topology and the Geometric Network Transmission pipelines have many coincident features whose position is derived from the centerline– in effect, features are essentially dynamic events. These features are geometrically coincident with the underlying centerline. This is the geometric basis for transmission pipeline– everything is located via stationing. Topology provides a mechanism to identify dependent features that must also be updated when edits to features and/or the centerline occur. Topology is a set of rules that define where features should be in space in relation to each other. The rules define the permissible geometric relationships between features. The underlying reason for using topology in the transmission pipeline environment is that some features (pipes, costing, pressure tests) are dependent on the location (or lack thereof) of other features (station series, etc.). Not only are features dependent on the centerline for positioning, but features are also dependent on other features for existence (coating and pressure tests require that pipe segments be present). When the source feature is removed, the dependent features must also be removed. Topology, at the current time, provides the best tools for managing pipeline spatial data integrity. The rules of topology define how pipeline features' geometries relate to each other. Ranks can be set for each feature class participating in the topology to determine which features are salient and which can be altered to maintain integrity. Topology errors can be examined and repaired with a wide variety of out-of-the-box ArcMap topology editing tools. Shared geometry editing ensures that coincident features participating in a topology move together as edits are performed. "Dirty areas" appear for points, lines, and polygons whenever edits occur that may affect topology integrity. Topology exists as a structure within the geodatabase, and, for all intents and purposes, acts as another feature layer in ArcCatalog and ArcMap.



Some general guidelines and rules to keep in mind when implementing a topology are listed below.

• Annotation, dimension, and geometric network features are complex features and

cannot participate in a topology. • Multiple topologies can exist in a single feature dataset. • One feature class can participate in only one topology. • A topology and a geometric network can coexist in the same feature dataset, but

they cannot share a participating feature class. • Topology performance is based on the number of feature segments (two points

and a line). Linear features consist of one or more feature segments. • The number of rules has relatively little effect on performance, but

inappropriately or overly defined rules hurt performance since each error that is generated for a topology is an error that is written into the geodatabase.

• Using subtypes increases performance since fewer cursors are generated during

processing. • There is no recommended upper limit to the number of feature classes that may

participate in a topology. The geometric network is an excellent tool for analysis purposes and for editing features. The network does not account for stationing nor does it account well for coincident linear features. A geometric network only allows one linear feature to participate in the network at one location in space. Since stationing is such an integral part of pipeline operations, the benefits of the geometric network do not outweigh those of topology from a data editing and maintenance standpoint. However, the geometric network is a versatile tool for analysis. A recommendation is that organizations requiring a geometric network for analysis generate the geometric network as a stand-alone dataset stored in a separate feature dataset. Because a topology feature class can be defined in such a way as to enforce network connectivity, creating a geometric network from features in the Transmission feature dataset is a simple matter. 11.5 Developing Applications The delineation of the core elements of the APDM provides a standard framework for application developers and software vendors to develop portable applications that work on most, if not every, properly implemented APDM. It is suggested that application


May 2007 144

developers write applications that respond to the core attributes and feature classes in the model according to the specifications recorded in this document. Applications should be responsive to the variations in other feature classes and attributes. The APDM is designed to provide a core set of objects that remain constant from model to model. The remaining objects in the APDM are suggestions only, based on common implementation of many pipeline companies' standard features. Applications written for the APDM should respond dynamically to objects that are defined within the APDM beyond the core elements. 11.6 The APDM and Other Pipeline Data Models The APDM is similar in many ways to its pipeline data model predecessors: ISAT, PODS, and ISPDM. Conceptually, the APDM may be construed as a superset of these earlier models. The ISAT, PODS and ISPDM models are designed for industry-standard relational database management systems. While there are conceptual similarities to these earlier models, the user must always bear in mind that the APDM is uniquely designed to fully exploit ESRI geodatabase technology. The feature classes in the APDM were designed independently from the tables contained in the ISPDM, ISAT, and PODS models, but many of the salient attributes found in the feature classes of the APDM have counterparts in the attributes of the tables in the PODS, ISAT, and ISPDM models. The geodatabase, and thus the APDM, incorporates a relational database engine to store an object-relational model that extends standard RDBMS technology. Although the content and underlying technology of the PODS, ISAT, and ISPDM models and the APDM are similar, the access methods used to manipulate the structure and content of these models are very different. An enterprise geodatabase is an object-relational database management system. The standard technologies used to access data in a RDBMS such as Structured Query Language (SQL), Open Database Connectivity [ODBC] or Microsoft ActiveX Data Objects [ADO] are not designed to access data stored in a geodatabase. The primary method for customizing and accessing the data stored in the APDM is through the core ESRI ArcGIS technology (such as ArcMap) and its underlying component model, ArcObjects™. This is not to say that all SQL-related functions will not perform against a geodatabase, rather the applicability of SQL is limited. Data definition queries (DDL) cannot safely be executed on schema that is versioned. Data manipulation queries (DML) for the purposes of retrieval and updating are possible (through ADO, multi-version views and the ESRI OLEBD data provider); however, the results may be unsatisfactory due to perceived limitations of multiple domains assigned to the same fields based on subtype value, and the non-resolution of domain values during query run-time. Users attempting insert, update and delete operations using standard database access techniques need to be aware of the potential impacts to the underlying geodatabase. Executing these kinds of statements without due diligence can irretrievably corrupt the data stored within a geodatabase (especially when the geodatabase is in a versioned state).



The data stored within a geodatabase is relatively simple to access for the purposes of query. However, those attempting to edit such data via SQL should do so with caution. It should be noted that the restriction of versioning does not apply to personal geodatabases (which are currently based on the Microsoft Access technology). However, personal geodatabases are not suitable as enterprise solutions because they do not support multi-user access, and therefore are not used in most examples within this whitepaper. Even with this assumption, small companies that cannot afford a license of ArcSDE will have more options for increased data access and performance when ESRI releases its file-based geodatabase (at ArcGIS 9.2). 11.7 Conversion To/From PODS and ISAT The recommended conversion of PODS and ISAT data to the APDM is as follows:

• Convert PODS/ISAT control points to APDM control points. • Convert PODS/ISAT station series to APDM station series. • Convert PODS routes as APDM "continuous" station series. • Convert each feature/event table to an APDM event table/feature class, making

note to delineate the begin/end station series EventID attribute, begin/end station attribute, the begin/end offset angle, and distance and side attributes for on/offline features.

• Import non-referenced features with geometry as required.

11.8 Getting Data into the Model The simplest approach to creating data in the APDM is to:

• Import control points from a source containing x,y coordinates, station value, and an ID field that can be used to group the control points.

• Digitize station series features from the control points using the station value to

order the control points sequentially. Calibrate the measure values of the station series features using the station values of the control point features.

• Import the ID field used to group the control points into the station series feature

to establish the relationship between control points and station series. • Update the begin/end station values of each station series feature from the

measured value contained in the from/to points of the station series feature.


May 2007 146

• Import event tables containing features. Event tables must have a field that contains a Route-ID value found in the EventID of a station series feature. Point event tables must have an attribute named BeginStation containing valid station values along a station series route feature. Linear event tables must have two attributes (BeginStation, EndStation).

• Use the event tables to generate event themes. • Convert the event themes to feature classes in the model.

12.0 Model Future The intellectual property of the ArcGIS Pipeline Data Model is owned by ESRI. The content and structure of the model is determined by the APDM steering and technical committees. The positions on the APDM steering and technical committees are elected by members of the ESRI Pipeline Interest Group (PIG). Contact Bill Meehan at [email protected], or any APDM steering or technical committee member for more information on serving on the APDM technical or steering committees. The APDM technical committee meets twice a year, at the following venues, to discuss proposed improvements and alterations to the model.

• ESRI Petroleum User Group Meeting (February/March) • APDM User Group Meeting at the ESRI User Conference (June/July/August)

If you have any suggestions for changes or requests for information please contact:

• Craig Wilder (El Paso Corporation [email protected] (Steering Committee Chairperson)

• Peter Veenstra (Eagle Information Mapping) [email protected] (Technical

Committee Chairperson) • Robert Brook (ESRI Pipeline Industry Manager) [email protected]



Appendix A - Standards and Conventions The following standards and conventions for naming object, feature and relationship classes are used in the APDM. These standards are applied to the whitepaper, the logical model diagram and the physical model. Naming Conventions Class Names Some RDBMS’s have restrictions on table name lengths. In particular, Oracle restricts table names to no more that 30 characters. All object and feature classes, and M:N relationship classes are implemented as physical tables in the RDBMS, so paying attention to name length for such objects is important. In addition, ArcSDE 9.2 archiving functionality appends an ‘_H’ to the names of the tables storing archived objects. Therefore, Object, M:N Relationship, and Feature class names for concrete classes are restricted to 28 characters in length. Assigned names are complete words (if possible) that describe the contents of the class. Names that comprise two elements (such as StationSeries) are documented using ‘CamelCase’ or ‘CamelBack’ notation (the first letter of each word is capitalized). Class names do not utilize the under bar (_) character to separate elements within the name. Similarly, the naming convention for Relationship Classes is to concatenate the names of the objects being related to each other via the class. The name starts with the origin class and then appends the name of the destination class as follows:

<OriginClass><DestinationClass> The <OriginClass> represents the Object Name of the Origin Class of the Relationship Class and <DestinationClass> represents the Object Name of the Destination Class of the Relationship Class. If any default relationship class name exceeds 30 characters, it is reduced to 30 characters. To accomplish this, two methods of truncating the name are used:

• Method 1 - Parse and remove elements within the name of the Origin Object Class such that the resulting name is 30 characters long. Removal of letters is performed using commonly accepted truncations, e.g. the word ‘Location’ is shortened to Loc.

• Method 2 - Truncate the concatenated name to 30 characters.

Consider a relationship between the Object Classes LineCrossingLocation and AltRefMeasure. The default concatenated name is LineCrossingLocationAltRefMeasure, which is 33 characters long. Using Method 2, the Relationship Class name is LineCrossingLocationAltRefMeas. Using Method 1, the Relationship Class name is


May 2007 148

LineCrossingLocatAltRefMeasure (30 characters) or LineCrossingLocAltRefMeasure (28 characters). Foreign Keys Foreign keys (a relationship attribute maintained in the destination class for a simple 1:M relationship class) are named using the Origin Class name and the word ‘EventID’ as follows:

<ForeignClass>EventID The <ForeignClass> represents the name of the Origin Feature/Object Class participating in the relationship with the class containing the foreign key attribute. Use of Feature Datasets A geodatabase provides a way of storing thematically similar features together in what is called a Feature Dataset. A Feature Dataset is analogous to a folder created in a disk drive. Folders and Feature Datasets are used to store data that are similar to each other in an aspect that denotes a logical or semantic grouping. Feature Datasets are primarily used to store a collection of Feature Classes in the geodatabase that have something in common. Another use for a Feature Dataset is the creation of a Topology and/or a Geometric Network. One of the requirements for building a Topology within ArcGIS is that all Feature Classes participating in the Topology must be contained in the same Feature Dataset. The same principle applies for all Features Classes participating in a Geometric Network. The APDM requires that all Feature Classes that implement or inherit from ‘OnlineFeature’, ‘CenterlinePoint’, or ‘CenterlinePolyline’ must be grouped in a single Feature Dataset named “Transmission”. Two other aspects of the Feature Dataset are worth mentioning. First, the Feature Dataset enforces a standard spatial reference (including precision and X, Y, Z and M extents) for all Feature Classes that are stored within the Feature Dataset. Secondly, storing Feature Classes in Feature Datasets provides easier administration of the database objects, such as versions and permissions. Using Oracle as an example, if the underlying relational database management system (RDBMS) environment is configured properly, tablespace backup of specific feature datasets can be performed. Feature Classes that inherit from OfflineFeature or OfflineFacility can have a different spatial reference than that defined for the centerline (StationSeries and ControlPoint) in the ‘Transmission’ Feature Dataset. (In this case, such feature classes must be stored in a separate feature dataset.) Object classes (tables) are stored and displayed at the root level of the geodatabase. For a more complete explanation of Feature Datasets, please refer to the ESRI document “Understanding ArcSDE”.



Maximum String Size The maximum allowable string field length varies depending on the underlying RDBMS being used for ArcSDE. The current UML model diagram of the APDM physical model simply uses a string field type (esriFieldTypeString) to describe fields larger than 255 characters. If the default APDM UML is used to build a geodatabase, then any field implementing a string larger than 255 characters or defined as a type not supported by the target underlying geodatabase needs to be reconciled. This has implications for any string attribute field in the APDM, and in particular the fields defined in the RemovedPoint and RemovedLine Feature Classes. Implementers of the APDM must address these two attributes (and any others with a string length greater than 255 characters) by changing the physical UML model with string length settings appropriate to the target RDBMS being used to host the geodatabase. Of course, any changes to the APDM physical model should be noted and documented in a log file or manual by the implementer and/or consultant. The following table depicts the maximum string length supported by some industry standard RDBMS software.

RDBMS String Data Type Maximum Length Oracle VarChar 2000 Oracle VarChar2 ?

SQL Server Char 8000 SQL Server Text, NText 2 Gb

DB2 ? ? Informix ? ?

MS Access Memo 63K Documentation Standards The following are the standards and conventions for describing object/feature classes and relationship classes. Object or Feature Class Class Name: Name of the Class Feature Class Geometry:

Describe geometry as “Implemented as an M-Aware Polyline feature class” or “Implemented as an Object Class” or “Implemented as an Object Class used to build ‘Event’ themes.

APDM Inheritance:

List the APDM abstract and ESRI Core classes from which this class inherits or is derived.

Top Class (Ancestor) Next Class (Ancestor) Parent

(Ancestor) ClassName (Concrete) Example: ESRI Simple Object ESRI Simple Feature (Optional)


May 2007 150

FeatureArchive (Abstract) CenterlinePolyline (Abstract) ClassName (Concrete)

Attributes: (name, type, length, precision, scale, domain, description)

Describe each attribute by name, type, (length, precision, scale, and domain name if applicable) and a description of the attribute including a reason why it was incorporated in the model.

Example: EventID (GUID, String, 38) – A globally unique identifier for the

class. OperationalStatus (Long Integer, 9) gnOperationalStatus (required

APDM domain) – A domain value indicating the status of a feature that has some ‘operational’ lifespan based on the US Federal Energy Regulatory Commission (FERC) and Office of Pipeline Safety (OPS) definitions. Applied to centerline features or facility features with complex operational lifespans. The gnOperationalStatus domain is considered a ‘core’ APDM domain that ‘inherits’ values from the ‘gnStatus’ domain and must be implemented verbatim.

Relationships: (cardinality, optionality, attributes, composite)

Describe the relationships this class has to other classes in the model. The format for describing relationships is to list the name, if the relationship is considered Core (and therefore must be implemented), the origin class, the relationship cardinality and the destination class.

RelationshipName (Core): OriginClass is 1:M with

DestinationClass The following relationships are supported: 1:M – One to many relationship 1:0..M – One to zero to many relationship M:N – Many to many relationship

SubTypes: 1 – Subtype One 2 – Subtype Two etc.

Attributed Relationship Class Class Name: The name of the relationship class. Feature Class Geometry:

Describe geometry as “Implemented as an M-Aware Polyline feature class” or “Implemented as an Object Class” or “Implemented as an Object Class used to build ‘Event’ themes. Implemented as an attributed many-to-many relationship class.

Attributes: Describe each attribute by name, type, (length, precision, scale, a



(Name, type, length, precision, scale, domain, notes)

domain name if applicable) and a description of the attribute including a reason why it was incorporated in the model.

CompanyEventID (String, 38) – Foreign key to the Company object

class. LineLoopEventID (String, 38) – Foreign key to the Company

object class. ParticipantPercentage (Long Integer, 9) – (Default = 0) –

clParticipantPercent – Percentage (0–100%) of ownership. ParticipantType (Long Integer, 9) – (Default = 0) –

cParticipantType – Type of participation, e.g. ‘Ownership’, ‘Operator’.

Related Tables: List the name of the origin and destination object/feature classes that participate in the relationship.

Company: Origin LineLoop: Destination


May 2007 152

Appendix B - Glossary A Abstract Classes In ArcObjects, a specification for subclasses that is often shown on object model diagrams to help give structure to the diagram. An abstract class is not defined in a type library and cannot be instantiated.

In the APDM, abstract classes are a collection of broad data type categories, each of which has its own defined behaviors, and are used to coarsely define the semantic behavior of the various feature and object classes in the APDM.

APDM APDM stands for ArcGIS Pipeline Data Model. The ArcGIS Pipeline Data Model is designed for storing information pertaining to features found in 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. APDM core classes Core elements in an APDM geodatabase that maintain the semantic framework and behavior of the model. For an APDM- compliant geodatabase implementation, core classes must be implemented with the same names, attributes and relationship classes as described in the APDM Whitepaper. Arc-node topology The data structure in a coverage used to represent linear features and polygon boundaries and to support analysis functions, such as network tracing. Nodes represent the beginning and ending vertices of each arc. Arcs that share a node are connected, and polygons are defined by a series of connected arcs. An arc that intersects another arc is split into two arcs. Each arc that defines all or part of a polygon boundary records the number of the polygon to its left and to its right, giving it a direction of travel.



Attribute Information about a geographic feature in a GIS, usually stored in a table and linked to the feature by a unique identifier. For example, attributes of a river might include its name, length, and average depth.

In raster datasets, information associated with each unique value of raster cells.

Information that specifies how features are displayed and labeled on a map; the graphic attributes of a river might include line thickness, line length, color, and font for labeling.

Attribute data See Also: nonspatial data

Tabular or textual data describing the geographic characteristics of features.

Attribute domain See Also: Coded value domain, Domain, Range domain

In a geodatabase, a mechanism for enforcing data integrity. Attribute domains define what values are allowed in a field in a feature class or nonspatial attribute table. If the features or nonspatial objects have been grouped into subtypes, different attribute domains can be assigned to each of the subtypes. Attribute table See Also: Text attribute table

A database or tabular file containing information about a set of geographic features, usually arranged so that each row represents a feature and each column represents one feature attribute. In raster datasets, each row of an attribute table corresponds to a certain zone of cells having the same value. In a GIS, attribute tables are often joined or related to spatial data layers, and the attribute values they contain can be used to find, query, and symbolize features or raster cells.

B Baseline Assessment Plan (BAP) See Also: Integrity Management Plan

A plan of inline inspections, direct assessment and close interval survey inspections to determine the structural integrity and health of a pipeline. A BAP is an integral part of an Integrity Management Plan (IMP)


May 2007 154

Boundary A line separating adjacent political entities, such as countries or districts; adjacent tracts of privately-owned land, such as parcels; or adjacent geographic zones, such as ecosystems. A boundary is a line that may or may not follow physical features, such as rivers, mountains, or walls.

C CAD Acronym for Computer Aided Design. Software and techniques used to render schematic diagrams representing facilities or mapped area on or along a pipeline system. Cathodic Protection The prevention of electrolytic corrosion of a usually metallic structure (as a pipeline) by causing it to act as the cathode rather than as the anode of an electrochemical cell Centerline A line digitized along the center of a linear geographic feature, such as a street or a river that at a large enough scale would be represented by a polygon.

CIS Acronym for Close Interval Survey. A procedure where soil loss potential measurements are taken from a pipeline by a person stabbing a thin metal wire into the ground spaced by a regular distance from the previous measurement.

Class See Also: Abstract Classes; Concrete Class

1. A set of entities grouped together on the basis of shared attribute values.

2. Pixels in a raster file that represent the same condition.

3. A template for a type of object in an object-oriented programming language. A class is used to create objects that share the same structure and behavior.

4. In Arc Web Services, a set of one or more types of features in the data. Each class has an associated set of symbols. The symbol used for a class may vary depending on the map scale and style.



CLSID See Also: GUID

Acronym for class identifier. Refers to the globally unique number that is used by the system registry and the COM framework to identify a particular co-class.

Coded value domain See Also: Domain

A type of attribute domain that defines a set of permissible values for an attribute in a geodatabase. A coded value domain consists of a code and its equivalent value. For example, for a road feature class, the numbers 1, 2, and 3 might correspond to three types of road surface: gravel, asphalt, and concrete. Codes are stored in a geodatabase, and corresponding values appear in an attribute table.

Coincident Occupying the same space. Coincident features or parts of features occupy the same space in the same plane. In geodatabase feature classes, vertices or boundaries that fall within the set cluster tolerance of one another are coincident; they are snapped together during the validate topology process.

Coincident geometry See Also: Topology

In a geodatabase, how the coordinates of coincident features are stored. For example, if two lines are coincident, they are both drawn in ArcMap, with one line lying precisely on top of the other. For two adjacent polygons, the coordinates for the shared boundary are stored with each polygon and the boundary is drawn twice.

COM Acronym for Component Object Model. A binary standard that enables software components to interoperate in a networked environment regardless of the language in which they were developed. Developed by Microsoft, COM technology provides the underlying services of interface negotiation, life cycle management (determining when an object can be removed from a system), licensing, and event handling. The ArcGIS system is created using COM objects.

Concrete Class See Also: Abstract Classes


May 2007 156

A feature or object class that is implemented within the Geodatabase. Within APDM a concrete class may inherit attributes and relationships from one or more APDM Abstract Classes.

Constraints Limits imposed on a model to maintain data integrity. For example, in a water network model, an 8-inch pipe cannot connect to a 4-inch pipe.

Control point An accurately surveyed coordinate location for a physical feature that can be identified on the ground. Control points are used in a least squares adjustment as the basis for improving the spatial accuracy of all other points to which they are connected.

One of various locations on a paper or digital map that has known coordinates and that is used to transform another dataset--spatially coincident but in a different coordinate system--into the coordinate system of the control point. Control points are used in digitizing data from paper maps, in georeferencing both raster and vector data, and in performing spatial adjustment operations such as rubber sheeting.

Coordinate system A reference framework consisting of a set of points, lines, and/or surfaces, and a set of rules, used to define the positions of points in space in either two or three dimensions. The Cartesian coordinate system and the geographic coordinate system used on the earth's surface are common examples of coordinate systems.

Coordinates See Also: Geographic coordinates, x,y coordinates

Values represented by x, y, and possibly z, that define a position in terms of a spatial reference framework. Coordinates are used to represent locations on the earth's surface relative to other locations.

CP See Also: Cathodic Protection

cp – The prefix used for the Cathodic Protection domains.



Core Classes In the APDM, those abstract, feature, object and relationship classes, and domains, that must be implemented to attain APDM compliance.

Crows Feet A database modeling term used to describe the end symbol on a relationship represent ‘many’ or ‘one or more’.

D Database See Also: Geodatabase

One or more structured sets of persistent data, managed and stored as a unit and generally associated with software to update and query the data. A simple database might be a single file with many records, each of which references the same set of fields. A GIS database includes data about the spatial locations and shapes of geographic features recorded as points, lines, areas, pixels, grid cells, or TINs, as well as their attributes.

Data model See Also: Data structure

In GIS, a mathematical paradigm for representing geographic objects or surfaces as data. The vector data model represents geography as collections of points, lines and polygons; the raster data model represents geography as cell matrixes that store numeric values; the TIN data model represents geography as sets of contiguous, non-overlapping triangles.

In ArcGIS, a set of database design specifications for objects in a GIS application. A data model describes the thematic layers used in the application (for example, counties, roads, hamburger stands); their spatial representation (for example, point, line, or polygon); their attributes; their integrity rules and relationships (for example, streets cannot self-intersect, counties must nest within states); their cartographic portrayal; and their metadata requirements.

In information theory, a description of the rules by which data is defined, organized, queried, and updated within an information system (usually a database management software program).

Data structure The organization of data within a specific computer system that allows the data to be stored and manipulated effectively; a representation of a data model in computer form.


May 2007 158

Dataset See Also: Feature dataset Any organized collection of data with a common theme. Data source Any data. Data sources may include coverages, shapefiles, rasters, or feature classes.

DBA Acronym for Database Administrator. The person responsible for the creation, management and monitoring of a Relational Database Management System (RDBMS) implementation for integrity and performance purposes.

DLL Acronym for dynamic link library. A type of file that stores shared code to be used by multiple programs (a "code library"). Programs access the shared code by linking to the .dll file when they run, a process referred to as dynamic linking. The .dll file must be registered for other programs to locate it.

Domain See Also: Attribute domain, Coded value domain, Range domain

A group of computers and devices on a network that are administered as a unit with common rules and procedures. Within the Internet, a domain is defined by IP address. All devices sharing a common part of the IP address are said to be in the same domain.

The range of valid values for a particular metadata element.

Domain name See Also: Domain

The unique name of a computer system on the Internet, such as www.apdm.net

Domain names (Namig Convention) in the APDM

cl – domains applied to centerline feature and object classes cp – cathodic protection domains. en – domains applied to feature classes pertaining to feature classes modeling encroachments to the pipeline. fc – domains applied to facility feature classes.



gn (generic) – domains that are applied to object classes and many different feature classes across the model. in – domains applied to inspection feature classes. op – domains applied to feature classes pertaining to pipeline operations.

Dynamic segmentation The process of calculating the shapes of point and line route events at run time.

E Edge In a network system, a linear feature (for example, a pipeline in a sewer system) through which a commodity, such as information, water, or electricity flows.

In a geometric network, a network edge can be simple or complex. A simple edge is always connected to exactly two junction features, one at each end. A complex edge is always connected to at least two junction features at its endpoints, but it can also be connected to additional junction features along its length.

In a network dataset, a network edge is only connected to two junctions at its endpoints.

Elevation The vertical distance of a point or object above or below a reference surface or datum (generally mean sea level). Used especially in reference to vertical height on land.

Equation A deliberate break in the monotonicity of stationing along a Lineloop. Equations represent the start or end of a station series of a different reference within a given Lineloop. Equations are sometimes referred to as Station Equations.

Event See Also: route event, temporal event, x,y event

A geographic location stored in tabular rather than spatial form. Event types include address events, route events, x,y events, and temporal events.

EventID Provides a mechanism for uniquely identifying each feature or object in the geodatabase independent of the feature or object class to which it belongs.


May 2007 160

Event layer In ArcGIS, a layer created from an event table.

Event table A data source containing location information in tabular format (called events) that is used to create a spatial dataset. For example, an event table might contain x,y coordinates or routes.

Extrapolation In GIS, using known or observed data to infer or calculate values for unobserved times, locations or other variables outside a sampled area. In the absence of data, extrapolation may be a good method for making predictions, but it is not always accurate. For example, based on observed economic indicators, an economist can make predictions about the state of the economy at a future time. These predictions may not be accurate because they cannot take into account seemingly random events such as natural disasters.

F Feature A representation of a real-world object on a map.

Feature class A collection of geographic features with the same geometry type (such as point, line, or polygon), the same attributes, and the same spatial reference. Feature classes can be stored in geodatabases, shapefiles, coverages, or other data formats. Feature classes allow homogeneous features to be grouped into a single unit for data storage purposes. For example, highways, primary roads, and secondary roads can be grouped into a line feature class named "roads." In a geodatabase, feature classes can also store annotation and dimensions.

Feature data

Data that represents geographic features as geometric shapes.

Feature dataset

A collection of feature classes stored together that share the same spatial reference; that is, they have the same coordinate system, and their features fall within a common



geographic area. Feature classes with different geometry types may be stored in a feature dataset.

Feature layer See Also: Layer

A layer that references a set of feature data. Feature data represents geographic entities as points, lines, and polygons.

G Geodatabase See Also: Database

A collection of geographic datasets for use by ArcGIS. There are various types of geographic datasets, including feature classes, attribute tables, raster datasets, network datasets, topologies, and many others. There are various styles of Geodatabase including: personal, file-based, workgroup, and enterprise.

Geographic coordinates See Also: Geographic Coordinate System A measurement of a location on the earth's surface expressed in degrees of latitude and longitude. Geographic coordinate system A reference system that uses latitude and longitude to define the locations of points on the surface of a sphere or spheroid. A geographic coordinate system definition includes a datum, prime meridian, and angular unit.

Geographic data Information about real-world features, including their shapes, locations, and descriptions. Geographic data is the composite of spatial data and attribute data.

Geometric coincidence The distance within which features in a geometric network are deemed to be coincident and, therefore, connected.


May 2007 162

Geometric network Edge and junction features that represent a linear network, such as a utility or hydrologic system, in which the connectivity of features is based on their geometric coincidence. A geometric network does not contain information about the connectivity of features; this information is stored within a logical network. Geometric networks are typically used to model directed flow systems.

Geometry The measures and properties of points, lines and surfaces. In a GIS, geometry is used to represent the spatial component of geographic features.

Georeferencing Aligning geographic data to a known coordinate system so it can be viewed, queried, and analyzed with other geographic data. Georeferencing may involve shifting, rotating, scaling, skewing, and in some cases warping or rubber sheeting the data.

GIS See Also: Model, Spatial data

Acronym for geographic information system. An integrated collection of computer software and data that people use to view and manage information about geographic places, analyze spatial relationships, and model spatial processes. A GIS provides a geographic framework for gathering and organizing spatial data and related information into layers of data that can be displayed and analyzed.

GPS Acronym for Global Positioning System. A system of geosynchronous, radio-emitting and receiving satellites used for determining positions on the earth. The orbiting satellites transmit signals that allow a GPS receiver anywhere on earth to calculate its own location through triangulation. Developed and operated by the U.S. Department of Defense, the system is used in navigation, mapping, surveying, and other applications in which precise positioning is necessary.

GUI Acronym for graphical user interface. A software display format of the input and output of a program that lets the user choose commands by pointing to icons, dialog boxes, and lists of menu items on the screen, typically using a mouse. This contrasts with a command line interface where communication is accomplished via the exchange of strings of text.



GUID See Also: CLSID

Acronym for globally unique identifier. A string used to uniquely identify an interface, class, type library, or component category.

H Hierarchical database See Also: database

A database that stores related information in a tree-like structure, where records can be traced to parent records which in turn can be traced to a root record.

High Consequence Area (HCA) A geographic region of significant environmental or cultural significance or population density that if, a pipeline rupture or burst were to occur, would incur substantial cost in terms of loss of life, environmental or financial consequence to a pipeline operator and those living in proximity of the pipeline.

I ILI Acronym for Inline Inspection. A procedure by which a mechanical devices equipped with sensors and/or cleaning devices is pushed, under pressure, through the pipeline for the purposes of detecting anomalies in the structure or ovality of the pipe or for removing sludge and other undesirable elements from inside the pipeline.

Index A data structure, usually an array, used to speed the search for records in a database or for spatial features in geographic datasets. In general, unique identifiers stored in a key field point to records or files holding more detailed information.

Inheritance An term or convention used by object-oriented modelers describing the ‘passing’ of attributes, interfaces, and relationships from a parent to child object.


May 2007 164

IMP Acronym for Integrity Mangement Programs. A formalized set of operating procedures for planning the remediation and mitigation of threats posed to a pipeline from corrosion, third party damage, current operating conditions, etc.

The IMP is designed to guide a pipeline operator in performing the required functions to maintain the structural and operational integrity of a pipeline system.

Interoperability See Also: OGC

The capability of components or systems to exchange data with other components or systems, or to perform in multiple environments. In GIS, interoperability is required for a GIS user using software from one vendor to study data compiled with GIS software from a different provider.

Interpolation

In the context of linear referencing, the calculation of measure values for a route between two known measure values.

J Joining See Also: relate

Appending the fields of one table to those of another through an attribute or field common to both tables. A join is usually used to attach more attributes to the attribute table of a geographic layer.

Connecting two or more features from different sets of data so that they become a single feature.

Junction

For network data models in a geodatabase, a point at which two or more edges meet.

In a coverage, a node joining two or more arcs.



K Keyword See Also: index

A significant word from a document that is used to index or search content.

A word searched for in a search command. Keywords are searched for in any order. When defining metadata, users can enter theme and place keywords.

Known point

A surveyed point that has an established x,y coordinate value. Known points are used in survey operations to extend survey computations into a project area.

L Layer 1. The visual representation of a geographic dataset in any digital map environment.

Conceptually, a layer is a slice or stratum of the geographic reality in a particular area, and is more or less equivalent to a legend item on a paper map. On a road map, for example, roads, national parks, political boundaries and rivers are examples of different layers.

2. In ArcGIS, a reference to a data source, such as a coverage, geodatabase feature class, raster, and so on, that defines how the data should be symbolized on a map. Layers can also define additional properties, such as which features from the data source are included. Layers can be stored in map documents (.mxd) or saved individually as layer files (.lyr). Layers are conceptually similar to themes in ArcView 3.x.

3. A stand-alone feature class in a geodatabase managed with SDE 3 or ArcSDE.

Line See Also: line feature, polyline

On a map, a shape defined by a connected series of unique x,y coordinate pairs. A line may be straight or curved.

Line event In linear referencing, a feature that describes a portion of a route using a from- and to-measure value. Examples include pavement quality, salmon spawning grounds, bus fares, pipe widths, and traffic volumes.


May 2007 166

Line feature See Also: line, polyline feature

A map feature that has length but not area at a given scale, such as a river on a world map or a street on a city map.

Line loop An object class designed to store information describing a line in the pipeline system. A construct that represents 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 line loop might be a mainline transmission pipe or a branch from a gathering field. Often several line loops run parallel to each other. A line loop may have gaps along the entire pipeline as pipes are often shared between several lines. In almost all cases a line loop is an aggregation of one or more station series features but can also be the aggregation of one or more line loops.

Logical LineLoop – A LineLoop object that has no related StationSeries features but

may have one or more related child LineLoop objects. Physical LineLoop – A parent LineLoop object that has one or more related child

StationSeries features.

Linear interpolation The estimation of an unknown value using the linear distance between known values.

Linear referencing See Also: dynamic segmentation

A method for storing geographic data by using a relative position along an already existing linear feature; the ability to uniquely identify positions along lines without explicit x,y coordinates. Location is given in terms of a known linear feature and a position, or measure, along it. Linear referencing is an intuitive way to associate multiple sets of attributes to portions of linear features.

Linear unit See Also: Unit of Measure

The unit of measurement on a plane or a projected coordinate system, often meters or feet.



M Many-to-many relationship An association between two linked or joined tables in which one record in the first table may correspond to many records in the second table, and vice versa.

Many-to-one relationship See Also: joining, many-to-many relationship, one-to-many relationship, one-to-one relationship

An association between two linked or joined tables in which many records in the first table may correspond to a single record in the second table.

Metadata Information that describes the semantic behavior, schema and data content of an APDM geodatabase.

Two types of metadata constructs are implemented in the APDM:

Class-level metadata – stores additional behavioral information for an object or feature class that applies to all objects in the class, or to all objects within a subtype of the class.

Feature-level metadata – stores information that defines the behavior of individual features within a feature class. Feature-level metadata is used to define the behavior of online events and ControlPoint features during centerline editing operations that change the shape of the centerline or alter station values.

Model 1. An abstraction and representation of reality used to represent objects, processes,

or events.

2. A set of clearly defined analytical procedures used to derive new information from input data.

3. A set of rules and procedures for representing a phenomenon or predicting an outcome. In geoprocessing, a model consists of one process or a sequence of processes connected together, and is created in Model Builder.

4. A data representation of reality, such as the vector data model.


May 2007 168

Monotonic Increasing or decreasing values in a single direction without breaks, gaps, or repetitions in values.

M-value Vertex attributes that are stored with x,y point coordinates in ESRI's Geometry Engine. Every type of geometry (point, polyline, polygon, and so on) can have attributes for every vertex.

In linear referencing, measure values that may be added to linear features to perform dynamic segmentation. In linear referencing, m-values are used on vertices to imply a measurement along a linear feature. The m-value allows a location along a line to be found.

N Nonspatial data See Also: attribute data

Data without inherently spatial qualities, such as attributes.

NPMS Acronym for the National Pipeline Mapping System. The U.S. Government requires that all pipelines report the location and other attributes describing the pipeline using the standard NPMS reporting format.

O Object In GIS, a digital representation of a spatial or nonspatial entity. Objects usually belong to a class of objects with common attribute values and behaviors.

In object-oriented programming, an instance of the data structure and behavior defined by a class.

Object class In a geodatabase, a collection of nonspatial data of the same type or class. While spatial objects (features) are stored in feature classes in a geodatabase, nonspatial objects are stored in object classes.



A table in a geodatabase used to store a collection of objects with similar attributes and behavior. Objects with no location information are stored as rows or records in object classes. Spatial objects, or features, are stored as rows in feature classes, which are a specialized type of object class in which objects have an extra attribute to define their geographic location.

Offline Linear Features Offline linear features are stored in a polyline feature class. It is possible for an offline linear feature to intersect the centerline in multiple places and thus have one or more online point location features as referenced locations. Offline linear features must have the following attribute:

• EventID (string, 38) − A globally unique identifier for the feature.

Offline Point Features Offline Point features are stored in an M Aware (optionally Z Aware) point feature class that is located off the centerline. Offline features may be referenced against a location on the centerline. Offline point features must have the following attribute:


Offline Polygon Features Offline Polygon features are stored in a polygon feature class. Offline polygons represent features that are not located by stationing or linear referencing. The centerline may pass through or by an offline polygon. It is optional to store an online liner feature as an online location for an offline polygon where the linear feature represents the intersection and overlap of the centerline by the polygon.

OGC

Acronym for Open Geospatial Consortium. An international industry consortium of companies, government agencies, and universities participating in a consensus process to develop publicly available geoprocessing specifications. Open interfaces and protocols defined by OpenGIS Specifications support interoperable solutions that "geo-enable" the Web, wireless and location-based services, and mainstream IT; and empower technology developers to make complex spatial information and services accessible and useful with all kinds of applications.


May 2007 170

One-to-many relationship See Also: joining, many-to-many relationship, many-to-one relationship, one-to-one relationship

An association between two linked or joined tables in which one record in the first table corresponds to many records in the second table.

One-to-one relationship See Also: joining, many-to-many relationship, many-to-one relationship, one-to-many relationship

An association between two linked or joined tables in which one record in the first table corresponds to only one record in the second table.

Online Linear Features Online linear features are stored in an M Aware (optionally Z Aware) polyline feature class that is geometrically constrained and coincident with the centerline. Online linear features are located by linear referencing using a Route-ID and two Measure fields.

Online linear features can exist as concrete features located along the centerline or as online locations for offline polyline and offline polygon features. Online Linear feature classes must have the following attributes:

• StationSeriesEventID (sting, 38) − A foreign key to a station series feature (route) along which the online linear feature is located.

• BeginStation (double 15, 2) − A station value (measure) along a station series used to position and locate the start of the linear feature.

• EndStation ( double 15, 2) − A station value (measure) along a station series used to position and locate the end of the linear feature.


Online Point Features Online point features can be used to model concrete features that occur along the centerline or as online locations for offline point or offline polyline features.

Online Point feature classes must have the following attributes:

• BeginOffsetDistance (double 15, 2) (Optional) − The distance of the point feature from a point referenced on the centerline. Only used if the online point feature is acting as an online location for an offline point or offline linear feature.



• BeginOffsetAngle (double 15, 2) − The angle of the vector from the referenced point on the centerline to the offline point. The angle is measured from the upstream vector of the centerline. Only used if the online point feature is acting as an online location for an offline point or offline linear feature.

• Station (double 15, 2) − A station value (measure) along a station series used to position and locate the point feature.

• StationSeriesEventID (string, 38) − A foreign key to a station series feature (route) on which the online point feature is located.


• SymbolRotation (double 15, 2) − A rotation angle from 0-360 for a point symbol (uses gnAngle domain).

op Prefix applied to domains describing feature classes describing pipeline operations.

OPS Acronym for the Office of Pipeline Safety. The OPS is the regulatory branch of the Pipeline and Hazardous Materials Safety Administation (PHMSA) under the auspices of the U.S. Department of Transportation (DOT) and Federal Energy Regulatory Commission (FERC).

P Personal geodatabase A geodatabase that stores data in a single-user relational database management system. A personal geodatabase can be read simultaneously by several users, but only one user at a time can write data into it.

Point See Also: Point Feature

A geometric element defined by a pair of x,y coordinates.


May 2007 172

Point event In linear referencing, a feature that occurs at a precise point location along a route; it uses a single measure value. Examples include accident locations along highways, signals along rail lines, bus stops along bus routes, and pumping stations along pipelines.

Point feature See Also: Point

A map feature that has neither length nor area at a given scale, such as a city on a world map or a building on a city map.

Polygon See Also: Polygon Feature

On a map, a closed shape defined by a connected sequence of x,y coordinate pairs, where the first and last coordinate pair are the same and all other pairs are unique.

Polygon feature See Also: Attribute Table, Polygon

A map feature that bounds an area at a given scale, such as a country on a world map or a district on a city map.

Polyline See Also: polyline feature

In ArcGIS software, a shape defined by one or more paths, where a path is a series of connected segments. If a polyline has more than one path (a multipart polyline) the paths may either branch or be discontinuous.

Polyline feature See Also: attribute table, polyline

In ArcGIS software, a digital map feature that represents a place or thing that has length but not area at a given scale. A polyline feature may have one or more parts. For example, a stream is typically a polyline feature with one part. If the stream goes underground and later reemerges, it might be represented as a multipart feature with discontinuous parts. If the stream diverges around an island and then rejoins itself, it might be represented as a multipart feature with branching parts. A multipart polyline feature is associated with a single record in an attribute table.



Primary key A column or set of columns in a database that uniquely identifies each record. A primary key allows no duplicate values and cannot be null.

Q Query A request to select features or records from a database. A query is often written as a statement or logical expression.

R Range domain See Also: Attribute domain, Coded value domain, Domain

A type of attribute domain that defines the range of permissible values for a numeric attribute. For example, the permissible range of values for a pipe diameter could be between one and 32 inches.

Raster See Also: Vector

A spatial data model that defines space as an array of equally sized cells arranged in rows and columns. Each cell contains an attribute value and location coordinates. Unlike a vector structure, which stores coordinates explicitly, raster coordinates are contained in the ordering of the matrix. Groups of cells that share the same value represent the same type of geographic feature.

RDBMS Acronym for relational database management system. A type of database in which the data is organized across several tables. Tables are associated with each other through common fields. Data items can be recombined from different files. In contrast to other database structures, an RDBMS requires few assumptions about how data is related or how it will be extracted from the database.

Oralce and MS SQLServer are two vendor specific RDBMS that both support implementation of an ESRI Geodatabase.


May 2007 174

Reference mode Reference modes represent different methods of recording station values and how these values are applied at the LineLoop level.

Relate See Also: joining

An operation that establishes a temporary connection between records in two tables using an item common to both.

Relationship class An item in the geodatabase that stores information about a relationship. A relationship class is visible as an item in the ArcCatalog tree or contents view.

Relational database A data structure in which collections of tables are logically associated with each other by shared fields.

Re-Route The procedure where the current position of a portion of the pipeline is altered by either:

• adding length to the beginning or end of the pipeline,

• deleting length from the pipeline

• abandoned or removing a portion of the pipeline and replacing that segment with another segment of pipe at the same or a slightly difference location.

Right of Way (ROW) A legal agreement between a pipeline operator and a land owner granting the operator access and useage of a portion of land along and to either side of a pipeline that intersects the owned property.

ROI Acronym for Return on Investment. A financial term used to measure the potential return (in monetary value) on an investment.



Route event In linear referencing, linear, continuous or point features occurring along a base route system.

S Segment In ArcGIS software, a geometric element from which paths are constructed. A segment consists of a start point, an endpoint, and a function that describes a straight line or curve between these two points. Curves may be circular arcs, elliptical arcs, or Bézier curves.

Shape The characteristic appearance or visible form of a geographic object as represented on a map. A GIS uses variations of three basic shapes to represent geographic objects: points, lines, and polygons.

Shapefile A vector data storage format for storing the location, shape, and attributes of geographic features. A shapefile is stored in a set of related files and contains one feature class.

Single-user geodatabase A personal geodatabase that can handle a single editor and multiple readers.

Spatial data See Also: nonspatial data, temporal data

Information about the locations and shapes of geographic features and the relationships between them, usually stored as coordinates and topology.

Any data that can be mapped.

Spatial database A collection of spatial data and its related descriptive data, organized for efficient storage and retrieval.


May 2007 176

Spatial reference The coordinate system used to store a spatial dataset. For feature classes and feature datasets within a geodatabase, the spatial reference also includes the spatial domain.

Stationing 1. In the pipeline industry, another name for linear referencing. Stationing is the

measured distance along the station series.

2. Stationing allows any point along a pipeline to be uniquely identified.

Station series A linear path representing a portion of the centerline of a pipeline, or the route that the pipeline follows across the surface of the earth.

Station Value The measure value assigned to a point location.

Subsystem A subsystem is an area on or along the pipeline system. Typically subsystems are represented by polygonal features such as states, counties, operating areas, inspection zones, site boundaries etc. A subsystem could also be represented by one or more linear ‘reaches’ or ‘events’ along a pipeline system.

Logical SubSystem – A SubSystem object that has no related SubSystemRange features but may have one or more related child SubSystem objects.

Physical SubSystem – A parent SubSystem object that has one or more related child

SubSystemRange features. Subtype In geodatabases, a subset of features in a feature class or objects in a table that share the same attributes. For example, the streets in a streets feature class could be categorized into three subtypes: local streets, collector streets, and arterial streets. Creating subtypes can be more efficient than creating many feature classes or tables in a geodatabase. For example, a geodatabase with a dozen feature classes that have subtypes will perform better than a geodatabase with a hundred feature classes. Subtypes also make editing data faster and more accurate because default attribute values and domains can be set up. For



example, a local street subtype could be created and defined so that whenever this type of street is added to the feature class, its speed limit attribute is automatically set to 35 miles per hour.

T Table A set of data elements arranged in rows and columns. Each row represents a single record for an entity, such as a feature. Each column represents a field of the record. Rows and columns intersect to form cells, which contain a specific value for one field in a record.

Tabular data See Also: Table

Descriptive information, usually alphanumeric, that is stored in rows and columns in a database and can be linked to spatial data.

Temporal data See Also: Spatial data

Time- and date-specific information for geographic locations that enables tracking of real-time, future, or past observations, which can be discrete, such as lightning strikes; moving, such as airplanes; or static, such as traffic sensors.

Temporal event See Also: event

In ArcGIS Tracking Analyst, a type of event used to describe observations through time of particular objects or groups of objects.

Text attribute table See Also: Attribute table

A table containing text attributes, such as color, font, size, location, and placement angle, for an annotation subclass in a coverage. In addition to user-defined attributes, the text attribute table contains a sequence number and text feature identifier.

Topology See Also: Arc-node topology


May 2007 178

In geodatabases, the arrangement that constrains how point, line, and polygon features share geometry. For example, street centerlines and census blocks share geometry, and adjacent soil polygons share geometry. Topology defines and enforces data integrity rules (for example, there should be no gaps between polygons). It supports topological relationship queries and navigation (for example, navigating feature adjacency or connectivity), supports sophisticated editing tools, and allows feature construction from unstructured geometry (for example, constructing polygons from lines).

The branch of geometry that deals with the properties of a figure that remains unchanged even when the figure is bent, stretched, or otherwise distorted.

U Unit of measure See Also: Linear unit

A standard quantity used for measurements such as length, area, and height.

V Vector See Also: Raster

A coordinate-based data model that represents geographic features as points, lines, and polygons. Each point feature is represented as a single coordinate pair, while line and polygon features are represented as ordered lists of vertices. Attributes are associated with each feature, as opposed to a raster data model, which associates attributes with grid cells.

Any quantity that has both magnitude and direction.

Vertex

One of a set of ordered x,y coordinate pairs that defines a line or polygon feature.

W Wormhole A database or object-modeling term used to show a relationship to a class using a small colored oval to represent the class in a logical model diagram as opposed to representing the class in it’s entirety. Is used in logical model diagrams for simplifying the drawing.



X X,Y coordinates A pair of values that represents the distance from an origin (0,0) along two axes, a horizontal axis (x), and a vertical axis (y). On a map, x,y coordinates are used to represent features at the location they are found on the earth's spherical surface.

X,Y event See Also: coordinates, event, event layer, event table, x,y coordinates

A simple coordinate pair that describes the location of a feature, such as a set of latitude and longitude degrees.

Y Z Z-value The value for a given surface location that represents an attribute other than position. In an elevation or terrain model, the z-value represents elevation; in other kinds of surface models, it represents the density or quantity of a particular attribute.


May 2007 180

Appendix 3 – APDM 3.0 to APDM 4.0 Conversion Utility Script In moving from version 3.0 to version 4.0 of the APDM, the following specific naming changes to various object classes, relationship classes and fields have occurred:

1. All object classes with the naming convention <class name>Activity have been renamed <class name>Audit.

2. All M-N relationship classes with the naming convention <class name>ActivityDocument have been renamed <class name>AuditDocument.

3. Within the above relationship classes, foreign key fields with the naming convention <class name>ActivityEventID have been renamed <class name>AuditEventID

Within the APDM are a large number of classes that follow these naming conventions. While it is possible to manually rename object and relationship classes in ArcCatalog, this activity is extremely tedious and prone to error. Also, unfortunately, ESRI geodatabase technology does not permit any renaming of fields. To deal with the relationship classes defined above, it is actually necessary to define new relationship classes with the desired names, copy information into them from the old relationship classes, and then remove the old relationship classes. This can only be accomplished via a utility program. The following VBA script is designed explicitly to implement the naming changes described above. The script is fairly generic, and can easily be modified to address other facets of migrating an APDM version 3.0 geodatabase in place to version 4.0. Disclaimer 1. PUBLIC DOMAIN Environmental Systems Research Institute, Inc. (ESRI) expressly states the script is being placed in the public domain or is "Freeware." The script may be freely used and redistributed, is provided "AS-IS" without warranty of any kind, and there is no technical support provided. 2. LICENSE AGREEMENT Reservation of Ownership and Grant of Rights This is a license agreement (Agreement) and not an agreement for sale. ESRI retains exclusive title and ownership of the copy of the VBScript script (referred to hereinafter as "Script") licensed under this Agreement and grants you (hereinafter referred to as "User") a personal, nonexclusive, nontransferable, worldwide, royalty-free license to use, copy, edit, modify, merge, incorporate, and/or prepare derivative work(s) of the Script with any new scripting code and/or data, and thereafter the copyright license to demonstrate, reproduce, redistribute, and publicly display the derivative work(s) embedding the Script to User's clients for the



client's own internal use. All rights not specifically granted in this Agreement are reserved to ESRI. In the event User transfers a copy of the unmodified Script to another party, User expressly agrees to always include this Agreement file with all copies of the unmodified Script. Copyright The Script is owned by ESRI and is protected by United States copyright laws and applicable international laws, treaties, and/or conventions. The following ESRI attribution information must be given in comment form in the Script, in an "Help-About" dialog box, in a supporting digital "Read Me" file, and/or provided in digital form for on-line documentation, and at the beginning or end acknowledgment page of any hard-copy documentation: "Portions of this work include intellectual property of Environmental Systems Research Institute, Inc. and are used herein with permission. Copyright (C) [Insert year(s)] Environmental Systems Research Institute, Inc. All rights reserved." The parties mutually agree that User may make an application for copyright registration in the derivative work(s) prepared by User based on the preexisting Script so long as User identifies and discloses all respective ownership rights in preexisting material(s) that comprise User's derivative work(s) in section 6, Derivative or Compilation on Form TX and/or any other applicable form(s) of the United States Copyright Office or the applicable forms in other legal jurisdictions. Disclaimer of Warranty User expressly acknowledges that the Script is unsupported scripting code and that no technical support shall be provided to User by ESRI. THE SCRIPT IS PROVIDED "AS-IS," WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, BY STATUTE OR OTHERWISE, INCLUDING, BUT NOT LIMITED TO ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. ESRI DOES NOT WARRANT THAT THE OPERATION OF THE SCRIPT SHALL BE UNINTERRUPTED OR ERROR FREE. USER BEARS ALL RISK AS TO THE QUALITY AND PERFORMANCE OF THE SCRIPT. Exclusive Remedy and Limitation of Liability The parties expressly agree that ESRI's liability hereunder for any damages to User, regardless of the form of action, shall not exceed the total amount paid for the license granted herein. IN NO EVENT SHALL ESRI BE LIABLE TO USER FOR COSTS OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOST SALES OR BUSINESS EXPENDITURES, INVESTMENTS, OR COMMITMENTS IN CONNECTION WITH ANY BUSINESS, LOSS OF ANY GOODWILL, OR FOR ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT OR USE OF THE SCRIPT, HOWEVER CAUSED, ON


May 2007 182

ANY THEORY OF LIABILITY, AND WHETHER OR NOT ESRI HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. THESE LIMITATIONS SHALL APPLY NOTWITHSTANDING ANY FAILURE OF ESSENTIAL PURPOSE OF ANY LIMITED REMEDY. Governing Law This license is governed by the laws of the United States of America and the state laws of California without reference to conflict of laws principles. Entire Agreement The parties agree that this Agreement constitutes the sole and entire agreement of the parties as to the matter set forth herein and supersedes any previous agreements, understandings, and arrangements between the parties relating hereto when User assents to be bound by these terms and conditions by using the Script. ConvertAPDM3to4 Option Explicit Option Compare Text Public Sub Test_Convert() 'Pass the data source string to the main subroutine. (Must be changed for ArcSDE.) Run_Convert "C:\EIM\APDM_PDM_041211.mdb" End Sub Private Sub Run_Convert(strMDBFile As String) On Error GoTo ErrorHandler 'Connect to the geodatabase. For ArcSDE, this must be modified. Dim pWSF As IWorkspaceFactory Set pWSF = New AccessWorkspaceFactory Dim pW As IWorkspace Set pW = pWSF.OpenFromFile(strMDBFile, 0) Dim pFW As IFeatureWorkspace Set pFW = pW 'Spin through every geodatabase object and change the word Activity to Audit wherever the class name ends in Activity. Dim i As Long, j As Integer Dim pEnumDS As IEnumDataset Dim pDS As IDataset Set pEnumDS = pW.Datasets(esriDTAny) pEnumDS.Reset



Set pDS = pEnumDS.Next Dim strDS As String Dim strNewDS As String 'Define classes to exclude. For instance, the ACTIVITY object class will be excluded. Const EXCLUDE_TABLES = "|ACTIVITY|OTHERTABLE" Do While Not pDS Is Nothing strDS = pDS.Name 'Check for the word Activity (as in <class>Activity). If Right(strDS, Len("Activity")) = "Activity" And InStr(EXCLUDE_TABLES, "|" & strDS) = 0 Then 'Change Activity to Audit… strNewDS = Replace(strDS, "Activity", "Audit") If pDS.CanRename Then Debug.Print "DETECTED->" & strDS & " RENAMED->" & strNewDS pDS.Rename strNewDS Else Debug.Print "DETECTED->" & strDS & " COULD NOT RENAME!" End If End If Set pDS = pEnumDS.Next Loop 'Spin through the relationship classes, looking for M-N classes containing a foreign key field with a name of the form <class>ActivityEventID. Set pEnumDS = pW.Datasets(esriDTRelationshipClass) pEnumDS.Reset Dim pRC As IRelationshipClass Set pDS = pEnumDS.Next 'Define fields to exclude from processing. (For instance, ActivityEventID will not be processed.) Const EXCLUDE_FIELDS = "|ActivityEventID|OtherFields"


May 2007 184

Dim bCopyRC As Boolean Do While Not pDS Is Nothing 'Check to see if this is an M-N attributed relationclass. If TypeOf pDS Is ITable Then 'QI to IRelationshipClass Set pRC = pDS Debug.Print "PROCESSING " & pDS.Name 'Open up table Dim pTable As ITable Set pTable = pDS bCopyRC = False Dim strNewField As String Dim strOldField As String Dim pNewField As IFieldEdit Dim pField As IField 'Check for the <class>ActivityEventID field. For i = 0 To pTable.Fields.FieldCount - 1 Set pField = pTable.Fields.Field(i) strOldField = pField.Name If InStr(strOldField, "ActivityEventID") > 0 And InStr(EXCLUDE_FIELDS, "|" & strOldField) = 0 Then bCopyRC = True Exit For End If Next 'Re-create the M-N relationship class with the desired new name. If bCopyRC Then Debug.Print "----CREATING NEW RELATIONSHIPCLASS" 'The new field name strNewField = Replace(strOldField, "ACTIVITY", "AUDIT") Dim pOldFieldsEdit As IFields



Dim pNewFieldsEdit As IFieldsEdit Set pNewFieldsEdit = New esrigeodatabase.Fields Set pOldFieldsEdit = pTable.Fields For j = 0 To pOldFieldsEdit.FieldCount - 1 If pOldFieldsEdit.Field(j).Name <> strOldField Then pNewFieldsEdit.AddField pOldFieldsEdit.Field(j) Else Set pField = pOldFieldsEdit.Field(j) 'Re-create this field Set pNewField = New esrigeodatabase.Field 'Copy field parameters to the new field With pNewField .Name = strNewField .AliasName = Replace(pField.AliasName, "ACTIVITY", "AUDIT") .Type = pField.Type .Length = pField.Length .Precision = pField.Precision End With pNewFieldsEdit.AddField pNewField End If Next 'Rename the relationship class strDS = Replace(pDS.Name, "Activity", "Audit") Dim pNewRC As IRelationshipClass 'Add _TMP to the new relationship class name, when the old relationship class is deleted, the _TMP will be removed. Set pNewRC = pFW.CreateRelationshipClass(strDS & "_TMP", pRC.OriginClass, pRC.DestinationClass, pRC.ForwardPathLabel, pRC.BackwardPathLabel, pRC.Cardinality, pRC.Notification, pRC.IsComposite, pRC.IsAttributed, pNewFieldsEdit, _ Replace(pRC.OriginPrimaryKey, strOldField, strNewField), _ Replace(pRC.DestinationPrimaryKey, strOldField, strNewField), _ Replace(pRC.OriginForeignKey, strOldField, strNewField), _ Replace(pRC.DestinationForeignKey, strOldField, strNewField)) Debug.Print "--------OPK->" & pNewRC.OriginPrimaryKey Debug.Print "--------OFK->" & pNewRC.OriginForeignKey Debug.Print "--------DPK->" & pNewRC.DestinationPrimaryKey


May 2007 186

Debug.Print "--------DFK->" & pNewRC.DestinationForeignKey 'Dump data across from the old relationship class to the new relationship class. Dim pSourceCur As ICursor Set pSourceCur = pTable.Search(Nothing, True) Dim pSourceRow As IRow Set pSourceRow = pSourceCur.NextRow Dim pNewTable As ITable Set pNewTable = pNewRC Dim pNewCur As ICursor Dim pNewRB As IRowBuffer Set pNewCur = pNewTable.Insert(True) Set pNewRB = pNewTable.CreateRowBuffer If Not pSourceRow Is Nothing Then Debug.Print "-------COPYING RECORDS" End If Dim iPos As Long iPos = 1 Do While Not pSourceRow Is Nothing 'If there is an error, do not add this row. On Error Resume Next For j = 0 To pNewTable.Fields.FieldCount - 1 'Do not copy over non-editable fields (i.e. RID). If pNewRB.Fields.Field(j).Editable Then pNewRB.Value(j) = pSourceRow.Value(j) End If Next If Err.Number = 0 Then pNewCur.InsertRow pNewRB Else Debug.Print "----------ERROR COPYING SOURCE OID->" & pSourceRow.OID & " " & Err.Description Err.Clear Resume End If



'Commit every 500 records. If iPos Mod 500 = 0 Then pNewCur.Flush End If iPos = iPos + 1 Set pSourceRow = pSourceCur.NextRow Loop 'Back to original errorHandling. On Error GoTo ErrorHandler 'Commit remaining. pNewCur.Flush 'Release objects. Set pSourceCur = Nothing Set pNewCur = Nothing 'Delete the old relationship class. pDS.Delete 'Rename the new relationship class. Set pDS = pNewRC pDS.Rename strDS End If End If 'Next relationship class. Set pDS = pEnumDS.Next Loop MsgBox "Done" Exit Sub ErrorHandler: MsgBox "ProcessError() " & Erl & "-" & Err.Description End Sub

arcgis pipeline data model version 4.0 - magpie-inc.commagpie-inc.com › wp-content › uploads ›...

Documents