magpie-inc.commagpie-inc.com/wp-content/uploads/2013/10/20101103... · 11/3/2010 · table of...

APDM V5.0 Reference Guide

ArcGIS® Pipeline Data Model

Version 5.0.1 – Reference Guide

November 2010

ArcGIS Pipeline Data Model Version 5.0 Topic Page

November 2010 ii

Table of Contents Table of Contents............................................................................................ ii

List of Figures ............................................................................................. ix List of Tables .............................................................................................. ix

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 Standing Committee ...................................................................... 13 7.0 Difference Between a Standard and a Template ........................................ 14 8.0 Design Rationale – The Geodatabase ........................................................ 14

8.1 Structure .............................................................................................. 16 8.2 Domains .............................................................................................. 16

9.0 Core Elements ......................................................................................... 16 9.1 Stationing and Station Equations ........................................................... 17

9.1.1 Distance Based ............................................................................... 19 9.1.2 Arbitrary (Pseudo-distance Based) ................................................... 20

9.2 The Centerline (Routes, Measures, and Events) ...................................... 20 9.3 Hierarchy ............................................................................................. 21 9.4 Coincident Geometry ............................................................................ 22 9.5 Events Versus Features ......................................................................... 22 9.6 APDM Compliance ................................................................................ 23 9.7 Non Geometric Features ....................................................................... 25 9.8 Topology .............................................................................................. 30 9.9 Centerline ............................................................................................ 30

10.0 APDM Conceptual Model ........................................................................ 32 10.1 APDM Abstract Classes/Metadata Overview .......................................... 32 10.2 APDM Abstract Classes ........................................................................ 33

10.2.1 What is an abstract class? ............................................................. 34 10.2.2 Why are abstract classes used? ...................................................... 34 10.2.3 Duplication of Attributes within APDM abstract classes .................... 35 10.2.4 Inheritance (How to read the APDM Logical Model Poster) ............... 36 10.2.5 Abstract Class Definitions .............................................................. 40

10.2.5.1 APDMObject .......................................................................................... 43 10.2.5.2 ObjectArchive ......................................................................................... 44


ESRI Technical Paper iii

10.2.5.3 CenterlineObject ..................................................................................... 45 10.2.5.4 NonFacilityObject ................................................................................... 46 10.2.5.5 AuditObject ............................................................................................. 47 10.2.5.6 ActivityExtension ................................................................................... 48 10.2.5.7 FacilityObject .......................................................................................... 49 10.2.5.8 FeatureArchive ........................................................................................ 49 10.2.5.9 CenterlinePolyline................................................................................... 52 10.2.5.10 CenterlinePolylineEvent ....................................................................... 53 10.2.5.11 CenterlinePoint ..................................................................................... 54 10.2.5.12 OfflineFeature ....................................................................................... 55 10.2.5.13 OfflinePoint........................................................................................... 56 10.2.5.14 OfflineFacility ....................................................................................... 57 10.2.5.15 OfflineNonPointFacility ....................................................................... 58 10.2.5.16 OfflinePointFacility .............................................................................. 59 10.2.5.17 OnlineFeature ........................................................................................ 60 10.2.5.18 OnlinePolyline ...................................................................................... 61 10.2.5.19 OnlinePolylineForOfflineFeature ......................................................... 63 10.2.5.20 OnlinePoint ........................................................................................... 64 10.2.5.21 OnlinePointForOfflineFeature .............................................................. 65 10.2.5.22 OnlineFacility ....................................................................................... 66 10.2.5.23 OnlinePolylineFacility .......................................................................... 67 10.2.5.24 OnlinePointFacility ............................................................................... 68 10.2.5.25 Fitting .................................................................................................... 69

10.3 APDM Metadata .................................................................................. 70 10.3.1 Class-level Metadata...................................................................... 71

10.3.1.2 ClassMetaData ........................................................................................ 71 10.3.1.3 OnlineLocationClass ............................................................................... 72 10.3.1.4 ReferenceMode ....................................................................................... 73

10.3.2 Feature-level Metadata .................................................................. 79 10.3.2.1 Online Event Feature-Level Metadata Attributes ................................... 79 10.3.2.2 ControlPoint Feature-Level Metadata Attributes.................................... 84

10.4 Additional Reference Modes ................................................................ 92 10.4.1 Inherited Reference Mode Root Names........................................... 92 10.4.2 Continuous Measure and Engineering Stationing ............................. 97

10.5 Removing AltRefMeasure Object Class ............................................... 104 10.6 Merging Control Points ...................................................................... 104

11.0 Core Object and Feature Classes .......................................................... 107 11.1 APDM Core Classes and Relationships ................................................ 107

11.1.1 EventID ...................................................................................... 111 11.1.2 Core Object Classes .................................................................... 111

11.1.2.1 Activity ................................................................................................. 111 11.1.2.2 ActivityHierarchy ................................................................................. 112


November 2010 iv

11.1.2.3 <class name>Audit ............................................................................... 114 11.1.2.4 Company ............................................................................................... 115 11.1.2.5 ExternalDocument ................................................................................ 116 11.1.2.6 LineLoop ............................................................................................... 117 11.1.2.7 LineLoopHierarchy ............................................................................... 121 11.1.2.8 OwnerOperator ..................................................................................... 123 11.1.2.9 Product .................................................................................................. 123 11.1.2.10 Site ...................................................................................................... 124 11.1.2.11 SubSystem........................................................................................... 125 11.1.2.12 SubSystemHierarchy........................................................................... 128

11.2.1 Core Feature Classes ................................................................... 130 11.2.1.1 ControlPoint .......................................................................................... 130 11.2.1.2 StationSeries ......................................................................................... 134 11.2.1.3 SubSystemRange .................................................................................. 136

11.2 APDM Core Domains ......................................................................... 138 11.2.1 gnOperationalStatus .................................................................... 138 11.2.2 gnStatus ..................................................................................... 139 11.2.3 clStationEditResponse ................................................................. 140 11.2.4 clXYEditResponse ........................................................................ 140 11.2.5 clZEditResponse .......................................................................... 140 11.2.6 gnOnlineLocationMechanism ........................................................ 141 11.2.7 gnHistoricalState ......................................................................... 141 11.2.8 gnAngle ...................................................................................... 141 11.2.9 clEditResponse ............................................................................ 141 11.2.10 gnAPDMClassType ..................................................................... 142 11.2.11 gnRefModeBasis ........................................................................ 142 11.2.12 gnRefModeType ........................................................................ 143 11.2.13 gnRefModeUnits ........................................................................ 143 11.2.14 gnYesNo ................................................................................... 143 11.2.15 gnRequiresGeometry ................................................................. 144

12.0 Implementation ................................................................................... 144 12.1 The APDM and ‘Inline’ History ........................................................... 145

12.1.1 Inline History Implementation ...................................................... 146 11.2 Using the APDM in a Versioned Geodatabase Environment .................. 149 11.3 Features as Events, Events as Features .............................................. 150 11.4 Topology and the Geometric Network ................................................ 150 11.5 Developing Applications .................................................................... 152 11.6 The APDM and Other Pipeline Data Models ......................................... 152 11.7 Conversion To/From PODS and ISAT ................................................. 153 11.8 Getting Data into the Model............................................................... 153

13.0 Optional Object and Feature Classes ..................................................... 155 13.1 Centerline and Hierarchy Classes .................................................... 155


ESRI Technical Paper v

13.1.1 SitePoint ................................................................................................... 155 13.1.2 SiteBoundary............................................................................................ 155

13.2 Facilities Classes ............................................................................ 156 13.2.1 Appurtenance ........................................................................................... 156 13.2.2 Casing ...................................................................................................... 156 13.2.3 Closure ..................................................................................................... 157 13.2.4 Coating ..................................................................................................... 158 13.2.5 Elbow ....................................................................................................... 159 13.2.6 Instrument ................................................................................................ 160 13.2.7 Meter ........................................................................................................ 161 13.2.8 PigStructure.............................................................................................. 162 13.2.9 PipeJoinMethod ....................................................................................... 163 13.2.10 PipeSegment .......................................................................................... 164 13.2.11 Reducer .................................................................................................. 166 13.2.12 Sleeve ..................................................................................................... 167 13.2.13 Tap ......................................................................................................... 168 13.2.14 Tee.......................................................................................................... 169 13.2.15 Valve ...................................................................................................... 170 13.2.16 ValveOperator ........................................................................................ 171 13.2.17 Vessel ..................................................................................................... 172 13.2.18 Well ........................................................................................................ 172

13.3 Operations Classes ......................................................................... 173 13.3.1 ElevationPoint .......................................................................................... 173 13.3.2 FieldNote.................................................................................................. 174 13.3.3 FieldNoteLocation ................................................................................... 175 13.3.4 Marker ...................................................................................................... 175 13.3.5 MarkerLocation........................................................................................ 176 13.3.6 OnlineFieldNote ....................................................................................... 176 13.3.7 OperatingPressure .................................................................................... 177 13.3.8 PressureTest ............................................................................................. 178 13.3.9 RightOfWay ............................................................................................. 179

13.4 Event Support Classes .................................................................... 180 13.4.1 Address .................................................................................................... 180 13.4.2 AlignmentSheet........................................................................................ 180 13.4.4 Contact ..................................................................................................... 181 13.4.5 DocumentPoint ........................................................................................ 182 13.4.6 GeoMetaData ........................................................................................... 183 13.4.7 InstrumentParameter ................................................................................ 184 13.4.8 RemovedLine ........................................................................................... 185 13.4.8 RemovedPoint .......................................................................................... 186

13.5 Integrity Classes ............................................................................ 186 13.5.1 ClusterBuffer............................................................................................ 189 13.5.2 CouldAffectSegment................................................................................ 189


November 2010 vi

13.5.3 DOTClass ................................................................................................. 190 13.5.4 DOTClassCorridor ................................................................................... 191 13.5.5 DOTClassSegment ................................................................................... 191 13.5.6 HCACorridor ........................................................................................... 193 13.5.7 HCARange ............................................................................................... 193 13.5.8 HCASegment ........................................................................................... 194 13.5.9 HighConsequenceArea ............................................................................ 195 13.5.10 RiskAnalysis .......................................................................................... 196

13.6 Inspection Classes ......................................................................... 197 13.6.1 Anomaly ................................................................................................... 197 13.6.2 AnomalyCluster ....................................................................................... 199 13.6.3 InspectionRange ....................................................................................... 200 13.6.4 Leak.......................................................................................................... 200

13.7 Encroachments Classes .................................................................. 201 13.7.1 StructureOrIDSite .................................................................................... 204 13.7.2 NearestPointToLine ................................................................................. 206 13.7.3 IDSiteArea ............................................................................................... 206 13.7.4 StructureLocation ..................................................................................... 207 13.7.5 StructureOutline ....................................................................................... 207 13.7.6 LineCrossing ............................................................................................ 208 13.7.7 LineCrossingEasement ............................................................................ 209 13.7.8 LineCrossingLocation .............................................................................. 209

13.8 Cathodic Protection Classes ............................................................ 210 13.8.1 CPAnode .................................................................................................. 210 13.8.2 CPBond .................................................................................................... 211 13.8.3 CPCable ................................................................................................... 211 13.8.4 CPGroundBed .......................................................................................... 212 13.8.5 CPLocation .............................................................................................. 213 13.8.6 CPRectifier ............................................................................................... 214 13.8.7 CPTestStation .......................................................................................... 215

13.9 Reading Classes ............................................................................. 215 13.9.1 CIS Reading ............................................................................................. 215 13.9.2 MeterReading ........................................................................................... 216

14.0 Attributed Relationship Classes ............................................................. 218 <class name>Contact .......................................................................................... 218 ContactAddress ................................................................................................... 218

Appendix A - Standards and Conventions ..................................................... 218 A.1 Naming Conventions ........................................................................... 218

A.1.1 Class Names ................................................................................. 219 A.1.2 Foreign Keys ................................................................................ 219

A.2 Use of Feature Datasets ...................................................................... 220 A.3 Maximum String Size .......................................................................... 220 A.4 Documentation Standards ................................................................... 221


ESRI Technical Paper vii

A.4.1 Object or Feature Class ................................................................. 221 A.4.2 Attributed Relationship Class ......................................................... 222

Appendix B – Change Log 4.0 to 5.0 ............................................................ 224 B.1 Model Changes from 4.0 to 5.0 (Synopsis) ........................................... 224 B.2 Model Changes from APDM 4.0 to APDM 5.0 (Detailed) ........................ 225

B.2.1 Domains ....................................................................................... 225 B.2.1.1 Convert string domains to String Coded Value domains ....................... 225 B.2.1.2 Added clRefMode domain ..................................................................... 225 B.2.1.3 Rename Domains - Move PipeFunction to LineFunction ...................... 225

B.2.2 Changes to Abstract Classes and Meta Data Tables ......................... 226 B.2.2.1 Converted EventID to esriTypeGUID. Added GlobalID field as GlobalID.............................................................................................................................. 226 B.2.2.2 Long Integer Precision has been set to 9. ............................................... 227 B.2.2.3 Create an Activity Extension Abstract Class – (added as child of Non-Facility Object) ................................................................................................... 227 B.2.2.4 Created AuditObject Abstract Class containing: ................................... 227 B.2.2.5 Created ActivityEvent Abstract Class containing: ................................. 228 B.2.2.6 Segregated Specification Field for Fittings ............................................ 228 B.2.2.7 Added XYZ Coordinate Attributes ........................................................ 228 B.2.2.8 Add Alternate Reference Mode station values ....................................... 228 B.2.2.9 Deleted the AltRefMeasure object class ................................................ 229 B.2.2.10 Removed GroupEventID field from Abstract Classes ......................... 230 B.2.2.11 Deleted StationSeries and ControlPoint Subtypes ............................... 230 B.2.2.12 Renamed APDMClass table to ClassMetaData. .................................. 230 B.2.2.13 Moved META Classes to EventSupport Static Structure Diagram ..... 230 B.2.2.14 Rebuilt Reference Mode Table ............................................................ 231

B.2.2 Concrete Class Modifications .......................................................... 231 B.2.2.1 Change domain fcNotApplicable default value. .................................... 231 B.2.2.2 Segregated Specification Field for Fittings ............................................ 231 B.2.2.3 Merged Control Points ........................................................................... 232 B.2.2.4 Renamed PipeFunction to LineFunction ................................................ 232 B.2.2.5 Turn Site into an Object Class................................................................ 233 B.2.2.6 Keep SitePoint and add SiteBoundary ................................................... 233 B.2.2.7 PipeSegment ........................................................................................... 233 B.2.2.7 Valve Information .................................................................................. 233 B.2.2.8 Added OnlineFieldNote ......................................................................... 233 B.2.2.9 Modification to StructureOrIDSite......................................................... 234 B.2.2.10 Modifications to DOTClass ................................................................. 234 B.2.2.11 Modifications to HCARange ................................................................ 234 B.2.2.12 Modifications to HCASegment ............................................................ 234 B.2.2.12 Converted Subtypes to Type fields with Domains ............................... 235

B.2.3 Concrete Class Additions ............................................................... 235


November 2010 viii

B.2.3.1 Well ........................................................................................................ 235 B.2.3.2 ClusterBuffer .......................................................................................... 235 B.2.3.3 DOTClassCorridor ................................................................................. 235 B.2.3.4 DOTClassSegment ................................................................................. 236 B.2.3.5 HCACorridor .......................................................................................... 236

B.2.4 Relationship Modifications ............................................................. 236 B.2.4.1 Dropped relationship between ReferenceMode and ControlPoint ......... 236 B.2.4.2 Relationships between ReferenceMode and StationSeries .................... 236 B.2.4.3 Change in LineLoop/OwnerOperator relationship. ................................ 236 B.2.4.4 Fixed and added relationship classes: .................................................... 236 B.2.4.5 Dropped relationships between concrete classes and AltRefMeasure ... 236

Appendix C – Example GCS Spatial Reference ............................................... 238 C.1 Spatial Reference Parameters for GCS Version of APDM ........................ 238

Appendix D - Glossary ................................................................................. 238 A ............................................................................................................. 238 B ............................................................................................................. 240 C ............................................................................................................. 240 D ............................................................................................................ 244 E ............................................................................................................. 246 F ............................................................................................................. 247 G............................................................................................................. 248 H ............................................................................................................ 249 I.............................................................................................................. 250 J ............................................................................................................. 251 K ............................................................................................................. 251 L ............................................................................................................. 252 M ............................................................................................................ 253 N............................................................................................................. 255 O ............................................................................................................ 255 P ............................................................................................................. 258 Q ............................................................................................................ 259 R ............................................................................................................. 259 S ............................................................................................................. 261 T ............................................................................................................. 263 U ............................................................................................................. 264 V ............................................................................................................. 264 W ............................................................................................................ 265 X ............................................................................................................. 265 Y ............................................................................................................. 265 Z ............................................................................................................. 265

ArcGIS Pipeline Data Model Version 5.0

ESRI Technical Paper ix

List of Figures Figure 1 – Non-Geometric Features (Sites) ...................................................................... 29 Figure 2 – Non Geometric Features (Offlne/Online) ........................................................ 30 Figure 3 – High Level APDM Abtract Class Hierarchy ................................................... 37 Figure 4 – Example APDM Inheritance ........................................................................... 39 Figure 5 – APDM 5.0 Abstract Classes (Page 1).............................................................. 41 Figure 6 – APDM 5.0 Abstract Classes (Page 2).............................................................. 42 Figure 7 – Reference Mode Basis ..................................................................................... 76 Figure 8 – Uninterrupted and Adjustable – Continuous Stationing .................................. 78 Figure 9 – Interrupted and Not-adjustable (Engineering Stationing) ............................... 79 Figure 10 – CL Edit Response (Part 1) ............................................................................. 81 Figure 11 – CL Edit Response (Part 2) ............................................................................. 83 Figure 12 – CL XY Edit Response ................................................................................... 86 Figure 13 – CL Station Edit Response .............................................................................. 88 Figure 14 – CL Z Edit Response....................................................................................... 90 Figure 15 – CL Control ..................................................................................................... 91 Figure 16 – Online Polygline and Online Point related to StationSeries .......................... 96 Figure 7 ............................................................................................................................. 97 Figure 8 ........................................................................................................................... 102 Figure 9 ........................................................................................................................... 105 Figure 10 ......................................................................................................................... 106 Figure 11 ......................................................................................................................... 109 Figure 12 ......................................................................................................................... 110 Figure 13 ......................................................................................................................... 119 Figure 14 ......................................................................................................................... 120 Figure 15 ......................................................................................................................... 127 Figure 16 ......................................................................................................................... 127 Figure 17 ......................................................................................................................... 132 Figure 18 ......................................................................................................................... 133 Figure 19 ......................................................................................................................... 133 Figure 20 ......................................................................................................................... 137 Figure 21 ......................................................................................................................... 188 Figure 22 ......................................................................................................................... 202 Figure 23 ......................................................................................................................... 203 List of Tables Table 2 .............................................................................................................................. 97 Table 3 .............................................................................................................................. 99 Table 4 ............................................................................................................................ 100 Table 5 ............................................................................................................................ 102 Table 6 ............................................................................................................................ 103

ArcGIS Pipeline Data Model Version 5.0

November 2010 x

Table 7 ............................................................................................................................ 104 Table 8 ............................................................................................................................ 120 Table 9 ............................................................................................................................ 122 Table 10 .......................................................................................................................... 128 Table 11 .......................................................................................................................... 130 Table 12 .......................................................................................................................... 137 Table 2 ............................................................................................................................ 138 Table 14 .......................................................................................................................... 221

November 2010

APDM V5.0 Reference Guide 1

Forward Several changes have taken place in the APDM Organization over the past few years. The Steering and Technical committees have been merged to form a single ‘Standing Committee’. This committee, comprised of operators and vendors, is now charged with the maintenance of the ArcGIS Pipeline Data Model (APDM), the documentation describing the model, and the update of the web page portal for the model (www.apdm.net) under the leadership and guidance of Environmental Systems Research Institute (ESRI). This documentation represents the combination of the original core and optional class documents for APDM 4.0 into a single ‘Reference Guide’ for APDM 5.0. It has always been the intent of the APDM Standing Committee to keep pace with the technology released by 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 5.0 represents a significant step forward from the APDM Version 5.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 was to define, capture and store the ‘behavior’ of pipeline systems, particularly that of reference modes (stationing) and response to ‘centerline’ editing. Version 4.0 is designed to take advantage of ArcGIS 9.2 technology. Version 5.0 refined further the behaviors documented in Version 4.0 and involves substantial ‘paring’ down of core behaviors into a simpler model. Version 5.0 has been designed for release with ArcGIS 9.3.1 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 4.0 is still the ‘core’ in the APDM 5.0. Core refers to those schema items that are required. The abstract classes denote the set of ‘required’ attributes, domains and relationships that make an APDM 5.0 model compliant. The APDM 5.0 abstract classes are slightly expanded and refined in comparison to Version 4.0. The reference guide, the logical model diagram and the physical Unified Modeling Language (UML) model have all been re-worked to consistently reflect the ‘compliance’

http://www.apdm.net/

ArcGIS Pipeline Data Model Version 5.0 November 2010

November 2010 2

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 5.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. 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 Standing committee. 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 Standing Committee. July, 2010



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 included as implementation examples in this document, 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.


November 2010 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 Standing committee. This document originally represented ‘Core Class’ description and the ‘Optional Classes’ data dictionary as defined in the APDM v5.0 Logical Model Poster. Instead of two different documents, all classes – core and optional are provided in this ‘Reference Guide’ Note that the ‘optional’ classes are still intended to provide a sample set of classes that could be implemented ‘as-is’ or modified to suit the specific business purposes of a pipeline operating company.



1.0 Introduction This reference guide 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 includes the description of the abstract and core classes of the APDM; and provides a data dictionary of the optional classes that are distributed as implementation examples in the Logical Data Model Poster and the Full Physical Model Visio UML diagram. 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 the APDM Standing committee under the umbrella of ESRI. The Standing 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 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.



November 2010 6

The APDM is designed as a starting point. It is neither the purpose nor the focus of the APDM standing 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 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.


November 2010 8

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


November 2010 10

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


November 2010 12

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 by the ESRI APDM Standing committee. The standing committee is responsible for developing the structure, content, and technological aspects of the model. The standing committee is responsible for the organizational/promotional aspects of the model. Ultimately the APDM Standing Committee falls 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 standing committee strives 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). • September 2009 – The APDM Technical and APDM Steering Committees are

merged to form the APDM Standing Committee. • November 2009 – The first draft of the APDM v5.0 is released to the APDM

Standing Committee for internal review. • April 2010– The first draft of the APDM v5.0 is released to the APDM Standing

Committee for internal review. • November 2010 – The final draft of the APDM v5.0 Reference Guide is released

documenting the Core and Abstract APDM Classes and the change log from Version 4.0 to Version 5.0.

5.0 APDM Standing Committee The APDM Standing committee is a ten (10) person committee comprised of pipeline operators and vendors. The committee is charged with setting the organizational direction of the APDM within the context of the pipeline industry and developing the technical content of the APDM model. The committee meets three times per year at the following conferences:

• The ESRI Petroleum User Group Conference (PUG) (Spring), • The Annual ESRI International User Conference (Summer) • The GITA Oil & Gas Conference (Fall).




November 2010 14

The Standing committee will organize an open forum at each of these venues for discussion of, and collaboration on, the model. The APDM website (www.apdm.net) will be the forum for advertising upcoming APDM Standing Committee forums. 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 Standing committee. The positions on the APDM Standing committee are elected by members of the ESRI Pipeline Interest Group (PIG). Contact Robert Brook at [email protected], or any APDM Standing committee member for more information on serving on the APDM Standing committee. The APDM standing committee meets three times per year, at the following venues, to discuss proposed improvements and alterations to the model.

• ESRI Petroleum User Group Meeting (Spring) • APDM User Group Meeting at the ESRI User Conference (Summer)

• GITA Oil and Gas Conference (Fall)

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

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

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 Geodatabase 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


mailto:[email protected]

mailto:[email protected]



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

1 The APDM standing 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.


November 2010 16

8.1 Structure The APDM contains one feature dataset named Transmission. The standing 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. 8.2 Domains The example domains provided with the model are designed to contain common values found in most pipeline systems. The purpose of these domains is to provide common values that are representative of the attributes they are populating. The provided domain values are not an attempt to provide a comprehensive or universal listing of values. The domain names in the model are prefaced with a two-letter designation that denotes the organizational category to which the domain belongs: gn (generic– domains that are applied to object classes and many different feature classes across the model), cp (cathodic protection domains), op (domains applied to feature classes pertaining to pipeline operations), en (domains applied to feature classes modeling encroachments to the pipeline), fc (domains applied to facility feature classes), cl (domains applied to centerline feature and object classes), and in (domains applied to inspection feature classes). 9.0 Core Elements The prime object of the standing 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. 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


November 2010 18

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.

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


November 2010 20

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


November 2010 22

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 11.2.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 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. 9.6 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 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.


November 2010 24

• 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. 9.7 Non Geometric Features APDM 5.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.


November 2010 26

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


November 2010 28

is not slaved directly to the pipeline centerline (and hierarchy) by virtue of not 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 5.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:



Figure 1 – Non-Geometric Features (Sites)


November 2010 30

Figure 2 – Non Geometric Features (Offlne/Online)

9.8 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. 9.9 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.


November 2010 32

• Each control point must belong to one and only one station series of the same reference mode.

• 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.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. 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 Standing committee has 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 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.


November 2010 34

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 Standing committee expended considerable effort in defining the APDM abstract classes for version 5.0. The APDM 5.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 5.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 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


November 2010 36

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.



APDMObject

Object

ObjectArchive

CenterlineObject NonFacilityObject

LineLoopSubSystem

Feature

FeatureArchive

Object

CenterlinePolyline

CenterlinePolylineEvent

StationSeries

CenterlinePoint

ControlPoint

OnlineFeatureOfflineFeature OfflineFacility

Site

OfflinePointFacility

OfflinePoint

OnlineFacility

OnlinePointFacility

Fitting

OnlinePolylineFacility

OnlinePolyline

OnlinePoint

OnlinePointForOfflineFeature

OnlinePolylineForOfflineFeature

StationSeries

StationSeries

Site

<OnlineFeature>

Object

ReferenceMode ClassMetaData OnlineLocationClasses

Metadata

OfflineNonPointFacility

Site

StationSeries

APDM Abstract Classes

SubSystemRange

ActivityCompanyExternalDocumentOwnerOperator

ESRI Simple Object

Relationship Wormhole

Inheritance

Relationship Cardinality

APDM Abstract Class

APDM Core Class

ActivityHierarchyLineLoopHierarcySubSystemHierarchy

FacilityObject

ObjectArchive

AuditObject

<fc>Audit

AuditObject

Figure 3 – High Level APDM Abtract Class Hierarchy


November 2010 38

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.



StationSeries

Example of APDM Inheritance

ESRI Simple Object


Inheritance


APDM Abstract Class

APDM Concrete Class

Shape

[Feature]

CreatedByCreatedDateEffectiveFromDateEffectiveToDateEventID (pk)GlobalIDHistoricalState <d>LastModifiedModifiedByOriginEventIDProcessFlagRemarks

[FeatureArchive]

OBJECTID

[Object]

CLEditResponse <d>CLValidityToleranceRouteEventID (fk)

OnlineFeature

InstallationDateInServiceDateOperationalStatus <d>SiteEventID (fk)

OnlineFacility

MeasureStationSymbolRotationPOINT_XPOINT_YPOINT_ZSeriesEventID (fk)

OnlinePointFacility

DateManufacturedGradeInletConnectionType <d>InletDiameter <d>InletWallThickness <d>Manufacturer <d>Material <d>PressureRating <d>

Fitting

StationSeries

Site

Elbow

ElbowAngle <d>ElbowRadius <d>

DateManufacturedGradeInletConnectionType <d>InletDiameter <d>InletWallThickness <d>Manufacturer <d>Material <d>PressureRating <d>Specification <d>

MeasureStationSymbolRotationPOINT_XPOINT_YPOINT_ZSeriesEventID (fk)

InstallationDateInServiceDateOperationalStatus <d>SiteEventID (fk)

CLEditResponse <d>CLValidityToleranceRouteEventID (fk)

CreatedByCreatedDateEffectiveFromDateEffectiveToDateEventID (pk)HistoricalState <d>LastModifiedModifiedByOriginEventIDProcessFlagRemarks

Shape

OBJECTID

Elbow

StationSeries

Site

Registered classes in the geodatabase

must have an Object ID Field

Feature classes must have a geometry field

These fields are used for tracking inline

history and for archiving. Each field

as a particular purpose.

The feature class is an online feature and is primarily located by

stationed position (indicated by the the

relationships to StationSeries and

AltRefMeasure). This feature will respond to edits on the centerline

using values stored in the CLEditResponse and CLValidityTolerance

fields.

These attributes indicate that the feature class is

going to store facility objects that are installed and put into service. The

relationship to Site allows the feature to be stored

without geometry.

The concrete class (Elbow) will store a point feature and needs only a

single station value.

An elbow is considered a fitting and inherits the

standard attributes that describe the physical

aspects of a fitting.

The elbow feature class is a concrete

implementation of the APDM abstract class

inheritance tree.

Elbows are modeled in this APDM as a M-Aware Point Feature Class.

This feature class inherits all the attributes and relationships from it’s ancestor or parent APDM abstract classes.

Additional attributes can be added to this class for describing or defining the features in this class as unique instances of elbows.

Attributes and relationships inherited from APDM abstract class must be implemented without alteration to names or cardinality.

Note: Diagramming the APDM abstract classes in this manner

reduces redundancy in the depiction of attributes for each concrete class

in the logical model diagram.

The Elbow feature class will appear in the APDM geodatabase

with the following attributes and

relationships having inherited them from a set of APDM abstract

classes.

StationSeries

Figure 4 – Example APDM Inheritance

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


November 2010 40

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 later in this document. 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 are outlined in Appendix A



Figure 5 – APDM 5.0 Abstract Classes (Page 1)


November 2010 42

Figure 6 – APDM 5.0 Abstract Classes (Page 2)



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) – A unique identifier for the class. GlobalID (GUID) – 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 unique identifier containing a GUID value (esriFieldtypeGUID). 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 within the geodatabase and is independent of the feature or object class to which it belongs. The GlobalID (esriTypeGlobalID) is used as a unique identifier for features and classes across geodatabases. The GlobalID’s are used in tracking one-way and two-way geodatabase replication. 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 unique 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).


November 2010 44

10.2.5.2 ObjectArchive

Class Name: ObjectArchive Feature Class


APDM Inheritance:

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



OriginEventID (GUID) – 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 (String, 30) 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)


November 2010 46

LineLoop (Child - Core) SubSystem (Child - Core)



OperationalStatus (String, 30) 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 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.). 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)

Attributes: Status (String, 30) gnStatus (required APDM domain) – Defines the



(name, type, length, precision, scale, domain, description) 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 AuditObject

Class Name: AuditObject Feature Class

Geometry: Implemented as an Object Class.

APDM Inheritance:

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

Attributes:

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 (GUID) – A foreign key to Activity storing the EventID of the activity with which this AuditObject record is associated.

<Class>EventID (GUID) – A foreign key to a parent object or feature class for which AUDIT information is tracked. Each parent object can have zero or more audit records describing the history and/or comments about the feature.

Relationships: <ParentClassName>Audit: Each <ParentClass> class may have 1:M <ParentClassName>Audit records.

<ParentClassName>AuditActivity: An Activity (Core) is optionally 1:M with each <ParentClassName>Audit class.

<ParentClassName>Audit is optionall M-N with the ExternalDocument object class (Core)

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 a core construct if a


November 2010 48

class requires a M-N relationship with Activity or ExternalDocument. Audit classe are not required for a class to implement a relationship to the Activity Object Class. Feature and/or object classes can implement a direct M-1 relationship to Activity in the absence of an Audit class or when the feature/object is created directly as a result of an activity and will not have any historical or comments appeneded to that relationship (Eg. The features created as the results of RISK analysis are likely not to be modifed and are the direct result of a single activity). This example shows that a RiskResultsAudit class is NOT required. A pipe segment stored in the PipeSegment feature class will incur the effects of multiple activities through it’s lifespan including (by not limited to): installation, tested, put into service, multiple inspections, possible repairs and ultimately continued operation, removal, replacement or abandonment. In this case, the implementation of PipeSegmentAudit class acting as a intermediary table to the Activity object class is highly appropriate. If the Audit class is implemented it must inherit directly from the AuditObject abstract class. Note that it is acceptable to add organization specific attributes to the AuditObject abstract class or to each individual Audit class. In this manner specific attribution can be tracked when an activity occurs for a specific parent object or feature. 10.2.5.6 ActivityExtension

Class Name: ActivityExtension Feature Class

Geometry: Implemented as an Object Class.

APDM Inheritance:

ESRI Object APDM Object Object Archive NonFacilityObject ActivityExtension

Attributes:

ActivityEventID (GUID) – A foreign key to Activity storing the EventID of the activity with which this ActivityExtension record is associated.

Relationships: Activity<ExtensionClassName>: Activity (Core) is optionally 0..1 with the <ExtensionClassName> Activity Extention object class

SubTypes: -- The ActivityExtension object classes represent a singular type of entity within the APDM. The ActivityExtension object classes are physically implemented within the model and are implemented whenever an Activity class requires a relationship with a class that stores more information about a specific activity. The ActivityExtension class allows storage of additional attributes for a specific activity. These attributes are specific to the activity and would not be applicable for inclusion the actual Activity table itself. For example, the attributes that describe in detail a Inline Inspection Run may not be applicable to a Pipe Replacement activity. All classes describing activities with specific attributes must inherit from the ActivityExtension feature class.



10.2.5.7 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 (String, 30) 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 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, 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 facility 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.8 FeatureArchive

Class Name: FeatureArchive


November 2010 50

Feature Class Geometry:

Not Applicable.

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) – A unique identifier for the class. GlobalID (GUID) – A globally unique identifier for the class. OriginEventID (GUID) – 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 (String, 30) 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’ histories. 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: -- 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 unique identifier containing a GUID (esriTypeGUID) value. All feature classes and object classes within the APDM must have an attribute named EventID. The GlobalID (esriTypeGlobalID) is used as a unique identifier for features and classes across geodatabases. The GlobalID’s are used in tracking one-way and two-way geodatabase replication.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.


November 2010 52

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.9 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 (String, 30) 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.

BeginStation (Double, 15, 2) - Contains the measure value that is used to locate the starting point of the linear feature along the Engineering station series feature.

EndStation (Double, 15, 2) – Contains the measure value that is used to locate the ending point of the linear feature along the Engineering station series feature.

BeginMeasure (Double, 15, 2) – Contains the measure value that is used to locate the starting point of the linear feature along a Continuous station series feature.

EndMeasure (Double, 15, 2) – Contains the measure value that is used to locate the ending point of the linear feature along a Continuous station series feature.

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 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.10 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)



RouteEventID (GUID) – Foreign key to a Continuous station series feature in the StationSeries feature class.

BeginSeriesEventID (GUID) – Foreign key to an Engineering station series feature in the StationSeries feature class where the starting point of the linear feature is located.

EndSeriesEventID (GUID) – Foreign key to an Engineering station series feature in the StationSeries feature class where the ending point of the linear feature is located.

CLEditResponse (String, 30) 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’.


composite)

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

SubTypes: -- The CenterlinePolylineEvent APDM abstract class adds online polyline event attributes (BeginStationEventID, EndStationEventID and RouteEventID) 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


November 2010 54

abstract class by the absence of the InstallationDate and InServiceDate attributes. 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.11 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 (String, 30) 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 (String, 30) 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 (String, 30) 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 (String, 30) 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’.

MeasureValue (Double, 15, 2) – Contains the measure value that is used to locate the point feature along a Continuous station series feature.

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

Point_X (Double, 15, 2) – X axis (East-West) geographic coordinate of the Point feature.

Point_Y (Double, 15, 2) – Y axis (North-South) geographic coordinate of the Point feature.

Point_Z (Double, 15, 2) – Z axis (Elevation) measure of the Point



feature. RouteEventID (GUID) – Foreign key to a Continuous station series

feature in the StationSeries feature class. SeriesEventID (GUID) - The foreign key of the Station Series

feature to which the control point belongs. StationValue (Double, 15, 2) – Contains the measure value that is

used to locate the point feature along a Engineering station series feature.

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.12 OfflineFeature

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)


November 2010 56

StructureOutline – (Child - Example) IDSiteArea – (Child - Example)


domained, notes)

Status (String, 30) 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.13 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)



Point_Z (Double, 15, 2) – Z axis (Elevation) measure of the Point



feature. 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.14 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 (String, 30) 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


November 2010 58

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.15 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, 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 or in proximity to a Site. Once stored in a Site, the geometry for the features becomes optional. The Site object 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.16 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, 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’.

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)

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


November 2010 60

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.17 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’.

RouteEventID (GUID) – Foreign key to a Continuous station series feature in the StationSeries feature class.


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.18 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)

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

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



EndStation (Double, 15, 2) – A measure value along an


November 2010 62

Engineering station series used to position and locate the end of the linear feature.



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

StationLocated (String, 30) 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.).


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


November 2010 64

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. 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.20 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)

Measure (Double, 15, 2) – A measure value along an Engineering station series used to position and locate the point feature.

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

SeriesEventID (GUID) - The foreign key of the Station Series feature to which the control point belongs.




Point_Z (Double, 15, 2) – Z axis (Elevation) measure of the Point feature.

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)

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


November 2010 66

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 (String, 30) 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.).


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.22 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 (String, 30) 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, 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.23 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)

Attributes: BeginMeasure (Double, 15, 2) - A measure value along a


November 2010 68

(name, type, length, precision, scale, domained, notes) Continuous station series used to position and locate the start of

the linear feature. EndMeasure (Double, 15, 2) – A measure value along an

Engineering station series used to position and locate the end of the linear feature.



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

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


inheritance)

None.

SubTypes: -- 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.24 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)

Measure (Double, 15, 2) – A measure value along an Engineering station series used to position and locate the point feature.

SeriesEventID (GUID) - The foreign key of the Station Series feature to which the control point belongs.



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



Point_Z (Double, 15, 2) – Z axis (Elevation) measure of the Point feature.

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.25 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 (String, 30) fcGrade - The grade at which the fitting material


November 2010 70

is rated (e.g. SMYS 40 KSI) InletConnectionType (String, 30) fcConnectionType - The inlet

connection type (e.g. weld, thread). InletDiameter (String, 30) fcDiameter - The diameter of the inlet

opening. InletWallThickness (String, 30) fcWallThickness - The wall

thickness around the inlet opening. Manufacturer (String, 30) fcManufacturer - The manufacturer of the

fitting. Material (String, 30) fcMaterial - The material the material from

which the fitting is made (e.g. PVC, steel). PressureRating (String, 30) fcPressureRating - The pressure rating

of the fitting. Relationships:

(cardinality, optionality, composite, 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. 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 standing 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.3,



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, ClassMetaData and OnlineLocationClass. These tables are required classes in the APDM. ReferenceMode stores metadata pertaining to the reference modes that describe the StationSeries table. (Reference modes represent different methods of recording station values and how these values are applied at the LineLoop level.) ClassMetaData 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 ClassMetaData 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. Although every attempt was made to not delete fields but rather add to the model the APDM MetaData tables underwent some changes that involved deleting and altering schema. The most notable are the re-write of the ReferenceMode and ClassMetaData tables. The former is described in detail above, the latter was altered to make it more generic and not reference APDM explicitly in the table, attribute and domain names. 10.3.1.2 ClassMetaData

Class Name: ClassMetaData (formerly called APDMClass) Feature Class

Geometry: Object Class

Feature Dataset: -- APDM Class

Type: --


domained, notes)

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

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

ClassType (String, 50) – gnClassType – Denotes the APDM Abstract class that is the direct ancestor of the object/feature class.

RequiresGeometry (String, 50) – gnRequiresGeometry (Default=Unknown)– Indicates whether the class is stored using geometry, or as an object for use as a route event.


inheritance)

ClassOriginClass (core): ClassMetaData is 1:M with OnlineLocationClass


November 2010 72

ClassOnlineClass (core): ClassMetaData is 1:M with OnlineLocationClass

ClassCPLocation: ClassMetaData is 1:M with CPLocation ClassRemovedPoint: ClassMetaData is 1:M with RemovedPoint ClassRemovedLine: ClassMetaData is 1:M with RemovedLine

SubTypes: -- ClassMetaData 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: Unknown (Verified), Unknown, Must Have, Must Not Have, Optional. The ClassOriginClass and ClassOnlineClass 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, The following class types are codes that are delineated for the ClassType field: • ActivityExtension • APDMObject • AuditObject • CenterlineObject • FacilityObject • NonFacilityObject • CenterlinePolyline • CenterlinePolylineEvent • CenterlinePoint • OfflineFeature • OfflinePoint • OfflineFacility

• OfflinePointFacility • OfflineNonPointFacility • OnlineFeature • OnlinePolyline • OnlinePolylineForOfflineFeature • OnlinePoint • OnlinePointForOfflineFeature • OnlineFacility • OnlinePolylineFacility • OnlinePointFacility • Fitting

10.3.1.3 OnlineLocationClass

Class Name: OnlineLocationClass Feature Class


Feature Dataset: -- APDM Class --



Type: Other Notes: --


domained, notes)

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

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

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


inheritance)

ClassOriginClass (core): OnlineLocationClass is M:1 with ClassMetaData

ClassOnlineClass (core): OnlineLocationClass is M:1 with ClassMetaData

SubTypes: -- OnlineLocationClass stores the ClassEventID for the offline and online classes involved in an ‘offline’ and ‘online location’ relationship. As noted above, the ClassOriginClass and ClassOnlineClass 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. 10.3.1.4 ReferenceMode

Class Name: ReferenceMode Feature Class


Feature Dataset: -- APDM Class

Type: --


domained, notes)

RefMode (String, 50) – clRefMode (Default=Continuous) – Indicates the linear referencing schemes for use within the geodatabase. Describes the style of measure that is applied to each route feature in the StationSeries feature class.

RefModeRootName (String, 50) – Indicates the ‘root’ of the attribute in a online point/polyline class that stores the FK from that class to the StationSeries feature class for the particular refernce type the related StationSeries feature is storing.

RefModeMeasureRootName (String, 50) – Indicates the ‘root’


November 2010 74

name of any begin/end measure/station attribute in an online point/polyline class. Each reference mode has a ‘root’ name so that the measure/stationing fields for that reference mode are easily located.

RefModeUnits (String, 50) – gnRefModeUnits (Default 0=esriUnknownUnits) – Describes the units that the stationing values for a reference mode represent.

RefModeType (String, 50) – 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.

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

IsPRM (String, 50) – gnYesNo (Default - Yes) – Indicates whether the reference mode is the ‘primary’ reference mode that all other refernce modes are derived from.

ParentRefMode (String, 50) – clRefMode (Default=Unknown) – Indicates the name of the parent linear referencing schema that a child reference mode is derived from.


inheritance)

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

SubTypes: -- The ReferenceMode table stores the metadata defining each reference mode implemented in an APDM geodatabase. Reference mode types are found in the StationSeries feature class. Reference modes are applied to the entire geodatabase. Each StationSeries feature must belong to one and only one LineLoop object and must implement one and only one of the defined reference modes. All ControlPoint features must belong to one and only one StationSeries feature and implement the all defined reference modes. In the Control Point feature class each reference mode (stationing, or measure value) are stored in a separate attribute. 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 reference mode value for StationSeries 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). All online event features in the geodatabase must be stored using the PRM and any ARM’s and related to appropriate PRM and ARM StationSeries features. 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:


November 2010 76

Figure 7 – Reference Mode Basis



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.


November 2010 78

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

Figure 8 – Uninterrupted and Adjustable – Continuous Stationing



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

Figure 9 – Interrupted and Not-adjustable (Engineering Stationing)

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


November 2010 80

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:



Figure 10 – CL Edit Response (Part 1)


November 2010 82

CLValidityTolerance 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:



Figure 11 – CL Edit Response (Part 2)


November 2010 84

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 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:


November 2010 86

Figure 12 – CL XY Edit Response



CLStationEditResponse 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:


November 2010 88

Figure 13 – CL Station Edit Response

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


November 2010 90

CLZEditResponse behavior is depicted below:

Figure 14 – CL Z Edit Response



CLControl 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:

Figure 15 – CL Control


November 2010 92

10.4 Additional Reference Modes The APDM 5.0 allows for the use of additional reference modes or the use of a single reference mode. The definition of reference modes in the ReferenceMode metadata table and the creation StationSeries features for each of these reference mode allow operators to define reference modes and series as needed to suit their business needs. The current implementation of APDM 5.0 uses Continuous Measure and Engineering Stationing as default reference modes. The behavior that describes each is listed in the ReferenceMode metadata table. 10.4.1 Inherited Reference Mode Root Names A reference mode is defined as a defined system of linear referencing measurement. Linear referencing is an ESRI data management construct where point or line events can be drawn or depicited along a route provided the event is contained in a table with a primary key to a PolylineM aware shape file or feature class. The event will have a second attribute indicating the measure along a particular PolylineM feature in the route feature class. Through this method, events can be drawn on-screen in ArcGIS Desktop for display purposes. The storage and categorization of the M or measure values in a route is a reference mode. A reference mode is described by a name, the units of measure used for M (or measure) values, the basis for how the M calculated (2D or 3D distance), and how the M values of the routes and the geometry of the routes themselves behave if the geometry of a route is altered. The reference mode is also described with root names for foreign key and measure/station values that are stored as attributes in event-based classes. The ReferenceMode table is designed to store the meta data describing the reference modes used within an APDM. This section of the document will concentrate on describing the relationships between online feature/event classes, the StationSeries feature class and the ReferenceMode metadata class using the default reference modes listed below. RefMode <d> RefModeRootName

(root for FK)

RefModeMeasureRootName

RefModeUnits <d> RefModeType <d> RefModeBasis <d> IsPRM ParentRefMode <d>

Continuous Route Measure Feet Uninterrupted and Adjustable

3D Geoid Yes <NULL>

Engineering Series Station Feet Interrupted and Not Adjustable

3D Geoid No Continuous

10.5.1 The table above lists the two default reference modes for APDM 5.0: Continuous and Engineering. Blue is used to define information describing the ‘continuous’ reference mode and ‘green’ is used to define the information describing the ‘engineering’ reference mode.



The RefModeMeasureRootName field in the ReferenceMode metadata class contains the ‘root’ name used to store the measure or station values in Online event/feature classes. A point event requires a single ‘measure’ attribute for each reference mode. The name of the ‘measure’ attribute for each reference mode is contained in the RefModeMeasureRootName column. The name of the foreign key attribute in the point event/feature class is stored in the RefModeRootName column. Based on the values in the above reference mode table a point event/feature class in APDM must have the following fields:

• RouteEventID – FK to a Continuous station series feature in the StationSeries feature class.

• Measure – contains the measure value that is used to locate the point along the Continuous station series feature.

• StationEventID – FK to a Engineering station series feature in the StationSeries feature class.

• Station – contains the measure/station value that is used to locate the point along the Engineering station series feature.

A polyline event requires two ‘measure’ attributes for each reference mode. The root name for these attributes is likewise contained in the RefModeMeasureRootName column for each reference mode. Since a linear event requires a begin and end attributes to define it’s position along the route two attributes are added to each online polyline event/feature class with ‘Begin’ and ‘End’ added to the RefModeMeasureRootName. Similarly the name of the foreign key attribute in the point event/feature class is stored in the RefModeRootName column. The ‘Continuous’ reference mode is the Primary Reference Mode and it is defined as ‘Uninterrupted and Adjustable’ inferring that only one ‘continuous’ station series feature can exist per lineloop. There only one foreign key field is required in each Offline polyline feature class. However, the ‘Engineering’ reference mode is ‘Interrupted and Not-Adjustable’ meaning that more than one engineering station series feature can exist for a given line loop. This means that a ‘begin’ and ‘end’ foreign key attributes must defined for each online polyline event/feature class to track the possibility of a linear event starting on one engineering station series and ending on another. Based on the values in the reference mode table on the preceding page a online polyline event/feature class in APDM must have the following fields:

• RouteEventID – FK to a Continuous station series feature in the StationSeries

feature class. • BeginMeasure – contains the measure value that is used to locate the starting

point of the linear feature along the Continuous station series feature. • EndMeasure – contains the measure value that is used to locate the ending point

of the linear feature along the Continuous station series feature. • BeginStationEventID – FK to a Engineering station series feature in the

StationSeries feature class where the starting point of the linear feature is located.


November 2010 94

• BeginStation – contains the measure value that is used to locate the starting point of the linear feature along the Engineering station series feature.

• EndStationEventID – FK to a Engineering station series feature in the StationSeries feature class where the ending point of the linear feature is located.

• EndStation – contains the measure value that is used to locate the ending point of the linear feature along the Engineering station series feature.

The following diagram illustrates examples of the schema for an online polyline event/feature class (InspectionRange) and a online point event/feature class (Leak). The schema for the StationSeries feature class and the ReferenceMode meta data table are also included. The relationships between the online event/feature classes are included and color coded to match the information listed in the reference mode table example. Blue lines indicate the ‘Continous’ Route reference mode/station series relationships. Light Green indicate the BEGIN ‘Engineering’ Series reference mode/station series relationships. Dark Green indicate the END ‘Engineering’ Series reference mode/station series relationships. The RED attributes show the relationships between StationSeries features of different reference modes. For example – each StationSeries of RefMode = ‘Engineering’ will have a single ‘Continuous’ Route StationSeries parent. This relationship is defined in the ReferenceMode metadata table. Where the ‘Continuous’ reference mode is the Primary Reference Mode and it’s EventID value is stored in the ParentRefModeEventID value for the ‘Engineering’ reference mode. The foreign key value for the relationship between ‘Engineering’ series and ‘Continuous’ route StationSeries features is contained in the ParentStationSeriesEventID attribute in the StationSeries feature class. Each ‘Continous’ station series will have a null value in this attribute. Each ‘Engineering’ station series will have the GUID value matching the EventID value of the parent ‘Continuous’ station series that it belongs to. Also note the relationship between StationSeries and ReferenceMode using the RefMode attribute (colored in purple). The parent-child relationship between reference modes in the ReferenceMode table is reflected in a parent-child relationship between station series features in the StationSeries feature class. Every station series feature must have a RefMode value equal to a defined reference mode in the ReferenceMode metadata table. Each reference mode defined in this table will have one or more station series features of that reference mode type stored in the StationSeries feature class. In the default implementation of APDM 5.0 using ‘Continuous’ and ‘Engineering’ as reference modes (as defined in the above ReferenceMode table example) the following rules apply: For a given physical LineLoop:

• There must be a single continuous station series feature that comprises the entire route of the line.



o The LineLoopEventID attribute will be populated with the EventID value of a LineLoop object.

o The BeginMeasure and EndMeasure attributes must contain an assigned start value and the cumulative length of the route in measure units respectively.

o The BeginStation and EndStation attributes can be null. o The ParentStationSeriesEventID attribute must be null. o The RefMode attribute must have the value of ‘Continuous’

• There must be one or more engineering station series features that completely cover, without gap or overlap, the exact same path (geometry) as the parent continuous station series feature.

o For each engineering station series: The LineLoopEventID attribute will be populated with the same

GUID value as the stored in the parent continuous station series feature.

The BeginMeasure and EndMeasure attributes will contain the measure value at those points along the parent ‘Continuous’ station series feature

The BeginStation and EndStation attributes must contain an assigned start value and the cumulative length of the engineering station series in station units respectively.

The ParentStationSeriesEventID attribute will contain the EventID attribute value of the parent ‘Continuous’ station series feature.

The SeriesOrder value will be populated with a sequential integer value indicating the order in which the engineering station series feature appear along the continuous route starting at the series that is found at the BeginMeasure position of the route.

The FromSeriesEventID and the ToSeriesEventID will be populated with the EventID values of the engineering station series that comprise the route from start to finish along the route. The first series in the string will not have a FromSeriesEventID value and the last series in the string will not have a ToSeriesEventID value.

The RefMode attribute must have a value of ‘Engineering’


November 2010 96

OnlinePolyline & OnlinePoint related to StationSeries

GlobalIDEventID (pk)CreatedByCreatedDateEffectiveFromDateEffectiveToDateHistoricalState <d>LastModifiedModifiedByOriginEventIDProcessFlagRemarks

CLEditResponse <d>CLValidityTolerance <d>RouteEventID (fk)

OnlineFeature

BeginMeasureEndMeasureBeginSeriesEventIDBeginStationEndSeriesEventIDEndStationStatus <d>

OnlinePolyline

[FeatureArchive]GlobalIDEventID (pk)CreatedByCreatedDateEffectiveFromDateEffectiveToDateHistoricalState <d>LastModifiedModifiedByOriginEventIDProcessFlagRemarks

CLEditResponse <d>CLValidityTolerance <d>RouteEventID (fk)

OnlineFeature

MeasureSeriesEventIDStationStatus <d>SymbolRotationPoiint_XPoint_YPoint_Z

OnlinePoint

[FeatureArchive]

Contact

Activity

InspectionRangeInspectionDate

DateRepairedDateReportedDepthLeakCause <d>LeakOrigin <d>LeakStatus <d>MethodDetected <d>RepairType <d>

Leak

EventID (pk)RefMode <d>RefModeMeasureRootNameRefModeBasis <d>RedModeType <d>RefModeUnits <d>IsPRM <d>ParentRefModeEventID (fk)RefModeRootName

ReferenceModeOBJECTID

Object

Shape

OBJECTID[Object]

[Feature]Shape

OBJECTID[Object]

[Feature]

BeginMeasureEndMeasureBeginStationEndStationOperationalStatus <d>

CenterlinePolyline

SeriesNameSeriesOrderParentStationSeriesEventID (sfk)LineLoopEventID (fk)FromConnectionStationValueFromSeriesEventID (sfk)ToConnectionStationValueToSeriesEventID (sfk)RefMode <d> (fk)

StationSeries

Lineloop

SubSystemRange

ControlPoint


[FeatureArchive]Shape

OBJECTID[Object]

[Feature]

Figure 16 – Online Polygline and Online Point related to StationSeries

Note that the ParentStationSeriesEventID does not follow the RefModeRoot naming convention as defined in the description in the preceding pages or in the ReferenceMode metadata table. This field refers to a surrogate primary-foreign key relationship between the StationSeries feature class and itself. Currently ESRI technology do not support as self- or reflexive relationship class. The relationship is documented in the above diagram but is not physically implemented in the physical model. The values in the ParentStationSeriesEventID MUST be maintained manually or programmatically. Note



that the ToSeriesEventID and the FromSeriesEventID values in the StationSeries feature class remain the same to maintain compatibility with APDM 5.0. 10.4.2 Continuous Measure and Engineering Stationing The default implementation of APDM 5.0 utilizes Continuous Measure and Engineering Stationing. The model is designed to support more than one form of linear referencing or ‘reference mode’. Continuous Measure and Engineering Stationing are the most common forms of linear referencing in pipelines. The following table shows an example of both forms of referencing as depicted in the newly updated ReferenceMode Table. RefMode <d> RefModeRootNam

e (root for FK)

RefModeMeasureRootName

RefModeUnits <d> RefModeType <d> RefModeBasis <d> IsPRM ParentRefMode <d>

Continuous Route Measure Feet Uninterrupted and Adjustable

3D Geoid Yes <NULL>

Engineering Series Station Feet Interrupted and Not Adjustable

3D Geoid No Continuous

Table 1

Figure 17 This table outlines two forms of linear referencing: continuous measure and engineering stationing. Each linear referencing method is stored in the ReferenceMode object class as a single record or object. Therefore each object is identified by an EventID value. The Continuous Measure object has a RefMode of ‘Continuous’. This value is derived from the clRefMode domain. This domain value is applied to the RefMode attribute of the StationSeries feature class. The RefModeMeasureRootName describes the root name used for all ‘Measure’ attributes in each Online (and the StationSeries and ControlPoint) feature class. An OnlinePoint feature class will have a Measure field that will contain the ‘measure’ value of that point along a

particular ‘Continuous’ measure StationSeries feature. The measure units for this reference mode are feet. The basis for the distance between the vertices or control points in the station series for this reference mode is 3D Geoid. The behavior or spatial integrity of each station series feature for this reference mode is ‘Uninterrupted and Adjustable’. This means that there is one and only one continuous measure station series

0.0 10.0 50.0 60.020.0 40.0

15.0 5.0

120.0

0.0

0.0 10.0 50.0 60.020.0 40.0

25.0 35.0

A

2

3

Continuous Station Series

Engineering Station Series

0.0 10.0 50.0 60.040.0

15.0 5.0

0.0

20.020.0

Control Points

LineLoop

Resulting APDM Control Points

0.0,0.0 10.0,10.0 50.0,50.0 60.0,60.040.0,40.0

15.0,25.0 5.0,35.0

0.0,40.0

20.0,20.0

20.0,20.0

Q1

b cd

e

f g

hi

jk


November 2010 98

for a given LineLoop. The continuous measure station series cannot be broken into two or more features per LineLoop. The EndMeasure for each continuous measure station series is based on the cumulative distance from start to end for the station series starting at the BeginMeasure value for this feature. The IsPRM field indicates that ‘continuous measure’ reference mode is the primary reference mode for the ‘engineering stationing’ reference mode. This has several ramifications. First, all child engineering stationing station series must comprise the same geometry as the parent continuous measure station series. This means that the position of the vertices from each child station series must match the position of those in the parent. The cumulative stationing of all child engineering stationing station series must equal that to the total measure of the parent continuous measure station series (EndMeasure – BeginMeasure). Second, since the child engineering stationing StationSeries belong to a ReferenceMode that is ‘Interrupted and Non-Adjustable’ this means that one or more of these station series features can be connected end-to-end to form the same route geometry as the geometry of the parent continuous measure station series feature. The parent station series geometry is comprised of the geometries of the child station series features connected end-to-end. The continuous measure station series are considered the parent reference mode so there is no ParentRefModeEventID value. Third, the RefModeRootName indicates the root name for the foreign key attribute in each Online feature class linking the feature to the StationSeries feature class and in particular the station series that is used to derive the ‘RefModeMeasureRootName’ value from. The second reference mode – Engineering Station has a unique EventID GUID value. The RefMode is ‘Engineering’. All ‘Engineering’ station series features representing this reference mode will have a similar value in the RefMode attribute of the StationSeries feature class. The RefModeMeasureRootName is ‘Station’ which is the attribute containing the measure or station value for each OnlineFeature located along this StationSeries. The RefMode units are feet. The distances along the StationSeries are calculated by using a 3D Geoid. The RefModeType is ‘Interrupted and Adjustable’ meaning that one or more ‘Engineering Station’ StatinoSeries linked end-to-end will comprise the geometry of the parent StationSeries feature. The ‘Engineering Stationing’ reference mode is not the Primary Reference Mode and it will have the GUID of the Parent Reference Mode record in the ParentRefModeEventID attribute. Lastly, the RefModeRootName, or foreign key attribute root name is listed in the RefModeRootName. The RefModeRootName is not only the root of the attributes in Online features it also contains terminology that describes the actual station series features. Each Continuous Measure station series feature is really a ‘Continuous Measure Route’ where each Engineering Stationing station series feature is really an ‘Engineering Station Series’. These are common terms used to describe station series features in the pipeline industry. The following diagram illustrates the spatial relationship between control points, ‘engineering station series’ and ‘continuous measure routes’. The diagram also shows



how the combination of control points, series and routes forms a ‘physical’ LineLoop object in the APDM. The bottom of the two diagrams shows a set of control points. APDM 5.0 control points now contain an attribute for each reference mode. The default implementation of ‘continous measure’ and ‘engineering stationing’ reference modes would require two attributes. Using the ReferenceMode table example above, and using the RefModeMeasureRootName values, these attributes will be called ‘MeasureValue’ and ‘StationValue’. The Value is appended to the Root names to differentiate the ControlPoint feature class from regular online feature classes. For each control point there are two ‘measure’ values. The measure values (in red) form the Continuous Station Series. The station values (in black) form the Engineering Station Series. Assuming that the control points in the top diagram form a single LineLoop comprised of three ‘engineering’ station series; then the middle sketch shows the formation of the ‘Engineering Station’ series feature. Note that the order of stationing for these features (in a ‘Interrupted and Non-Adjustable’ reference mode) can be ascending or descending. The stationing values or measure values or M values for each StationSeries feature must be montonically increasing but the direction of the ‘interrupted’ child station series ‘measure’ values is independent of the parent continuous station series. The middle and the top routes in the top diagram show the relationship between the ‘Continuous Measure’ routes and the underlying ‘Interrupted Engineering Station’ series. Engineering Series 1 links at it’s end point to the end point of Engineering Series 2 which links at it’s begin point to Engineering Series 3 to form the same geometry route as the ‘Continuous Measure’ Route A (in the top drawing). Although the continuous measure route is the parent reference mode it is generated and derived form the underlying engineering station series which is in-turn derived from the control points that form the engineering station series.

In the APDM 5.0, duplicate control points have been merged. Each control point will contain one attribute for each reference mode. The only time that control points are duplicated are at ‘equations’ representing the linking of two ‘interrupted’ style station series belonging to the same parent ‘non-interrupted’ style station series. The lower diagram (above) now shows control points (b-k) with ‘engineering’ station value (black) and a ‘continuous’ measure value (red).

Table 2

LIneLoop Attribute Value ObjectID 1 GlobalID {A298F545-4209-4CA5-9E2F-CE7F8C50E2A3} EventID (pk) {F3004B6A-40A6-49A6-B951-7F4F15D27E7E} CreatedBy Pcgv CreatedDate 10/05/2009 EffectiveFromDate 1/1/2009 EffectiveToDate <Null> HistoricalState <d> Current LastModified 10/05/2009 ModifiedBy Pcgv OriginEventID <Null> ProcessFlag <Null> Remarks APDM 5.0 LineLoop Example OperationalStatus <d> Active LineName Q1 Q1 LineFunction <d> Transmission LineJurisdiction <d> Onshore


November 2010 100

The following three tables lists the resulting LineLoop, StationSeries and ControlPoint features described above in their respective table views based on the ‘ReferenceMode’ example (used above).

StationSeries Attribute Value Value Value Value ObjectID 1 2 3 4 Shape

GlobalID {81D21CE3-6414-4DF8-8035-FD52804B5DDD}

{73B57D7B-195F-4940-8E0F-0A1B6542F6C3}

{ECD9C22F-855A-483A-93F3-8E618F1C5E78}

{10DE1E6D-43E3-45CA-A50B-CA7F5E2127FB}

EventID (pk) {4AE67B70-2B52-4DED-89D8-6E8C88CAFC2A}

{8914F122-C505-4A4F-B335-2DBF7F0D4140}

{85CE58EB-0F7B-4EF3-9584-36F23B3D0461}

{789633DF-727C-4CD0-B216-9E5EBF5507B9}

CreatedBy Pcgv Pcgv Pcgv Pcgv CreatedDate 10/05/2009 10/05/2009 10/05/2009 10/05/2009 EffectiveFromDate 1/1/2009 1/1/2009 1/1/2009 1/1/2009 EffectiveToDate <Null> <Null> <Null> <Null> HistoricalState <d> Current Current Current Current LastModified 10/05/2009 10/05/2009 10/05/2009 10/05/2009 ModifiedBy Pcgv Pcgv Pcgv Pcgv OriginEventID <Null> <Null> <Null> <Null> ProcessFlag <Null> <Null> <Null> <Null> Remarks APDM 5.0 Continuous

StationSeries Example APDM 5.0 Engineering StationSeries Example

APDM 5.0 Engineering StationSeries Example

APDM 5.0 Engineering StationSeries Example

BeginMeasure 0 0 20 40 BeginStation <Null> 0 20 40 EndMeasure 60 20 40 60 EndStation <Null> 20 0 60 OperationalStatus <d> Active Active Active Active SeriesName Q1 A Q1 1 Q1 2 Q1 3 SeriesOrder 1000 1000 2000 3000

ParentSeriesEventID (fk)

<Null> {4AE67B70-2B52-4DED-89D8-6E8C88CAFC2A}

{4AE67B70-2B52-4DED-89D8-6E8C88CAFC2A}


LIneLoopEventID (fk) {F3004B6A-40A6-49A6-B951-7F4F15D27E7E}

{F3004B6A-40A6-49A6-B951-7F4F15D27E7E}

{F3004B6A-40A6-49A6-B951-7F4F15D27E7E}

{F3004B6A-40A6-49A6-B951-7F4F15D27E7E}

FromConnectionStationValue

<Null> <Null> <Null> <Null>

FromSeriesEventID <Null> <Null> <Null> <Null>

ToConnectionStationValue

<Null> <Null> <Null> <Null>

ToSeriesEventID <Null> <Null> <Null> <Null>

RefMode Continuous Engineering Engineering Engineering Table 3



Note that all four station series features are related to a single line loop via the LineLoopEventID attribute. Note also that all three ‘Engineering’ series are related to the single ‘Continuous’ route feature using the ‘ParentSeriesEventID’. No relationship class exists for this relationship; it is a logical relationship only. ESRI does not currently support self-relates within the Geodatabase. But it illustrates the point that the ‘engineering’ station series are children of the ‘continuous’ series by virtue of the values in the RefMode attribute. Correspondingly this relationship is further defined by the example ReferenceMode table provided above.

ControlPoint Attribute Value Value Value Value Value Value Value Value Value Value ObjectID 1 2 3 4 5 6 7 8 9 10 Shape GlobalID GUID GUID GUID GUID GUID GUID GUID GUID GUID GUID EventID (pk)

GUID GUID GUID GUID GUID GUID GUID GUID GUID GUID

CreatedBy Pcgv Pcgv Pcgv Pcgv Pcgv Pcgv Pcgv Pcgv Pcgv Pcgv CreatedDate

10/05/2009 10/05/2009 10/05/2009 10/05/2009 10/05/2009 10/05/2009 10/05/2009 10/05/2009 10/05/2009

10/05/2009

EffectiveFromDate

1/1/2009 1/1/2009 1/1/2009 1/1/2009 1/1/2009 1/1/2009 1/1/2009 1/1/2009 1/1/2009

1/1/2009

EffectiveToDate

<Null> <Null> <Null> <Null> <Null> <Null> <Null> <Null> <Null> <Null>

HistoricalState <d>

Current Current Current Current Current Current Current Current Current Current

LastModified

10/05/2009 10/05/2009 10/05/2009 10/05/2009 10/05/2009 10/05/2009 10/05/2009 10/05/2009 10/05/2009

10/05/2009

ModifiedBy Pcgv Pcgv Pcgv Pcgv Pcgv Pcgv Pcgv Pcgv Pcgv Pcgv OriginEventID


ProcessFlag


Remarks b c d e f g h i j k

OperationalStatus <d>

Active Active Active Active Active Active Active Active Active Active

RouteEventID (fk)











MeasureValue

0 10 20 20 25 35 40 40 50 60

SeriesEventID (fk)

{8914F122-C505-4A4F-B335-2DBF7F0D4140}

{8914F122-C505-4A4F-B335-2DBF7F0D4140}

{8914F122-C505-4A4F-B335-2DBF7F0D4140}

{85CE58EB-0F7B-4EF3-9584-36F23B3D0461}

{85CE58EB-0F7B-4EF3-9584-36F23B3D0461}

{85CE58EB-0F7B-4EF3-9584-36F23B3D0461}

{85CE58EB-0F7B-4EF3-9584-36F23B3D0461}

{789633DF-727C-4CD0-B216-9E5EBF5507B9}

{789633DF-727C-4CD0-B216-9E5EBF5507B9}

{789633DF-727C-4CD0-B216-9E5EBF5507B9}

StationValue

0 10 20 20 15 5 0 40 50 60

Point_X 0.00 10.0 20.0 20.0 20.0 30.0 30.0 30.0 40.0 50.0 Point_Y 0.00 0.00 0.00 0.00 -5.0 -5.0 0.00 0.00 0.00 0.00 Point_Z 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 CLControl <d>

No No No No No No No No No No CLStationEditRespons

Assigned Assigned Assigned Assigned Assigned Assigned Assigned Assigned Assigned Assigned


November 2010 102

e <d> CLXYEditResponse <d>


CLZEditResponse <d>


SymbolRotation

0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0

ControlPointAngle

0.0 0.0 0.0 0.0 -90.0 +90.0 +90.0 0.0 -90 0.0

ControlPointType <d>

PI PI PI PI PI PI PI PI PI PI

PIDirection <d>

None None None RT LT LT RT None None None

Table 4 All control points belong to the same ‘continuous’ measure route as denoted by the GUID values in the RouteEventID foreign key attribute to the StationSeries EventID attribute. All control points belong to one and only one engineering series feature. Note that control points D and E and control points H and I are both located at the same coordinates (yellow cells) but belong to different engineering series features (blue text) using the SeriesEventID foreign key attribute to the StationSeries EventID attribute. No two control points will share both the same MeasureValues and StationValues for a given route. The following diagram and tables show examples of four online features; three InspectionRange features and four leak features. These examples show both the spatial position of these features but also the tabular view of how they are stored in the APDM as Online Polyline and Online Point features.

Figure 18 In this example Inspection Range features (b,c,d,e) and Leak features (f, g) are located on LineLoop Q1. In APDM 5.0 both the measure values from Continuous Station Series A and station values from Engineering Station Series 1, 2 and 3 are recorded with the features. The following tables illustrate both sets of features and the FK relationships between those features and the StationSeries feature class. Each inspection range feature belongs on the Q1 route as denoted by the

0.0 10.0 50.0 60.020.0 40.0

15.0 5.0

120.0

0.0

0.0 10.0 50.0 60.020.0 40.0

25.0 35.0

A

2

3

Continuous Station Series

Engineering Station Series

Inspection Range and Leak Features

LineLoop Q1

b c

d

ef g



RouteEventID foreign key to the EventID field in the StationSeries feature class. This foreign key value corresponds to the EventID value for the continuous station series feature in the Station Series Feature class.

InspectionRange Attribute Value Value Value Value ObjectID 1 2 3 4 Shape

GlobalID {F34E196E-67E5-42A3-A872-B77FD5DE15E8}

{59C8A169-3578-4118-AAD3-FF6F79FEBD93}

{061FE0EC-1D1E-4CDC-976E-5A938FB7ECE3}

{811062D1-E1C6-4A5E-8921-1C5C8BC8492D}

EventID (pk) {76F605CD-6FB5-452C-8947-2C64E9C76D5D}

{4BE3CB84-7E7A-430F-AAFD-3F6CA20DF9E2}

{60FABB8B-7148-404F-90F5-B1A14F0320A0}

{E34B4F7C-2DFB-482F-9047-A12E830BFA1E}

CreatedBy Pcgv Pcgv Pcgv Pcgv CreatedDate 10/05/2009 10/05/2009 10/05/2009 10/05/2009 EffectiveFromDate 1/1/2009 1/1/2009 1/1/2009 1/1/2009 EffectiveToDate <Null> <Null> <Null> <Null> HistoricalState <d> Current Current Current Current LastModified 10/05/2009 10/05/2009 10/05/2009 10/05/2009 ModifiedBy Pcgv Pcgv Pcgv Pcgv OriginEventID <Null> <Null> <Null> <Null> ProcessFlag <Null> <Null> <Null> <Null> Remarks APDM 5.0

InspectionRange Example b

APDM 5.0 InspectionRange Example

c

APDM 5.0 InspectionRange Example d

APDM 5.0 InspectionRange Example e

CLEditResponse <d>

Relative Relative Relative Relative

CLValidityTolerance 0.00 0.00 0.00 0.00 RouteEventID (fk) {4AE67B70-2B52-4DED-

89D8-6E8C88CAFC2A} {4AE67B70-2B52-4DED-89D8-6E8C88CAFC2A}



BeginMeasure 0 10 15 50 EndMeasure 10 15 50 60 BeginStation 0 10 15 50 EndStation 10 15 50 60 BeginSeriesEventID {73B57D7B-195F-4940-

8E0F-0A1B6542F6C3} {73B57D7B-195F-4940-8E0F-0A1B6542F6C3}

{73B57D7B-195F-4940-8E0F-0A1B6542F6C3}

{789633DF-727C-4CD0-B216-9E5EBF5507B9}

EndSeriesEventID {73B57D7B-195F-4940-8E0F-0A1B6542F6C3}

{73B57D7B-195F-4940-8E0F-0A1B6542F6C3}

{789633DF-727C-4CD0-B216-9E5EBF5507B9}

{789633DF-727C-4CD0-B216-9E5EBF5507B9}

Status Active Active Active Active InspectionDate 10/05/2009 10/05/2009 10/05/2009 10/05/2009

Table 5 Note how each inspection range online polyline feature also relates to one or two ‘engineering’ station series features in the StationSeries feature class. The GUID values in the BeginSeriesEventID and EndSeriesEventID fields relate to one or two station series of ‘engineering’ RefMode type in the StationSeries feature class. Note that some linear events start on one engineering station series and end on another engineering station series (as denoted by the colored cells matching the color of the respective series in the drawings above).


November 2010 104

Leak Attribute Value Value ObjectID 1 2 Shape GlobalID {FBE90BBD-B6B7-49D1-828D-3E547ACA19C2} {165AB795-863E-426C-883B-862B9A022F77} EventID (pk) {141DE41D-05B1-4693-8862-0A95C40D1A75} {64756066-C5DF-4EAE-917F-1C92124F8873} CreatedBy Pcgv Pcgv CreatedDate 10/05/2009 10/05/2009 EffectiveFromDate 1/1/2009 1/1/2009 EffectiveToDate <Null> <Null> HistoricalState <d> Current Current LastModified 10/05/2009 10/05/2009 ModifiedBy Pcgv Pcgv OriginEventID <Null> <Null> ProcessFlag <Null> <Null> Remarks APDM 5.0 Leak Example f APDM 5.0 Leak Example g CLEditResponse <d> Relative Relative CLValidityTolerance 0.00 0.00 RouteEventID (fk) {4AE67B70-2B52-4DED-89D8-6E8C88CAFC2A} {4AE67B70-2B52-4DED-89D8-6E8C88CAFC2A} Measure 20 45 SeriesEventID (fk) {8914F122-C505-4A4F-B335-2DBF7F0D4140} or

{85CE58EB-0F7B-4EF3-9584-36F23B3D0461} {789633DF-727C-4CD0-B216-9E5EBF5507B9}

Station 20.0 45 Status <d> Active Active SymbolRotation 0.0 0.0 Point_X 20.0 35.0 Point_Y 0.0 0.0 Point_Z 0.0 0.0 DateRepaired 10/05/2009 10/05/2009 DateReported 10/05/2009 10/05/2009 Depth 2.3 1.2 LeakCause <d> Some domain value … Some domain value … LeakOrigin <d> Some domain value … Some domain value … MethodDetected <d> Some domain value … Some domain value … RepairType <d> Some domain value … Some domain value …

Table 6 10.5 Removing AltRefMeasure Object Class The addition of secondary stationing attributes in the Online event/feature classes removes the need for the AltRefMeasure object class. See the notes on GroupEventID below for further information why AltRefMeasure is required. 10.6 Merging Control Points Only a single set of control points will be maintained in APDM 5.0. In APDM 4.0 a complete set of control points was maintained for each station series feature. APDM5.0 default implementation requires a ‘continuous’ measure route station series be present for each physical LineLoop object in the model. Each vertex of the continuous measure route station series feature will have a control point. The control point will now contain the XYZ values of the vertex and a foreign key and measure field for each type of reference mode listed in the ReferenceMode table. This diagram shows in APDM 5.0 where for each station series one set of control points would be maintained for both the continuous and engineering station series. In this example a minimum of two control points would be stored in the APDM for the same



XYZ location. At the equation points, where two engineering station series abut against each other, there will be a minimum of three control points – one continuous control point, two engineering control points – one at the end of the first engineering station series, one at the beginning of the second engineering station series.

Figure 19 In APDM 5.0 control points sharing the same XYZ coordinate but different reference modes are merged into a single control point. In the diagram below the APDM 5.0 control points are shown. Instead of duplicate points being maintained for all sets of control points only a single point is saved. Non-equation control points B, C, F, G, J, and K are merged into a single point. Equation points D, E, H, I now require two points – one for each engineering station series at the equation, rather than the three points that were required in APDM 5.0. To facilitate the merging of control points new attributes are required to manage this data. The diagram in the following page shows the new additions to the ControlPoint feature class schema. Each control point must have a two foreign key attributes – one for each reference mode. Each Control point must have two measure or station value attributes – one for each reference mode.


0.0,0.0 10.0,10.0 50.0,50.0 60.0,60.040.0,40.0

15.0,25.0 5.0,35.0

0.0,40.0

20.0,20.0

20.0,20.0b cd

e

f g

hi

jk

0.0 10.0 50.0 60.020.0 40.0

25.0 35.0

AContinuous Station Series

LineLoop Q1

0.0 10.0 50.0 60.020.0 40.0

25.0 35.0

Continuous Control Points

0.0 10.0 50.0 60.020.0 40.0

15.0 5.0

120.0

0.0

2

3Engineering Station Series

0.0 10.0 50.0 60.040.0

15.0 5.0

0.0

20.020.0

Engineering Control Points


November 2010 106


CenterlinePolyline


StationSeries

Lineloop

SubSystemRange

ControlPoint



OBJECTID[Object]

[Feature]

OperationalStatus <d>RouteEventID (fk)MeasureValueSeriesEventID (fk)StationValuePoint_XPoint_YPoint_ZCLControl <d>CLStationEditResponse <d>CLXYEditResponse <d>CLZEditResponse <d>SymbolRotation

CenterlinePoint

ControlPointAngleControlPointType <d>PIDirection <d>

ControlPoint

GeoMetaData



OBJECTID[Object]

[Feature]

StationSeries and ControlPoint FeatureClasses

Figure 20

The ControlPoint feature class now contains the EventID value of both the Continuous Route Station series and the Engineering Station series feature that it belongs to. The ControlPoint feature also contains a MeasureValue and a StationValue for each of these station series features.



11.0 Core Object and Feature Classes The following subsections describe the core feature/object classes in the model. The object and feature classes presented in this section comprise the core classes of the APDM. They are included at this time to present a coherent data dictionary 11.1 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. 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:


November 2010 108

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

• Feature classes: o ControlPoint 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:



OnlineFeature

APDM Core

CenterlineObject

StationSeriesNameSeriesOrderParentStationSeriesEventID (fk)LineLoopEventID (fk)FromConnectionStationValueFromStationSeriesEventID (fk)ToConnectionStationValueToStationSeriesEventID (fk)RefMode <d>

StationSeries

LineNameLineFunction <d>LineJurisdiction <d>

LineLoop

SubSystemName

SubSystem

CenterlinePoint CenterlinePolyline


SubSystemEventID (fk)

SubSystemRange

ControlPointAudit

StationSeriesAudit

LineLoopAuditSubSystemAudit

SiteNameSiteType <d>

Site

OfflineFacility

SiteAudit

OnlineFacility

SiteEventID (fk)

SubSystemEventID (fk) LineLoopEventID (fk)

ControlPointEventID (fk)

StationSeriesEventID (fk)

ClassMetaData

Contact

GeoMetaData

OfflinePointFacility

Contact

StationSeries

OwnerOperator

Product

OfflineNonPointFacility

FacilityObject

ReferenceMode

LineLoopHierarchy

LineLoopHierarchy

SubSystemHierarchy

SubSystemHierarchy


ControlPoint

Figure 21


November 2010 110

APDM Core (Continued)

CompanyEventID (fk)LineLoopEventID (fk)OwnerPercentage <d>OwnerType <d>

OwnerOperator

ParentSubsystemEventID (fk)ChildSubsystemEventID (fk)

SubSystemHierarchy

ParentLineLoopEventID (fk)ChildLineLoopEventID (fk)

LineLoopHierarchy

Product <d>

Product

LineLoop

NonFacilityObject

APDMObject

ActivityDateActivityDescriptionActivityNameActivityType <d>

Activity

<classname>EventID (PK)ActivityDateActivityEventID (PK)

<classname>Audit

DocumentDescriptionDocumentType <d>FileNameFilePathHyperLink

ExternalDocument

<parent class>

InspectionRange

ParentActivityEventID (fk)ChildActivityEventID (fk)

ActivityHierarchy

GeoMetaData

LineLoop

LineLoop

SubSystem

SubSystem

CompanyLabelCompanyNameCompanyType <d>

Company

LegendESRI Simple Object

Inheritance


APDM Abstract Class


Wormhole to non-Core Class

APDM Audit Class

Foreign Key

Domain Attribute

(fk)

<d>

Subtype

Wormhole to APDM Abstract Class

ControlPoint (Core)

Activity (Core)

Site (Core)

StationSeries (Core)SubSystemRange (Core)

ActivityHierarchy (Core)

ClassMetaData (Metadata)

Company (Core)

ControlPointAudit (Core)ExternalDocument (Core)

LineLoop (Core)

LineLoopAudit (Core)

LineLoopHierarchy (Core)

OnlineLocationClass (Metadata)

OwnerOperator (Core)

Product (Core)

ReferenceMode (MetaData)

SiteAudit (Core)

StationSeriesAudit (Core)

SubSystem (Core)

SubSystemAudit (Core)

SubSystemHierarchy (Core)

GeoDatabaseTransmission (FeatureDataset)

NOTE: The Catalog View does not show any relationship classes Only feature and object classes are shown.OBJECTID

Object

RefMode <d>RefModeMeasureRootNameRefModeBasis <d>RedModeType <d>RefModeUnits <d>IsPRM <d>ParentRefMode (fk)RefModeRootName

ReferenceModeClassType <d>ClassEventID (pk)ClassNameRequiresGeometry

ClassMetaDataOriginClassEventID (fk)OnlineLocationClassEventID (fk)OnlineLocationMechanism <d>

OnlineLocationClasses

Metadata

StationSeries

CPOnlineLocation

RemovedPoint

RemovedLine

The metadata classes represent a set of object classes that are used to hold information

about the reference modes, information about each concrete class inheriting from an ‘APDM Abstract Class’ and information about which

‘offline’ APDM classes have related ‘online’ polyline or ‘online’ point classes.

Figure 22



11.1.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 (esriFieldTypeGUID). 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". 11.1.2 Core Object Classes 11.1.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 (String, 50) – 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


November 2010 112

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 11.2.2.2 ActivityHierarchy. 11.1.2.2 ActivityHierarchy Class Name: ActivityHierarchy Feature Class Geometry:

Implemented as an Object Class

APDM Inheritance:

ESRI Object APDM Object (Ancestors – Abstract)


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

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


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

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.


November 2010 114

11.1.2.3 <class name>Audit Class Name: <class name>Audit Feature Class Geometry:

Implemented as an Object Class.

APDM Inheritance:

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


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 (GUID) – 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 M-N relationship with Activity or ExternalDocument. The Audit class acts as the intersection table between the parent feature/object class and the Activity object class. 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. 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. 11.1.2.4 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 (String, 50) – gnCompanyType – Describes the

services the company provides (pipeline, contractors, etc.) Relationships: CompanyOwnerOperator (core): Company is 1:M with


November 2010 116


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. 11.1.2.5 ExternalDocument Class Name: ExternalDocument Feature Class Geometry:


APDM Inheritance:



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

DocumentType (String, 50) – 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. 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. 11.1.2.6 LineLoop Class Name: LineLoop Feature Class Geometry:

Implemented as an Object class.

APDM Inheritance:

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


LineName (String, 45) – Name of the pipeline. LineFunction (String, 50) clLinefunction -- designates current

function of the pipeline. (ex: Lateral, Mainline, Cross-over, etc.) LineJurisdiction (String, 50) clLineJurisdiction -- designates

jurisdiction of lineloop. (ex: offshore or onshore)

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


November 2010 118


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

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

LineLoopOwnerOperator (core): LineLoop is 1:M 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 11.1.2.7 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.



C

LineloopsLineloops represent the primary method of organizing and locating features on or along the centerline of a pipeline system. A Lineloop represents one or more Primary Reference Mode (PRM) StationSeries features connected from end point to endpoint forming a single line or route without breaks. Lineloops are used to identify the pipelines of a system. Lineloops form the base unit for analysis and reporting. No StationSeries feature can exist without belonging to a LineLoop. Between the two classes the pipeline centerline is formed. Reference mode behavior, particularly in the instance of a centerline re-route, is governed by the extent of an individual lineloop.

The difference between a physical and logical Lineloop is based on the number of Primary Reference Mode StationSeries features the Lineloop is related to.

GroupEventIDOperationalStatus <d>

CenterlineObject

APDMObject

[Object]

[ObjectArchive]

EventID (pk)

LineNameLineFunction <d>LineJurisdiction <d>

LineLoop

ParentLineLoopEventID (fk)ChildLineLoopEventID (fk)

LineLoopHierarchy

LineLoopAuditLineLoopEventID (fk)

StationSeries

OwnerOperator

Product

A

Transmission System Example – Physical View

a – This diagram represents the ACME Transmission Pipeline Company. The company runs two main lines (ACME 12" and ACME 10") and one lateral pipeline. Each physical lineloop (a parent lineloop with a set of primary reference mode station series features that form a end-to-end network) belongs to one or more logical line loops. And ultimately all lineloops belong the the ‘ACME Transmission PL’ parent lineloop. The logical view is presented below.

ACME 12" Main(Physical) Lineloop #2

a

10" Lateral(Physical) Lineloop #6

B

D

ACME Transmission PL(Logical) Lineloop #1

10" Main B(Physical) Lineloop #5

10" Main A(Physical) Lineloop #4

ACME 10" Main(Logical) Lineloop #3

Transmission System Example – Logical View

b – This diagram represents the ACME Transmission Pipeline Company showing the relationships between the LineLoop and the LineLoopHierarchy object classes. Each Lineloop exists as a record in the Lineloop object class. For every parent-child relationship between Lineloops a record is placed in the LineLoopHierarchy object class. These relationships are illustrated by the hierarchy view (above) and the pseudo-tables showing each individual text line in the box as a record in the class.

ACME Transmission PL

ACME 12" Main has StationSeries

ACME 10" Main

10" Main A has StationSeries

10" Main B has StationSeries

10" Lateral has StationSeries

b

#1 - ACME Transmission PL#2 - ACME 12" Main#3 - ACME 10" Main#4 - 10" Main A#5 - 10" Main B#6 - 10" Lateral

LineLoop

ACME Transmission PL, ACME 12" MainACME Transmission PL, ACME 10" MainACME Pipeline System, 10" LateralACME 10" Main, 10" Main AACME 10" Main, 10" Main B

LineLoopHierarchy

There are two kinds of Lineloops as determined by the relationship between the LineLoop object class and the StationSeries feature class.

Logical – A Logical Lineloop has no (0) related child StationSeries features.Physical – A physical Lineloop has 1 or more related child StationSeries features belonging to the PRM.

Each and every Lineloop may have one or more parent

Lineloops.Each and every

Lineloop may be the child of one or more

parent Lineloops.

Logical LineLoop

Physical LineLoop

Related StationSeries

Figure 23


November 2010 120

Figure 24 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 Table 7

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 models a hierarchy between parent and children LineLoops. A single line loop may be the parent to one or more child line loops (see 11.1.2.7 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. 11.1.2.7 LineLoopHierarchy Class Name: LineLoopHierarchy Feature Class Geometry:


APDM Inheritance:



ParentLineLoopEventID (GUID) - Foreign key to a parent LineLoop object.

ChildLineLoopEventID (GUID) - 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 11.1.2.6 LineLoop). In the transmission system, let the ‘ACME System’ be the parent of the ‘ACME 12”’ and ‘ACME 10”’


November 2010 122

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

Table 8 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. 11.1.2.8 OwnerOperator Class Name: OwnerOperator Feature Class Geometry:


APDM Inheritance:



CompanyEventID (GUID) – Foreign key to the Company object class.

LineLoopEventID (GUID) -- Foreign key to the LineLoop object class.

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

OwnerType (String, 50) clOwnershipType – Type of participation, e.g. ‘Ownership’, ‘Operator’.


LineLoopOwnerOperator (core): LineLoop is 1:M 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. 11.1.2.9 Product Class Name: Product Feature Class Geometry:


APDM Inheritance:



Product (String, 50) – clProduct (Default=Unknown) – Product type, e.g. ‘Oil’, ‘Natural Gas’

Relationships: (cardinality, optionality,

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


November 2010 124

composite, inheritance) 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). 11.1.2.10 Site Class Name: Site Feature Class Geometry:


APDM Inheritance:

ESRI Object APDMObject ObjectArchive CenterlineObject (Ancestors – Abstract)


SiteName (String, 45) – The name of the site. SiteType (String, 50) opSiteType –The type of site contained within

the boundary (e.g., meter station, compressor station) Relationships: (cardinality, optionality, composite, inheritance)

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 SitePoint: Site is 1:M to SitePoint (Optional) SiteBoundary: Site is 1:M to SiteBoundary (Optional)

SubTypes: -- The Site object class is designed to store information about the various stations and other properties housing facilities owned by a pipeline company. Site objects store the name and type of the facility. It is optional to represent Site boundaries as either or both point and polygon features. Polygon 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. It is not uncommon for these facilities to require several polygon boundaries. Site features may also be used to demarcate the limit of stationed pipes and non-stationed pipes. Sites can likewise be represented by point features for representing the site features on large scale maps as a single point. 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. 11.1.2.11 SubSystem Class Name: LineLoopHierarchy Feature Class Geometry:


APDM Inheritance:

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


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


November 2010 126

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

C

SubsystemsSubSystems represent an secondary method of organizing and locating features on or along the centerline of a pipeline system. A Subsystem represents an operationally significant area, boundary, unit or jurisdiction that the pipeline centerline passes through. This area may be demarcated by a polygonal boundary or a beginning and ending stationed position along the centerline. SubSystems provide a mechanism for sub-dividing the centerline into SubSystem ranges (Centerline Polyline Events similar to Online Polylines). SubSystem ranges tie the Subsystem to the centerline by having a relationship with StationSeries which is related directly to a Lineloop. In this manner the intersection between SubSystems and Linelloops can be derived.

The difference between a physical and logical SubSystem is based on the number of SubSystemRange features the SubSystem is related to.

OperationalStatus <d>

CenterlineObject

APDMObject

[Object]

[ObjectArchive]

EventID (pk)

SubSystemName

SubSystemParentSubSystemEventID (fk)ChildSubSystemEventID (fk)

SubSystemHierarchy

SubSystemAuditSubSystemEventID (fk)

Site

Contact

A

Operations SubSystem Example

a – This diagram represents the ACME Transmission Pipeline Company and the Operating Divisions and Districts that are used to organize the pipeline into manageable units. The pipeline is divided into two divisions (Western and Eastern). Each division is divided into two districts (District 1, 2 and District 3, 4 respectively. The portion of the centerline that intersects the district boundaries is used to create SubSystem range (SSR) CenterlinePolylineEvent features. The logical view is presented below.

a

B

D

Operating Divisions(Logical) SubSystem #2

Operations SubSystem Example – Logical View

b – This diagram represents the ACME Transmission Pipeline Company showing the relationships between the SubSystem and the SubSystemHierarchy object classes. Each SubSystem exists as a record in the SubSystem object class. For every parent-child relationship between SubSystems a record is placed in the SubSystem object class. These relationships are illustrated by the hierarchy view (above) and the pseudo-tables (below) showing each individual line in the box as a record in the class. Note also the color coding showing the relationships between the Physical SubSystems records and the related SubSystemRange features.

ACME Transmission PLb

#1 - ACME Transmission PL#2 - Operating Divisions#3 - Western Division#4 - Eastern Division#5 - District #1#6 - District #2#7 - District #3#8 - District #4

SubSystem

ACME Transmission PL, Operating DivisionsACME Transmission PL, Operating Divisions Operating Divisions, Western Division Operating Divisions, Eastern DivisionWestern Division, District #1Western Division, District #2Eastern Division, District #3Eastern Division, District #4

SubSystemHierarchy

There are two kinds of SubSystems as determined by the relationship between the SubSystem object class and the SubSystemRange feature class.

Logical – A Logical SubSystem has no (0) related child SubSystemRange features.Physical – A physical SubSystem has 1 or more related child SubSystemRange features.

Each and every SubSystem may

have one or more parent

SubSystems.Each and every SubSystem may

be the child of one or more parent

SubSystem. Logical SubSystem

Physical SubSystem

SubSystem Rnage


SubSystemEventID (fk)

SubSystemRange

StationSeries

AltRefMeasure

Western Division

(Logical) SubSystem #3

Eastern Division

(Logical) SubSystem #4

District 1(Physical) SubSystem #5

District 2(Physical)

SubSystem #6


SubSystem #7


SubSystem #8

SSR-1SSR-2

SSR-3SSR-4

SSR-6SSR-7

SSR-5SSR-8

SSR-9SSR-10

SSR-11

Operating Divisions

SubSystemRange are located on the centerline as events or features and therefore must be related to a Primary Reference Mode StationSeries feature.

Operations SubSystem Example – Physical Viewc

SubSystemRange-1SubSystemRange-2SubSystemRange-3SubSystemRange-4SubSystemRange-5SubSystemRange-6SubSystemRange-7SubSystemRange-8SubSystemRange-9SubSystemRange-10SubSystemRange-11

SubSystemRange

c – This diagram shows the three SubSystem object/feature classes. Each SubSystem may have a parent or child and that record is shown in the SubSystemHierarchy object class. Each SubSystem may be a Physical SubSystem and have one or more SubSystemRange features demarcating the range of the SubSystem on the centerline.

SSR1

Western Division

District #1

SSR2

SSR3

District #2

SSR4

SSR5

Eastern Division

District #3

SSR6

SSR7

SSR8

SSR9

District #4

SSR10

SSR11



Figure 25

Figure 26 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


November 2010 128

10 Jefferson County Table 9

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. 11.1.2.12 SubSystemHierarchy Class Name: SubSystemHierarchy Feature Class Geometry:


APDM Inheritance:



ParentSubSystemEventID (GUID) - Foreign key to a parent SubSystem object.

ChildSubSystemEventID (GUID) - 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 2.2.2.10 Site and 2.2.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.


November 2010 130

The SubSystemHierarchy table for the hypothetical subsystem hierarchy is populated with the following records (GUIDs are replaced with the above integer designations for clarity):

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

Table 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. 11.2.1 Core Feature Classes 11.2.1.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 (String, 50) – clControlPointType – The type of control point (e.g., point of inflection, monument, line crossing.

PIDirection (String, 50) – 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’).


RouteControlPoint (core): StationSeries is 1:M with ControlPoint SeriesControlPoint (core): StationSeries is 1:M with ControlPoint ControlPointAudit (core): ControlPoint is 1:M with

ControlPointAudit. GeoMetaData (core): ControlPoint is M:N with GeoMetaData.



SubTypes: None The ControlPoint feature class lies at the heart of the APDM. The ControlPoint feature class stores points of known X,Y (optionally Z) position and known station value (measure) along the pipeline centerline. Control point features define the pipeline centerline. The ControlPoint feature class has one or more many-to-one relationships with the StationSeries feature class; one for each ReferenceMode in the system. Within a given reference mode, 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 ControlPoint feature class must contain a FK attribute and a station/measure attribute for each ReferenceMode in the Geodatabase. In this manner the control points can store multiple stationing/measure values. Only a single control point is required at the vertex of the primary reference mode (PRM) station series feature. The control point then inherits the stationing and relationship attributes of all other non-PRM reference modes. In this manner, one control point can store many stationing/measure values. 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.) 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 ReferenceMode be defined as the primary reference mode (default measurement system) for the pipeline centerline. Other 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 station series features. Representations for all control point (and station series) features must be present at each vertex of the primary reference mode and at the end-point junctions (representing station equations) of any secondary reference mode station series feature where the refernce mode is considered ‘interruptable’. In this manner, all online features will store all reference modes. 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 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


November 2010 132

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.

Figure 27 Changes from Version 4.0 to Version 5.0 Only a single set of control points will be maintained in APDM 5.0. In APDM 4.0 a complete set of control points was maintained for each station series feature. APDM5.0 default implementation requires a ‘continuous’ measure route station series be present for each physical LineLoop object in the model. Each vertex of the continuous measure route station series feature will have a control point. The control point will now contain the XYZ values of the vertex and a foreign key and measure field for each type of reference mode listed in the ReferenceMode

table. This diagram shows in APDM 5.0 where for each station series one set of control points would be maintained for both the continuous and engineering station series. In this example a minimum of two control points would be stored in the APDM for the same XYZ location. At the equation points, where two engineering station series abut against each other, there will be a minimum of three control points – one continuous control point, two engineering control points – one at the end of the first engineering station

series, one at the beginning of the second engineering station series.


0.0,0.0 10.0,10.0 50.0,50.0 60.0,60.040.0,40.0

15.0,25.0 5.0,35.0

0.0,40.0

20.0,20.0

20.0,20.0b cd

e

f g

hi

jk

0.0 10.0 50.0 60.020.0 40.0

25.0 35.0

AContinuous Station Series

LineLoop Q1

0.0 10.0 50.0 60.020.0 40.0

25.0 35.0

Continuous Control Points

0.0 10.0 50.0 60.020.0 40.0

15.0 5.0

120.0

0.0

2

3Engineering Station Series

0.0 10.0 50.0 60.040.0

15.0 5.0

0.0

20.020.0

Engineering Control Points



Figure 28 In APDM 5.0 control points sharing the same XYZ coordinate but different reference modes are merged into a single control point. In the diagram below the APDM 5.0 control points are shown. Instead of duplicate points being maintained for all sets of control points only a single point is saved. Non-equation control points B, C, F, G, J, and K are merged into a single point. Equation points D, E, H, I now require two points – one for each engineering station series at the equation, rather than the three points that were required in APDM 4.0. To facilitate the merging of control points new attributes are required to manage this data. The diagram in the following page shows the new additions to the ControlPoint feature class schema. Each control point must have a two foreign key attributes – one for each reference mode. Each Control point must have two measure or station value attributes – one for each reference mode.


CenterlinePolyline


StationSeries

Lineloop

SubSystemRange

ControlPoint



OBJECTID[Object]

[Feature]

OperationalStatus <d>RouteEventID (fk)MeasureValueSeriesEventID (fk)StationValuePoint_XPoint_YPoint_ZCLControl <d>CLStationEditResponse <d>CLXYEditResponse <d>CLZEditResponse <d>SymbolRotation

CenterlinePoint


ControlPoint

GeoMetaData



OBJECTID[Object]

[Feature]

StationSeries and ControlPoint FeatureClasses

Figure 29


November 2010 134

The ControlPoint feature class now contains the EventID value of both the Continuous Route Station series and the Engineering Station series feature that it belongs to. The ControlPoint feature also contains a MeasureValue and a StationValue for each of these station series features. 11.2.1.2 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)


LineLoopEventID (GUID) – 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.

ParentStationSeriesEventID (GUID) – A foreign key pointing to the EventID of a PRM StationSeries feature that non-PRM StationSeries feature is derived from. This column is acting as a self-relate FK to/from StationSeries. Note: This type of relationship is not support by ESRI Geodatabase technology.

FromStationSeriesEventID (GUID) – A foreign key pointing to the EventID of the StationSeries feature connected to the ‘starting’ end of the current StationSeries feature.

ToStationSeriesEventID (GUID) – A foreign key pointing to the EventID of the StationSeries feature connected to the ‘ending’ end of the current StationSeries feature.

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

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

StationSeriesName (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.

RefMode (String, 50) – clRefMode (Default=Continuous) – Indicates the linear referencing schemes for use within the geodatabase. Describes the style of measure that is applied to each route feature in the StationSeries feature class.


RouteControlPoint (core): StationSeries is 1:M with ControlPoint. SeriesControlPoint (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>

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

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

SubTypes: None 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 (RouteEventID or SeriesEventID) 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 PRM station series (route) but make begin and end on separate interrupted station series (series - BeginSeriesEventID and EndSeriesEventID). The FromStationSeriesEventID, FromConnectionStationValue, ToStationSeriesEventID, 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 two one-to-many relationship between the StationSeries feature class and each referenced online point feature class and three one-to-many relationships between the StationSeries feature class and each referenced online polyline feature class; these relationships type is core to the model. Each online feature is referenced to a PRM station series feature; the location and measure (station) values of online features are defined and constrained by their underlying related PRM and ARM station series features. The StationSeries feature class also has two one-to-many relationships with the ControlPoint feature class. These relationships embody 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).


November 2010 136

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 a RefMode value (in the place of the SubTypeCD value in APDM 4.0). This value identifies which reference mode the station series is implementing (continous, engineering, etc.) but also acts as a FK ‘relate’ item to the ReferenceMode table. The APDM requires that one ReferenceMode be chosen as the primary stationing or referencing method (the default and Primary Reference Mode or PRM). 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. 11.2.1.3 SubSystemRange Class Name: SubSystemRange Feature Class Implemented as an M-Aware (and optionally Z-Aware) Polyline



Geometry: Feature class. APDM Inheritance:

ESRI Feature FeatureArchive CenterlinePolyline CenterlinePolylineEvent (Ancestors – Abstract)


SubSystemEventID (GUID) - Foreign key to a SubSystem object.


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

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

Figure 30

Table 11 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 two many-to-one relationships with StationSeries; the location and station values for each SubSystemRange feature are constrained by the associated route or continuous station series and the interrupted engineering station series.

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)


November 2010 138

11.2 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

Table 12 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. 11.2.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

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


November 2010 140

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

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

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



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

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

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

11.2.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:


November 2010 142

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

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

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

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

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

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


November 2010 144

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

12.0 Implementation The following section describes considerations that need to be addressed by an organization planning to implement the APDM as a geodatabase. The standing 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 5.0 is ArcGIS 9.3 and 9.3.1. All design and implementation considerations are based on the technology available at these releases of ArcGIS.



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


November 2010 146

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

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

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


November 2010 148

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


November 2010 150

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


November 2010 152

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


November 2010 154

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



13.0 Optional Object and Feature Classes The following subsections describe the non-core feature/object classes in the model. The object and feature classes presented in this section comprise the optional classes of the APDM. They are included as examples for those implementing the APDM who have no current data model, and may also be of some use to those with incomplete data models. However, none of the feature and object classes in the following sections are required elements of the model. The organization of the optional object and feature classes follows the same groupings as depicted on the APDM Logical Model diagram. 13.1 Centerline and Hierarchy Classes 13.1.1 SitePoint Class Name: SitePoint Feature Class Geometry:

Implemented as a Point feature class.

APDM Inheritance:

ESRI Object Feature Feature Archive OfflineFacility OfflinePointFacility

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

None.

Relationships: (cardinality, optionality, attributes, composite)

SitePoint: SitePoint is 1..1 with Site

SubTypes: -- Notes: SitePoint is used to indicate the center point of a site. 13.1.2 SiteBoundary Class Name: SiteBoundary Feature Class Geometry:

Implemented as a Polygon feature class.

APDM Inheritance:

ESRI Object Feature Feature Archive OfflineFacility OfflineNonPointFacility

Attributes: (name, type, length, precision,

None.


November 2010 156

scale, domain, description) Relationships: (cardinality, optionality, attributes, composite)

SiteBoundary: SiteBoundary is 1..1 with Site

SubTypes: -- Notes: SiteBoundary is used to reference the perimeter boundary of a site. 13.2 Facilities Classes 13.2.1 Appurtenance Class Name: Appurtenance Feature Class Geometry:

Implemented as an M-Aware Point feature class.

APDM Inheritance:

ESRI Object Feature Feature Archive OnlineFeature OnlineFacility OnlinePointFacility


AppurtenanceType (String, 50) fcAppurtenanceType – The appurtenance type (e.g., anchor rod, river weight).


AppurtenanceAudit: Appurtenance is 1:M with AppurtenanceAudit

SubTypes: -- The Appurtenance feature class is used to store ad hoc, non-pressurized point features that are found on and along a pipeline system. The Appurtenance feature class can be used as a catchall for referenced online point features that do not fit into any other APDM feature class and for which a minimum common set of attributes must be recorded. Typical appurtenances include anchor rods, hold-down blocks, river weights, and thrust blocks. 13.2.2 Casing Class Name: Casing Feature Class Implemented as an M-Aware Polyline feature class.



Geometry: APDM Inheritance:

ESRI Object Feature Feature Archive OnlineFeature OnlineFacility OnlinePolylineFacility


CasingLength (Short Integer, 4) – The length of the casing unit along the pipeline.

CrossingType (String, 50) fcCasingCrossingType – The type of line crossing over the pipeline (e.g., road, railroad).

Filled (String, 50) gnYesNo (required APDM domain) – Indicates if the casing is filled with some material. The gnYesNo domain is considered a ‘core’ APDM domain and must be implemented verbatim.

InsulatorType (String, 50) fcCasingInsulatorType – The type of insulator protecting the casing (e.g., concrete, plastic).

OutsideDiameter (String, 50) fcDiameter (required APDM domain) – The outside diameter of the casing (e.g., 24", 36"). The fcDiameter domain is considered a ‘core’ APDM domain and must be implemented verbatim.

SealType (String, 50) fcCasingSealType – The type of seal used to close the casing (e.g., epoxy, case seal).

Shorted (String, 50) gnYesNo (required APDM domain) – Indicates if the casing is electrically conductive. The gnYesNo domain is considered a ‘core’ APDM domain and must be implemented verbatim.

Vented (String, 50) gnYesNo (required APDM domain) – Indicates if the casing is vented for air/water circulation/drainage. The gnYesNo domain is considered a ‘core’ APDM domain and must be implemented verbatim.

WallThickness (String, 50) fcWallThickness (required APDM domain) – The wall thickness of the casing. The fcWallThickness domain is considered a ‘core’ APDM domain and must be implemented verbatim.


CasingAudit: Casing is 1:M with CasingAudit

SubTypes: -- The Casing feature class represents a protective structural device surrounding a pipe segment. Casings are used to protect pipelines from the weight, pressure, and vibration caused by traffic on roads, railroads, and other types of line crossings. 13.2.3 Closure


November 2010 158

Class Name: Closure Feature Class Geometry:


APDM Inheritance:

ESRI Object Feature Feature Archive OnlineFeature OnlineFacility OnlinePointFacility Fitting


ClosureType (String, 50) fcClosureType – The type of closure (e.g., blind flange, hinged, plug).

Specification (String, 50) fcSpecificationClosure -- The specification the closure was manufactured to. The API, ANSI, ASTM and other organizations all publish specifications. Specification include characteristics like ovality, wall thickness variation, test requirements, strength, etc. (e.g., ANSI, API 5).


ClosureAudit: Closure is 1:M with ClosureAudit

SubTypes: -- The Closure feature class represents the terminus or endpoint of a pipeline. A closure is designed to interrupt (and typically contain) pressurized flow at the end of a pipe segment. 13.2.4 Coating Class Name: Coating Feature Class Geometry:

Implemented as an M-Aware Polyline feature class.

APDM Inheritance:



CoatingCondition (String, 50) fcCoatingCondition – The last known condition of the coating (e.g., disbonded, intact).

CoatingLength (Double, 15,2) – The length of the coating application.

CoatingLocation (String, 50) fcCoatingLocation – The location of the coating (e.g., internal/external).

CoatingMaterial (String, 50) fcCoatingType – The type of coating (e.g., epoxy, asphalt, enamel).

CoatingMill (String, 50) fcCoatingManufacturer – The mill that manufactured the coating (e.g., DuPont, BASF).

CoatingSource (String, 50) fcCoatingApplicationSource – The place the coating was applied (e.g., mill, in situ).

InternalCoating (String, 50) gnYesNo (required APDM domain) –



Indicates if coating was applied to inside of pipe. The gnYesNo domain is considered a ‘core’ APDM domain and must be implemented verbatim.


CoatingAudit: Coating is 1:M with CoatingAudit

SubTypes: -- The Coating feature class represents the materials that are spread over a set of pipe segments and fittings to preserve the metal from corrosion and exposure to environmental conditions. Coating can be applied to the internal and/or external surfaces of pipe segments. It is also common for coating features to overlap other coating features. A pipe segment can potentially have zero or more internal and zero or more external applications of coating. 13.2.5 Elbow Class Name: Elbow Feature Class Geometry:


APDM Inheritance:



ElbowAngle (Double, 15,2) gnAngle (required APDM domain) – The angle the elbow bends the pipeline (e.g., 30°, 45°). The gnAngle domain is considered a ‘core’ APDM domain and must be implemented verbatim.

ElbowRadius (Double, 15,2) gnRadius – The radius of the elbow from one endpoint of the elbow to the other endpoint.

Spectification (String, 50) fcSpecificationElbow -- The specification the elbow was manufactured to. The API, ANSI, ASTM and other organizations all publish specifications. Specification include characteristics like ovality, wall thickness variation, test requirements, strength, etc. (e.g., ANSI, API 5).


ElbowAudit: Elbow is 1:M with ElbowAudit

SubTypes: -- The Elbow feature class describes manufactured elbow fittings. An elbow feature typically represents a bend in the pipeline at a specific angle. An elbow is typically


November 2010 160

manufactured in angle increments of 15 degrees. Elbow features are designed to carry pressurized product. 13.2.6 Instrument Class Name: Instrument Feature Class Geometry:


APDM Inheritance:



Manufacturer (String, 50) fcInstrumentManufacturer – The instrument manufacturer.

Model (String, 50) instrUnknownModel – The instrument model (model domain is dependent on instrument type).

SerialNumber (String, 30) – The instrument serial number. DateManufactured (Date) – The date the instrument was

manufactured. InstrumentName (String, 80) – The instrument name or description.


InstrumentParameter: Instrument is 1:M with InstrumentParameter InstrumentAudit: Instrument is 1:M with InstrumentAudit

SubTypes: -1 – Unknown (Verified) 0 – Unknown 1 – Flow Control Valve 2 – Flow Computer 3 – Gas Chromatograph 4 – Gas Sampler 5 – Level Controller 6 – Level Indicator 7 – Liquid Sampler 8 – Pressure Controller 9 – Pressure Gauge 10 – Pressure Recorder 11 – Pressure Switch 12– Pressure Transducer 13 – Pressure Transmitter 14 – Solar Panel 15 –Temperature Switch 16 – Valve Position Indicator 17 – Valve Positioner 18 –Corrosion Coupon



19 –ER Probe Note: The instrument feature class is subtyped by instrument type, so new instrument types may be easily added to the model with out resorting to the creation of additional feature classes.

The Instrument feature class stores information about facilities and equipment typically found on a Process and Instrumentation Diagram (P&ID). Examples of these types of equipment include pressure and temperature sensors, pressure and temperature transmitters, pressure regulators, level indicators, level controllers, valve position indicators, valve positioners, gas samplers, gas chromatographs, flow computers, E/R probes, etc. Many implementers will choose not to capture all the piping found in a compressor or pump station. For this reason, not all records in the Instrument feature class will have a shape, a Station value and a StationSeriesEventID value. The relationship between Instrument and Site (through the inherited attributes) is so that Instrument features not related to a Station Series may still be related to a Site (compressor, valve, or pumping station). The InstrumentParameter table stores information about instruments. 13.2.7 Meter Class Name: Meter Feature Class Geometry:


APDM Inheritance:



MeterFunction (String, 50) fcMeterFunction – The main function the meter provides (e.g., check, custody transfer)

MeterName (String, 30) – An organizational name or number assigned to the meter.

MeterNumber (Long Integer, 9) – Uniquely identifies the meter within a group of meters.

MeterType (String, 50) fcMeterType – The meter style or type (e.g., turbine, rotary, positive displacement).

RemoteNetworked (String, 50) gnYesNo(required APDM domain) – Indicates if the meter can be operated via remote network. The gnYesNo domain is considered a ‘core’ APDM domain and must be implemented verbatim.

SerialNumber (String, 30) – The factory assigned serial number for the meter.

Spectification (String, 50) fcSpecificationMeter -- The specification the meter was manufactured to. The API, ANSI, ASTM and other organizations all publish specifications. Specification include characteristics like ovality, wall thickness variation, test requirements, strength, etc. (e.g., ANSI, API 5).


November 2010 162


MeterAudit: Meter is 1:M with MeterAudit

SubTypes: -- The Meter feature class contains information describing manufactured, pressurized fittings that are used to monitor flow, pressure, and composition of product as it is transported along a pipeline. 13.2.8 PigStructure Class Name: PigStructure Feature Class Geometry:


APDM Inheritance:



BarrelDiameter (String, 50) fcDiameter (required APDM domain) – The outer diameter of the barrel or pipe of the structure. The fcDiameter domain is considered a ‘core’ APDM domain and must be implemented verbatim.

BarrelGrade (String, 50) fcGrade – The grade of the material to which the structure barrel is rated

BarrelWallThickness (String, 50) fcWallThickness (required APDM domain) – The wall thickness of the structure barrel or pipe. The fcWallThickness domain is considered a ‘core’ APDM domain and must be implemented verbatim.

Manufacturer (String, 50) fcPipeManufacturer – The manufacturer of the structure barrel or pipe

Material (String, 50) fcMaterial (required APDM domain) – The material used to manufacture the structure (e.g., steel). The fcMaterial domain is considered a ‘core’ APDM domain and must be implemented verbatim.

MillLocation (String, 50) fcMillLocation – The name/location of the mill that manufactured the structure

PressureRating (String, 50) fcPressureRating (required APDM domain) – The pressure rating of the structure. The fcPressureRating domain is considered a ‘core’ APDM domain and must be implemented verbatim.

StructureLength (Double, 15,2) – The actual length of the structure StructureType (String, 50) fcPigStructureType– The type of pig

structure – launcher or receiver or Multi-Function.




PigStructureAudit: PigStructure is 1:M with PigStructureAudit

SubTypes: The PigStructure feature class models launcher and receiver facilities used to launch and receive inline inspection PIGs. Inline inspection PIGs are used to detect corrosion and geometric anomalies in a reach of pipeline using pressurized flow to propel the PIG through the pipe. Launchers and receivers are often fabricated in situ by a pipeline company. Some pipeline companies station or locate pigging structures via stationing; other companies consider these features to be non-referenced. The APDM does not mandate whether pigging structure features are to be referenced or not. Referenced pigging structure features can optionally be stored as a subtype of the PipeSegment feature class rather than maintained in a separate feature class. 13.2.9 PipeJoinMethod Class Name: PipeJoinMethod Feature Class Geometry:


APDM Inheritance:



Insulated (String, 50) gnYesNo (required APDM domain) – Indicates if the join method is insulated (used to delineate cathodic projection zones). The gnYesNo domain is considered a ‘core’ APDM domain and must be implemented verbatim.

JoinType (String, 50) fcWeldType – Description of the join method type depending on the feature subtype.

Manufacturer (String, 50) fcFittingManufacturer(required APDM domain) – The manufacturer of the structure barrel or pipe. The fcFittingManufacturer domain is considered a ‘core’ APDM domain and must be implemented verbatim.

PressureRating (String, 50) fcPressureRating(required APDM domain) – The pressure rating of the structure. The fcPressureRating domain is considered a ‘core’ APDM domain and must be implemented verbatim.


PipeJoinMethodAudit: PipeJoinMethod is 1:M with PipeJoinMethodAudit


November 2010 164

SubTypes: 1 – Weld 2 – Coupling 3 – Flange 4 – Screw 5 – Electro Stop

The PipeJoinMethod feature class stores information about the features that are used to join pipe segments with varying attributes and features for which information must be explicitly recorded. A pipe segment feature in a pipeline system is a generalized feature that is composed of many pipes sharing the same attribute values. When attribute values change between pipe segments, then a pipe join method feature (typically a weld) is placed in between the pipe segments. Other features that are used to link two connected pipe segments can be stored in the PipeJoinMethod feature class. These features share a common set of attributes and can be divided into separate feature classes as required. Some join method features are manufactured (flanges) and others are constructed or applied in the field (e.g., welds, couplings). 13.2.10 PipeSegment Class Name: PipeSegment Feature Class Geometry:


APDM Inheritance:



BendRadius (Double, 15,2) gnRadius – The radius from a centerpoint to the ends of the pipe segment.

DateManufactured (Date) – The date the pipe segment was originally manufactured.

GirthWeld (String, 50) fcWeldType – The type of weld used to link the pipes that form the pipe segment

Grade (String, 50) fcGrade – Grade refers to the chemical composition of the steel used to manufacture the pipe. Grade A (less carbon) has lower strength, but higher ductility; Grade B (more carbon) is higher strength, but less ductile.

InletWallThickness (String, 50) fcWallThickness (required APDM domain) – The inlet wall thickness of the pipe segment. The fcWallThickness domain is considered a ‘core’ APDM domain and must be implemented verbatim.

LongitudinalSeam (String, 50) fcLongitudinalWeld – The type of weld used along the length of the pipes that form the pipe segment.

LongitudinalSeamOrientation (Double, 15,10) gnOrientation – The location of the seam on the pipe (zero degrees is up).

Manufacturer (String, 50) fcPipeManufacturer – The manufacturer



of the pipes that form the pipe segment. Material (String, 50) fcMaterial (required APDM domain) – The

material that pipes were constructed of (e.g., PVC, steel). The fcMaterial domain is considered a ‘core’ APDM domain and must be implemented verbatim.

MillLocation (String, 50) fcMillLocation – The location of the mill where the pipes that form the pipe segment were manufactured.

MillTestPressure (String, 50) – The recorded test pressure when the pipe was milled.

OutsideDiameter (String, 50) fcDiameter (required APDM domain) – The diameter of the outer wall of the pipes that form the pipe segment. The fcDiameter domain is considered a ‘core’ APDM domain and must be implemented verbatim.

OutletWallThickness (String, 50) fcWallThickness (required APDM domain) – The outlet wall thickness of the pipe segment. The fcWallThickness domain is considered a ‘core’ APDM domain and must be implemented verbatim.

PipeJurisdiction (String, 50) – The jurisdiction the pipe segment performs (e.g., Gathering, Transmission, Distribution).

PreTested (String, 50) gnYesNo (required APDM domain) – Indicates if the pipe was pretested before it was installed. The gnYesNo domain is considered a ‘core’ APDM domain and must be implemented verbatim.

PressureRating (String, 50) fcPressureRating (required APDM domain) – Indicates the operating pressure of the pipe segment. The fcPressureRating domain is considered a ‘core’ APDM domain and must be implemented verbatim.

SegmentLength (Double, 15,2) – The assigned/recorded length of the pipe segment.

SegmentType (String, 50) fcPipeSegmentType – Indicates what the linear pipe segment feature is representing – pipe segments, bends, transitions, and valve/elbow/meter/reducer and tee assemblies.

Specification (String, 50) fcSpecificaton – The specification the pipe segment was manufactured to. The API, ANSI, ASTM and other organizations all publish pipe specifications. Specification include characteristics like ovality, wall thickness variation, test requirements, strength, etc. (e.g., ANSI, API 5).


PipeSegment: PipeSegment is 1:M with PipeSegmentAudit

SubTypes:


November 2010 166

The PipeSegment feature class is used to model the primary conduit of pressurized product flow of a pipeline system: pipes. The typical length of pipe used in transmission pipelines is 40 feet. Pipe segment features aggregate many of these pipes into a single feature with common attribute values. Traditionally it is common implementation practice to not explicitly represent pipe or the joints in between individual pipe. Rather, pipes were aggregated into larger pipe segment features where all attribute values between the pipes were equal. Where the attribute values changed from pipe segment to pipe segment, a pipe join feature was placed. Pipes represent straight pipe features. A bend is a field fabrication where a pipe is bent over a distance to force the pipeline to turn. A transition pipe segment represents where the diameter of the pipe changes over a specified distance. When a pipe segment feature is altered, removed, or abandoned, then a cascade of data maintenance must occur to maintain concurrency between the pipe segment feature and the dependent features. 13.2.11 Reducer Class Name: Reducer Feature Class Geometry:


APDM Inheritance:



OutletConnectionType (String, 50) fcConnectionType(required APDM domain) – The inlet connection type (e.g., weld, thread). The fcConnectionType domain is considered a ‘core’ APDM domain and must be implemented verbatim.

OutletDiameter (String, 50) fcDiameter (required APDM domain) – The diameter of the outlet. The fcDiameter domain is considered a ‘core’ APDM domain and must be implemented verbatim.

OutletWallThickness (String, 50) fcWallThickness (required APDM domain) – The thickness of the fitting at the outlet opening. The fcWallThickness domain is considered a ‘core’ APDM domain and must be implemented verbatim.

ReducerSize (String, 50) fcRecuderSize – The size of both input and output pipe diameters connected to the reducer (e.g., 4x12, 6x8)

ReducerType (String, 50) fcReducerType – The type of reducer (e.g., concentric weld, full open, swedge)

Specification (String, 50) fcSpecificatonReducer – The specification the reducer was manufactured to. The API, ANSI, ASTM and other organizations all publish pipe specifications. Specification include characteristics like ovality, wall thickness variation, test requirements, strength, etc. (e.g., ANSI, API 5).

Relationships: ReducerAudit: Reducer is 1:M with ReducerAudit




SubTypes: -- Reducers are manufactured fittings designed to carry pressurized product. The Reducer feature class stores information about a reducer facility. Reducers are points along the pipeline where the internal diameter of the pipeline is decreased or increased by the reducer. 13.2.12 Sleeve Class Name: Sleeve Feature Class Geometry:


APDM Inheritance:



Grade (String, 50) fcGrade – The grade of the material from which the sleeve is constructed.

NominalDiameter (String, 50) fcDiameter (required APDM domain) – The nominal outside diameter of the sleeve. The fcDiameter domain is considered a ‘core’ APDM domain and must be implemented verbatim.

SleeveLength (Short Integer, 4) – The measured/calculated length of the sleeve.

SleeveType (String, 50) fcSleeveType – The type of sleeve applied to the pipe (e.g., repair, clamp, composite).

WallThickness (String, 50) fcWallThickness (required APDM domain) – The wall thickness of the sleeve. The fcWallThickness domain is considered a ‘core’ APDM domain and must be implemented verbatim.


SleeveAudit: Sleeve is 1:M with SleeveAudit

SubTypes: -- The Sleeve feature class stores information about sleeves, clamps, reinforcements, and other repair features that are applied around the girth of pipes. Sleeve features do not typically overlap each other and are dependent on the presence of a pipe segment feature.


November 2010 168

13.2.13 Tap Class Name: Tap Feature Class Geometry:


APDM Inheritance:



BranchConnectionType (String, 50) fcBranchConnectionType – Description of a reinforcing structure around the tap (e.g., saddle, full encirclement).

Capacity (Short Integer, 4) – A measure of the tap flow capacity CapacityUnits (String, 50) fcCapacityUnits– The units of flow

capacity. Capped (String, 50) gnYesNo (required APDM domain) – Indicates

if the tap is currently capped and does not conduct product flow. The gnYesNo domain is considered a ‘core’ APDM domain and must be implemented verbatim.

FlowDirection (String, 50) fcTapFlowDirection– Indicates flow direction into/from the pipeline system (delivery, receipt, bidirectional).

Manufacturer (String, 50) fcFittingManufacturer (required APDM domain) – The name of the tap manufacturer. The fcFittingManufacturer domain is considered a ‘core’ APDM domain and must be implemented verbatim.

Material (String, 50) fcMaterial (required APDM domain) – The material that the tap is constructed with (e.g., steel, PVC) . The fcMaterial domain is considered a ‘core’ APDM domain and must be implemented verbatim.

Metered (String, 50) gnYesNo (required APDM domain) – Indicates if the tap contains a meter as part of the feature. The gnYesNo domain is considered a ‘core’ APDM domain and must be implemented verbatim.

PressureRating (String, 50) fcPressureRating (required APDM domain) – The pressure rating of the tap. The fcPressureRating domain is considered a ‘core’ APDM domain and must be implemented verbatim.

TapSize (String, 50) fcTapSize– The sizes of the branch pipe connected to the tap (1"–24").

TapSpecification (String, 50) fcSpecification– The specification the Tap was manufactured to. The API, ANSI, ASTM and other organizations all publish pipe specifications. Specification include characteristics like ovality, wall thickness variation, test requirements, strength, etc. (e.g., ANSI, API 5).

TapType (String, 50) fcTapType– The function or style of the tap



(e.g., blow-off, siphon, thread-o-let). TappingMethod (String, 50) fcTappingMethod– The method used

to create the tap (e.g., cold tap, hot tap, weld plus). Relationships: (cardinality, optionality, attributes, composite)

TapAudit: Tap is 1:M with TapAudit

SubTypes: The Tap feature class stores information describing both manufactured tap fittings and tap fabrication (hot taps) located on a pipeline system. The APDM considers a tap to be the joining of two or more pipes at a junction for the purpose of releasing product in a controlled fashion. A tap is usually found in conjunction with a shutoff, check, or release valve. 13.2.14 Tee Class Name: Tee Feature Class Geometry:


APDM Inheritance:



BranchConnectionType (String, 50) fcConnectionType (required APDM domain) – The element used to connect the branch to the main pipe (e.g., weld, flange, thread). The fcConnectionType domain is considered a ‘core’ APDM domain and must be implemented verbatim.

BranchDiameter (String, 50) fcDiameter (required APDM domain) – The outside diameter of the branch pipe. The fcDiameter domain is considered a ‘core’ APDM domain and must be implemented verbatim.

BranchWallThickness (String, 50) fcWallThickness– The wall thickness of the branch pipe.

ScraperBars (String, 50) gnYesNo (required APDM domain) – Indicates if the branch has scraper bars to prevent structural interference with inline pigging devices. The gnYesNo domain is considered a ‘core’ APDM domain and must be implemented verbatim.

TeeSize (String, 50) fcTeeSize – The diameters of the main and branch pipes (e.g., 12x12x4, 6x6x2).

TeeType (String, 50) fcTeeType– The type of tee (e.g., split, stopple, barrel, reducing).

Specification (String, 50) fcSpecificatonTee – The specification the


November 2010 170

tee was manufactured to. The API, ANSI, ASTM and other organizations all publish pipe specifications. Specification include characteristics like ovality, wall thickness variation, test requirements, strength, etc. (e.g., ANSI, API 5).


TeeAudit: Tee is 1:M with TeeAudit

SubTypes: The Tee feature class contains information describing manufactured branch or tee fittings designed to carry pressurized product flow from a main to a branch or secondary pipe. 13.2.15 Valve Class Name: Valve Feature Class Geometry:


APDM Inheritance:



Automated (String, 50) gnYesNo (required APDM domain) – Indicates if the valve automatically opens or closes in certain circumstances. The gnYesNo domain is considered a ‘core’ APDM domain and must be implemented verbatim.

InletConnectionType (String, 50) fcValveConnectionType– The type of connection at the inlet (e.g., weld, flange).

InletDiameter (String, 50) fcDiameter (required APDM domain) – The diameter of the pipe connected to the valve inlet. The fcDiameter domain is considered a ‘core’ APDM domain and must be implemented verbatim.

Manufacturer (String, 50) fcValveManufacturer – The valve manufacturer.

NominalPressure (Long Integer, 9) -- The working pressure of the valve.

NormalPosition (String, 50) gnPresentPosition – The normal position the valve is set to (Open/Closed).

OutletConnectionType (String, 50) fcValveConnectionType– The type of connection at the outlet.

OutletDiameter (String, 50) fcDiameter (required APDM domain) – The diameter of the pipe connected to the valve outlet. The fcDiameter domain is considered a ‘core’ APDM domain and must be implemented verbatim.

PresentPosition (Long Integer, 9) gnPresentPosition– The current



position the valve is set at (Open/Closed). PressureRating (Long Integer, 9) fcPressureRating (required APDM

domain) – The pressure rating of the valve. The fcPressureRating domain is considered a ‘core’ APDM domain and must be implemented verbatim.

ResponseTime (Long Integer, 9) -- The time in minutes the valve requires to complete an action in response to an event.

Specification (String, 50) fcSpecificatonValve – The specification the valve was manufactured to. The API, ANSI, ASTM and other organizations all publish pipe specifications. Specification include characteristics like ovality, wall thickness variation, test requirements, strength, etc. (e.g., ANSI, API 5).

ValveFunction (Long Integer, 9) fcValveFunction – The function that the valve performs (e.g., check, release, main line).

ValveNumber (String, 15) – An organizational number assigned to the valve.

ValveType (String, 50) fcValveType – indicates the type or style of valve in place – angle, ball, check, block, control, curb, gate, plug etc.


ValveAudit: Valve is 1:M with ValveAudit ValveGeoMetaData: Valve is M:N with GeoMetaData ValveOperator: Valve is 1:M with ValveOperator

SubTypes: The Valve feature class contains information describing manufactured, pressurized fittings used to control or impede flow of product through a pipeline system. Valves provide the control structure for the pipeline system and are often connected to the SCADA monitoring system for a pipeline. Valve features are often part of a generalized pipeline network used for capacity, flow, and hydraulic analyses. Valves describe the inlet and outlet connection and diameter and wall thickness information of the connection input and output pipe features. The pipes that run along a single, unaltered (no station equations) station series contain starting and ending values. The Valve feature class has a relationship with the ValveOperator object class which models that zero or more operator types may be used to operate a valve feature. 13.2.16 ValveOperator Class Name: ValveOperator Feature Class Geometry:


APDM Inheritance:

ESRI Object APDM Object Object Archive FacilityObject


November 2010 172


OperatorType (String, 50) fcValveOperatorType– The operator used to open/close the valve (e.g., gas, manual, electric).

ValveEventID (GUID) – Foreign key relate to EventID attribute in the Valve feature class.


ValveOperator: ValveOperator is M:1 with Valve ValveOperatorAudit: ValveOperator is 1:M with

ValveOperatorAudit

SubTypes: -- The ValveOperator feature class describes a non-geometric object related to a particular site. 13.2.17 Vessel Class Name: Vessel Feature Class Geometry:


APDM Inheritance:



Manufacturer (String, 50) fcFittingManufacturer (required APDM domain) – The manufacturer of the vessel. The fcFittingManufacturer domain is considered a ‘core’ APDM domain and must be implemented verbatim.

SerialNumber (String, 30) – The serial number stamped or applied to the vessel by the manufacturer.

VesselType (String, 50) fcVesselType – The type of vessel (e.g., odorizer, filter, scrubber, storage tank).


VesselAudit: Vessel is 1:M with VesselAudit

SubTypes: -- The Vessel feature class describes large volume facility features that are used to contain, process, or alter product on or along the pipeline. 13.2.18 Well Class Name: Well



Feature Class Geometry:


APDM Inheritance:



APINumber (String, 50) -- Well identifier assigned by API (ex: 42-501-20130-03-00)

CompletionDate (Date) -- Date on which drilling was completed. GeologicFormation(String, 50) -- Name of target formation. (ex:

Barnett Shale, Frontier Sands, Niobrara) LegalDescription(String, 255) -- Description of well location using

PLSS designation (ex: NENENW Sec 23, Twp 34S, Rge 21W, Clark County, KS, or 310ft FSL, 2008FEL, A-217, Bee County, TX)

Operator(String,38) -- Name of operating company of the well. SeasonallyActive (String, 50) gnYesNo (required APDM domain) –

Indicates if the well is normally shut-in during specific times of the year (ex: winter, planting season). The gnYesNo domain is considered a ‘core’ APDM domain and must be implemented verbatim.

TieInDate (Date) -- Date well was connected to gathering pipeline. WellName (String, 100) -- Name of well. WellType (String, 50) fcWellType -- Current designation of well.

(ex: Oil, Gas, Dry and Abandoned) Relationships: (cardinality, optionality, attributes, composite)

WellAudit: Well is 1:M with WellAudit

SubTypes: -- The Well feature class describes petroleum wells associated with, or near the pipeline. 13.3 Operations Classes 13.3.1 ElevationPoint Class Name: ElevationPoint Feature Class Geometry:


APDM Inheritance:

ESRI Object Feature Feature Archive OnlineFeature OnlinePoint

Attributes: (name, type, length, precision,

FeatureElevation (Double, 15, 2) – Depth of a pipeline feature below ground surface.

GroundElevation (Double, 15, 2) – Elevation of the ground at a


November 2010 174

scale, domain, description)

specific location. MeasurementDate (Date) – Date the elevation value was recorded. WaterElevation (Double, 15, 2) – Depth of a pipeline feature below

water surface. Relationships: (cardinality, optionality, attributes, composite)

ElevationPointAudit: ElevationPoint is 1:M with ElevationPointAudit

SubTypes: -- The ElevationPoint feature class is designed to store elevations taken at specific points along the pipeline centerline. Anytime that a section of pipe is excavated (or initially placed in the ground) the depths of the pipeline features from the ground surface are recorded. (The engineers need to know the elevation to plan for hydrostatic testing.) Along with the elevation, slope/horizontal distance between elevation points, slope/horizontal stationing, depth of cover, and lat/long information are collected. There are many more ElevationPoints physically on the center line than off the center line. The ElevationPoint feature class is also useful for storing the depth of offshore features that are under water. 13.3.2 FieldNote Class Name: FieldNote Feature Class Geometry:


APDM Inheritance:

ESRI Object Feature Feature Archive OfflineFeature OfflinePoint


FieldNoteType (String, 50) opFNCultural – The type of field note (e.g., structure location, routing angle) based on the subtype of the field note.


FieldNoteAudit: FieldNote is 1:M with FieldNoteAudit FieldNoteGeoMetaData: FieldNote is M:N with GeoMetaData FieldNoteLocation: FieldNote is 1:M with FieldNoteLocation

SubTypes: 1 – Cultural Note 2 – Environmental Note 3 – Facility Note 4 – Geopolitical Note 5 – Hydrology Note



6 – Line Crossing Note 7 – Operations Note 8 – Routing Note 9 – Transportation Note

The FieldNote feature class is designed to store data collected during preliminary routing of pipeline, engineering, environmental, or cultural field surveys. Field notes serve as placeholders for information pertaining to proposed features or survey notes. Field notes also serve as memos or notations that provide additional comments, descriptions, or annotation about existing events or features on or along the pipeline. The GeoMetaData for a field note stores the provenance of the field note's original position and data collection method. 13.3.3 FieldNoteLocation Class Name: FieldNoteLocation Feature Class Geometry:


APDM Inheritance:

ESRI Object Feature Feature Archive OnlineFeature OnlinePoint OnlinePointForOfflineFeature


FieldNoteEventID (GUID) – Foreign key relate to EventID attribute in the FieldNote feature class.


FieldNoteLocation: FieldNoteLocation is M:1 with FieldNote

SubTypes: -- 13.3.4 Marker Class Name: Marker Feature Class Geometry:


APDM Inheritance:



MarkerNumber (String, 15) – An organizational name, code, or number identifying the marker.

MarkerType (String, 50) opMarkerType – The type of marker – mile post, aerial marker, above ground marker, monument, survey point etc.


November 2010 176


MarkerAudit: Marker is 1:M with MarkerAudit MarkerLocation: Marker is 1:M with MarkerLocation

SubTypes: The Marker feature class stores information about monuments, aerial markers, mileposts, and other offline features that determine position along a pipeline. Marker features are not control points since they do not explicitly mark the route of a centerline. Markers are placed at regular intervals or at points of known locations along the pipeline and serve as reference points. Markers may serve as calibration points for station series features for alternate measurement systems. 13.3.5 MarkerLocation Class Name: MarkerLocation Feature Class Geometry:


APDM Inheritance:



MarkerEventID (GUID) – Foreign key relate to EventID attribute in the Marker feature class.


MarkerLocation: MarkerLocation is M:1 with Marker

SubTypes: -- The MarkerLocation feature class stores the designated online locations for Marker features. (As defined, Marker is an offline feature class.) 13.3.6 OnlineFieldNote Class Name: OnlineFieldNote Feature Class Geometry:


APDM ESRI Object Feature Feature Archive OnlineFeature



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

FieldNoteType (String, 50) opFNCultural – The type of field note (e.g., structure location, routing angle) based on the subtype of the field note.


OnlineFieldNoteAudit: OnlineFieldNote is 1:M with OnlineFieldNoteAudit

SubTypes: 1 – Cultural Note 2 – Environmental Note 3 – Facility Note 4 – Geopolitical Note 5 – Hydrology Note 6 – Line Crossing Note 7 – Operations Note 8 – Routing Note 9 – Transportation Note

The OnlineFieldNote feature class is designed to store data collected during preliminary routing of pipeline, engineering, environmental, or cultural field surveys. Field notes serve as placeholders for information pertaining to proposed features or survey notes. Online Field notes also serve as memos or notations that provide additional comments, descriptions, or annotation about existing events or features on the pipeline. 13.3.7 OperatingPressure Class Name: OperatingPressure Feature Class Geometry:


APDM Inheritance:

ESRI Object Feature Feature Archive OnlineFeature OnlinePolyline


ActualPressure (Short Integer, 4) – The recorded or established pressure for a reach along a pipeline.

AgreedToPressure (Short Integer, 4) – The agreed-to pressure between client and customer for a reach of a pipeline.

CalculatedPressure (Short Integer, 4) – The calculated pressure for a reach of pipeline based on physical and operational characteristics of the pipeline.

PressureType (String, 50) opPressureType – The type of operating pressure (e.g., maximum allowable, grandfather, operational).

Relationships: OperatingPressureContact: OperatingPressure is M:N with Contact


November 2010 178


OperatingPressureAudit: OperatingPressure is 1:M with OperatingPressureAudit

SubTypes: -- The OperatingPressure feature class is designed to store features describing the current, designed, and maximum allowable operating pressure zones along a pipeline. Operating pressure features can potentially stretch over long areas of the pipeline system sharing common attribute values. When lengthy linear features span station series, these features must be segmented into lengths no longer than the underlying station series features. The GroupEventID attribute inherited from the OnlinePolyline abstract class can be used to aggregate many separate operating pressure features, with equal attributes, into a single grouped element. The relationship between OperatingPressure and Contact establishes the person responsible for verifying the attributes of an operating pressure feature. 13.3.8 PressureTest Class Name: PressureTest Feature Class Geometry:


APDM Inheritance:



MinAdjustedPressure (Short Integer, 4) – The minimum adjusted pressure of the pressure test

MinDesignPressure (Short Integer, 4) – The minimum design pressure of the pressure test

PreTest (String, 50) gnYesNo (required APDM domain) – Indicates if a pretest was conducted before the actual pressure test. The gnYesNo domain is considered a ‘core’ APDM domain and must be implemented verbatim.

TestDate (Date) – The date on which the pressure test was conducted or started

TestDuration (String, 50) opPressureTestDuration – The duration of the pressure test (e.g., 4, 8, 16 hours)

TestMedium (String, 50) opPressureTestMedium – The medium used to conduct the pressure test (e.g., water, nitrogen)

TestName (String, 45) – The organizational name assigned to the pressure test

TestType (String, 50) opPresureTestType – The type of pressure test conducted (e.g., leak, strength, spike)

Relationships: (cardinality,

PressureTestAudit: PressureTest is 1:M with PressureTestAudit



optionality, attributes, composite) SubTypes: -- The PressureTest feature class is designed to store features describing pressure tests conducted along parts of the pipeline. PressureTest features can potentially stretch over long reaches of the pipeline. When lengthy pressure test features span station series, these features must be segmented into lengths no longer than the underlying station series features. The GroupEventID attribute inherited from the Audit abstract class can be used to aggregate many separate pressure test features, with equal attributes, into a single grouped element. 13.3.9 RightOfWay Class Name: RightOfWay Feature Class Geometry:


APDM Inheritance:



EasementWidth (Double, 15,2) – The width of the easement to either side of the right-of-way feature

ParcelNumber (String, 30) – Records the parcel identification number the right-of-way feature passes through and can be used to link the right-of-way to a property information system

ROWType (String, 50) opRightOfWayType – Describes the arrangement between the land owner and the pipeline (e.g., easement, fee, license).

TraverseLength (Double, 15,2) – The measured length of the right-of-way feature


RightOfWayContact: RightOfWay is M:N with Contact RightOfWayAddress: RightOfWay is M:N with Address RightOfWayAudit: RightOfWay is 1:M with RightOfWayAudit

SubTypes: -- The RightOfWay feature class stores information describing easements and right-of-way information of the pipeline as it passes through polygonal boundaries such as property parcels, operating districts, and municipal/political boundaries. Right-of-way polyline features are used to indicate the starting position of the pipeline as it enters and exits an area including a distance or length value of the reach of the pipeline within the area. Right-of-way features contain easement widths that can be used to buffer the feature. The address and contact relationships model ownership and address information for the


November 2010 180

section of the pipeline that passes through right-of-way. A relationship exists between LineLoop and RightOfWay, which models that a RightOfWay linear feature falls on one and only one LineLoop and is used as a source of identification. 13.4 Event Support Classes 13.4.1 Address Class Name: Address Feature Class Geometry:


APDM Inheritance:

ESRI Object APDM Object Object Archive NonFacilityObject


City (String, 45) – City name. County (String, 45) – County name. Country (String, 60) – Country name. StateProvince (String, 45) – State or Province name. Street1 (String, 45) – Street direction prefix, street number, street

name. Street2 (String, 45) – Street direction suffix, address modifier,

apartment/lot number. ZipPostalCode (String, 15) – ZIP or Postal Code.


CompanyAddress: Address is M:N with Company ContactAddress: Address is M:N with Contact RightOfWayAddress: Address is M:N with RightOfWay StructureOrIDSiteAddress: Address is M:N with

StructureOrIDSite SubTypes: -- The Address object class contains information about a specific address. This address information pertains to encroaching structures, company addresses, and individual mailing addresses. The Address object class provides a simple repository for storing address information for people and places. The Address object class is not intended to be the definitive description of an address. The Address object class was designed to maintain a list of commonly required addresses pertaining to geographic and organizational features in the model that might be contacted via surface mailing and to provide a linkage to customer information systems. 13.4.2 AlignmentSheet Class Name: AlignmentSheet Feature Class Geometry:




APDM Inheritance:

ESRI Object Feature Feature Archive OfflineFeature


SheetName (String, 45) – An organizational name or code that identifies the alignment sheet.

SheetNumber (String, 45) – An organizational name, code, or alias that identifies the alignment sheet.

SheetType (String, 50) – gnAlignmentSheetType – The type of alignment sheet (e.g., engineering, new construction).


--

SubTypes: -- The AlignmentSheet feature class stores the polygonal boundary of the printable geographic map portion of an alignment sheet generated along a reach or section of the pipeline system. The attributes of the AlignmentSheet feature class are purposefully designed to store only generic information due to the high variance of alignment sheet requirements between different pipeline companies. Only the broadest attributes that describe alignment sheets in the most generic terms are included in the model. 13.4.4 Contact Class Name: Contact Feature Class Geometry:


APDM Inheritance:



ContactType (String, 50) gnContactType – Brief job description/organizational position of contact person.

Email (String, 45) – E-mail address. Fax (String, 45) – Fax number. FirstName (String, 45) – First name. LastName (String, 45) – Last name. Mobile (String, 45) – Mobile/Cell phone number. Pager (String, 45) – Pager phone number. Phone (String, 45) – Phone number.


ContactAddress: Contact is M:N with Address LineCrossingContact: Contact is M:N with LineCrossing StructureOrIdSiteContact: Contact is M:N with StructureOrIDSite RightOfWayContact: Contact is M:N with RightOfWay


November 2010 182

composite) OperatingPressureContact: Contact is M:N with OperatingPressure InspectionRangeContact: Contact is M:N with InspectionRange SiteContact: Contact is M:N with Site SubSystemContact: Contact is M:N with SubSystem ContactCISReading: Contact is 1:M with CISReading ContactMeterReading: Contact is 1:M with MeterReading CompanyContact: Contact is M:N with Company

SubTypes: -- The Contact object class contains the contact information for communicating with any person who has contact with or works for a pipeline company and its contractors. Examples of contacts include right-of-way property owners, structure owners, cathodic protection inspectors, emergency contacts, contractors, and company employees (managers, field crews, GIS operators, etc.). The Contact object class has many-to-many relationships with the Address, Company and SubSystem object classes and with the InspectionRange, LineCrossing, OperatingPressure, RightOfWay, Site and StructureOrIdSite feature classes. These relationships model the person conducting a reading at a facility feature, inspection, or pressure test. The relationships between Contact, LineCrossing, RightOfWay, and StructureOrIDSite reflect ownership or primary contact information. The Contact object class has one-to-many relationships with CISReading and MeterReading. 13.4.5 DocumentPoint Class Name: DocumentPoint Feature Class Geometry:


APDM Inheritance:



DPName (String, 45) – A name, alias, or other identifier for the document point.


DocumentPointExternalDoc: DocumentPoint is M:N with ExternalDocument

SubTypes: -- The DocumentPoint feature class contains points that are used to link to one or more external documents stored on a file server to one or more features in the geodatabase.



DocumentPoint features can be used to annotate (with supporting documents) features that are not explicitly defined in the geodatabase. A document point might be used in a site area polygon representing the boundary of a meter station or a town border station. The site area can have hyperlinked document references in ArcMap; the DocumentPoint can refer to documents pertaining to specific points within the site area polygon. The relationship between DocumentPoint and ExternalDocument object class models that many external document objects can be displayed by one or more document points. 13.4.6 GeoMetaData Class Name: GeoMetaData Feature Class Geometry:


APDM Inheritance:



DateCollected (Date) – The date the original or previous point location was recorded.

ExternalDocumentEventID (GUID) – Foreign key relationship to the associated ExternalDocument.

ProjectionID (String, 5) – The 5 digit numeric ESRI projection identifier in which the original coordinates were collected.

OriginalX (Double, 15,2) – The original x location of the point. OriginalY (Double, 15,2) – The original y location of the point. OriginalZ (Double, 15,2) – The original z location of the point. PositionSource (String, 50) clPositionSource– The origin or method

from which the original point location was derived. Relationships: (cardinality, optionality, attributes, composite)

ExternalDocumentGeoMetaData: GeoMetaData is M:1 with ExternalDocument

FieldNoteGeoMetaData: GeoMetaData is M:N with FieldNote ValveGeoMetaData: GeoMetaData is M:N with Valve ControlPointGeoMetaData: GeoMetaData is M:N with

ControlPoint SubTypes: -- The GeoMetaData object class describes the geographic provenance of point features in the model (e.g. ControlPoint, FieldNote) whose geographic coordinates are absolute and known. The GeoMetaData object class allows the database to store highly accurate coordinate information derived from the field for points whose current position has been degraded to suit a projection/precision limitation or has been moved to conflate the current feature to an existing background or control layer (e.g., land base or orthophotography). The GeoMetaData object class is used to maintain a historic tie to the original geographic location of these features in the event that this information is required for more accurate


November 2010 184

or detailed analysis. The GeoMetaData object class has many-to-many relationships to the ControlPoint, Valve, and FieldNote feature classes. These relationships model the need to store original data collected in the event that a feature is later joined to another position. A many-to-one relationship is also created with ExternalDocument to record the provenance of the original location information. 13.4.7 InstrumentParameter Class Name: InstrumentParameter Feature Class Geometry:


APDM Inheritance:

ESRI Object APDMObject


InstrumentEventID (GUID) – Foreign key to the parent Instrument feature.

ParameterType (String, 50) instrUnknownParameter – The parameter type; dependent on the SubTypeCD Domain assigned is the instr<SubtypeName>Parameter domain.

ParameterValue (String, 80) – The value of the parameter (number values are stored as string).


InstrumentParameter: InstrumentParameter is M:1 with Instrument

SubTypes: -1 – Unknown (Verified) 0 – Unknown 1 – Flow Control Valve 2 – Flow Computer 3 – Gas Chromatograph 4 – Gas Sampler 5 – Level Controller 6 – Level Indicator 7 – Liquid Sampler 8 – Pressure Controller 9 – Pressure Gauge 10 – Pressure Recorder 11 – Pressure Switch 12– Pressure Transducer 13 – Pressure Transmitter 14 – Solar Panel 15 –Temperature Switch 16 – Valve Position Indicator 17 – Valve Positioner



18 – Corrosion Coupon 19 – ER Probe

A single instrument feature may have multiple InstrumentParameter records associated with it. The valid parameter types are dependent on the instrument type. For this reason InstrumentParameter is subtyped identically to Instrument; SubTypeCD for InstrumentParameter records must match that of the parent Instrument record. InstrumentParameter maintains a many-to-one composite relationship with Instrument; the longevity of InstrumentParameter records is controlled by the parent Instrument record. 13.4.8 RemovedLine Class Name: RemovedLine Feature Class Geometry:

Implemented as a Polyline feature class.

APDM Inheritance:



Attributes (String, 4000) – The concatenated name/value pairs of the removed features attributes

BeginStationSeriesEventID (GUID) – Foreign key relationship with BeginStationSeries attribute of the parent StationSeries.

BeginStation (Double, 15, 2) – The known begin station value (measure) of the removed line along its associated station series.

ClassEventID(GUID) – Foreign key relationship to the original feature class for the removed feature.

EndStationSeriesEventID (GUID) – Foreign key relationship with EndStationSeries attribute of the parent StationSeries.

EndStation (Double, 15, 2) – The known end station value (measure) of the removed line along its associated station series.

ProjectionID (String, 5) – The 5 digit numeric ESRI projection identifier that the original coordinates were collected in

RemovedDate (Date) – The data the original feature was deleted, removed, or abandoned.


RemovedLineAudit: RemovedLine is 1:M with RemovedLineAudit ClassMetaDataRemovedLine: RemovedLine is M:1 with

ClassMetaData

SubTypes: -- The RemovedLine feature class is a container for polyline features that belong to other feature classes in which features have been deleted, removed from the ground, or


November 2010 186

abandoned in place. Removed lines capture the stationing information that was last used to locate the feature by linear referencing. The attribute names and values are appended into a single string separated by colons and semicolons respectively. These name/value pairs are stored in the Attributes field. The projection information of the original feature's coordinates is also stored for the feature. 13.4.8 RemovedPoint Class Name: RemovedPoint Feature Class Geometry:


APDM Inheritance:



Attributes (String, 4000) – The concatenated name/value pairs of the removed features attributes.

ClassEventID (GUID) – Foreign key relationship to the original feature class for the removed feature.

ProjectionID (String, 5) – The 5 digit numeric ESRI projection identifier that the original coordinates were collected in

RemovedDate (Date) – The date the original feature was deleted, removed, or abandoned.

StationSeriesEventID (GUID) – Foreign key relationship with StationSeries the RemovedPoint was a part of.

Station (Double, 15, 2) – The known station value (measure) of the removed point along its associated station series.


RemovedPointAudit: RemovedPoint is 1:M with RemovedPointAudit

ClassMetaDataRemovedPoint: RemovedPoint is M:1 with ClassMetaData

SubTypes: -- The RemovedPoint feature class is a container for point features that belong to other feature classes in which features have been deleted, removed from the ground, or abandoned in place. Removed points capture the stationing information that was last used to locate the feature by linear referencing. The attribute names and values are appended into a single string separated by colons and semicolons respectively. These name/value pairs are stored in the Attributes field. The projection information of the original feature's coordinates is also stored for feature. 13.5 Integrity Classes The example integrity classes are designed primarily to support Class and HCA analysis for gas transmission systems, and HCA analysis for liquids transmission systems. Although HCA analysis is performed on both gas and liquids systems, the methods used



for gas and liquids HCA analysis are very different, requiring different class structures within the APDM. The example APDM integrity classes are depicted in the following figure:


November 2010 188

Regulatory Segments – HCA and DOT

HCASegmentA segment derived from some form of HCA calculation or assignment.

ActivityEventID (GUID) – The EventID of the Activity Object representing the calculation or determination of HCA.

BIHOStructureCount (Long Int) - The number of structures (buildings intended for human occupancy) that created the individual HCA segment (optional).

CalculatedLength (Double) - Calcuated 2D/3D length of class segment in feet.DateCalculated (Date) - Date the HCA analysis was performed.HCARangeEventID (GUID) – The foreign key to the HCARange online polyline feature class indicating

the rolled up HCA parent segment.MAOP (Double) - The MAOP of the original operating pressure or dynamically segmented feature used

to calculate the PIR.OutsideDiameter <Domain> (fcOutsideDiameter) - The outside diameter of the original pipe or

dynamically segmented feature used to calculate the PIR.PIR (Double) – The potential impact radius of the original segment.PIRT (Double) - A tolerance factor to account for variation in spatial data accuracy of the features used

to determine if a segment is HCA.Provenance <Domain> (opHCAProvenance) – The method used to assign/calculate the HCAClass

segment.TotalPIR (double) - The total PIR (PIR+PIRT) for a HCAClass segment.StructureOrIDSiteEventID (GUID) – The EventID of the object class containing the Identified Sites that

were the cause of a created HCA segment (optional).

HCARangeThe aggregate segment derived from a rolled up set of

HCACLass segments.

AssessmentCalculated (Date) - Date the HCA analysis was performed.

RangeName (String) – A name or code assigned to the HCARange that is used in further analysis such as Risk Assessment or mapping.

RiskRanking (Double) – An overall Risk Ranking assigned to the HCARange.

DOTClassSegments indicating the calculated or assigned Department of

Transportation Office of Pipeline Safety class designations.

ActivityEventID (GUID) – The EventID of the Activity Object representing the calculation or determination of DOT Class.

CalculatedLength (Double) – The 2D/3D length of the class segment (in feet).

ClassType <Domain> (opDOTClassType) – The class designation assigned to the class.

ClassSource <Domain> (opDOTClassSource) – The methodology used to derive/assign the class type to the segment.

ClusterBufferEventID (GUID) – Foreign key of the cluster buffer that was used to create DOT Class III or IV segments

CorridorWidth (Double) – The width of the corridor surrounding the class (?).

CorridorTolerance (Double) – The tolerance used to extend the corridor buffer.

DateCalculated (Date) – The date the class value was determined and assigned to the class segment.

IDSiteBufferRadius (Double) – The buffer distance surrounding the IDSite causing Class II or IV.

StructureOrIDSiteEventID (GUID) – The EventID of the object class containing the Structures that were the cause of a created DOT segment (optional).

OnlinePolyline

HCASegmentAudit

HCASegmentEventID (fk)

ActivityEventID (fk)BIHOStructureCountCalculatedLengthDateCalculatedHCARangeEventID (fk)MAOPOutsideDiameterPIRFactorPIRPIRTProvenance <d>SturctureOrSiteEventID (fk)

HCASegment

ActivityEventID (fk)AssessmentDateRangeNameRiskRanking

HCARange

Activity

HCARangeAudit

HCARangeEventID (fk)

ActivityEventID(fk)CalculatedLengthClassType <d>ClassSource <d>ClusterBufferEventID (fk)CorridorWidthCorridorToleranceDateCalculatedIDSiteBufferRadiusStructureOrIDSiteEventID (fk)

DOTClass

DOTClassAudit

DOTClassEventID (fk)

RiskAnalysis

Many Structures cancreate an HCASegment

Many Structures can

create an DOTSegment

A single structure actingas an Identified Site cancreate an HCA Segment

OnlinePolyline

CouldAffectSegment

CASegmentsAudit

HCARangeEventID (fk)

HCA LiquidsHCA and DOTClass for Gas

A single structure acting as an

Identified Site cancreate an DOTClass

Segment

AreaType <d>ClassArea <d>

HighConsequenceArea

OfflineFeature

StructureOrIDSite

StructureOrIDSite

CouldAffectSegmentsThe segments affected as the results of a liquid spill.

HighConsequenceAreaA polygonal area the if affected by a liquids spill will result in

high loss of life, environmental and/or economic consequence.

AreaType <Domain> (enHCAEncroachmentType) - The classification of the type of area.

ClassArea <Domain> (enHCAClass) – The assigned class designation.

APDM 4.0 has revised the schema for High Consequence Area and DOT Class analysis for both gas and liquid transportation systems. The examples provided for gas are more detailed than those for liquids. The biggest change from APDM 3.0-4.0 is the specification of Structures and IDSites in the same object class and the relationships from this class to both HCASegment and DOTClass feature classes. A 1-M and M-N relationship exist to these classes from StructureAndIDSite showing how a single IDSite or multiple structures cause HCASegments. The inclusion of the HCARange feature class allows HCASegments to be aggregated or ‘rolling up’ to form HCARange segments which solely indicating areas of high consequence along the pipelne should a rupture occur.

Activity

Figure 31



Detailed descriptions for each of the integrity classes are found below. 13.5.1 ClusterBuffer Class Name: CouldAffectSegment Feature Class Geometry:


APDM Inheritance:



ActivityEventID (GUID) -- Foreign key to Activity object. BufferRadius (Double, 15,2) -- Radius of buffer used in clustered

calculations of DOT Class BufferTolerance (Double, 15,2) -- The + or - tolerance used in

determining the cluster radius.


ClusterBufferAudit: ClusterBuffer is 1:M with ClusterBufferAudit

SubTypes: -- The ClusterBuffer represents the extent of a cluster area used in determining the DOT Class using clustering methods. 13.5.2 CouldAffectSegment Class Name: CouldAffectSegment Feature Class Geometry:


APDM Inheritance:




CouldAffectSegmentAudit: CouldAffectSegment is 1:M with CouldAffectSegmentAudit

SubTypes: --


November 2010 190

The CouldAffectSegment feature class is intended to store the results of liquids HCA analysis. CouldAffectSegment features represent pipeline segments that potentially ‘could affect’ a high consequence area, as defined by the National Pipeline Mapping System (NPMS). Because of the wide variation in practice for calculating could affect segments, the CouldAffectSegment feature class is included as a ‘placeholder’ class without defined attribution. 13.5.3 DOTClass Class Name: DOTClass Feature Class Geometry:


APDM Inheritance:



ActivityEventID (GUID) -- Foreign key to Activity object. CalculatedLength (Double, 15,2) – The 2D/3D length of the class

segment (in feet). ClassType (String, 50) opDOTClassType – The class designation

(Class I, Class II, Class III, Class IV). ClassSource (String, 50) opDOTClassSource – The methodology

used to derive/assign the class type to the class segment. CorridorWidth (Double, 15,2) – The width of the corridor

surrounding the class. CorridorTolerance (Double, 15,2) -- The + or - tolerance used in

determining the corridor width. IDSiteBufferRadius (Double, 15,2) -- The calculated radius of a site

used in determining if the site is within applicable distance for DOT classification.

DateCalculated (Date) – The date the class value was determined and assigned to the class segment.

StructureOrIDSiteEventID (GUID) – Foreign key relationship to a StructureOrIDSite object.

ClusterBufferEventID (GUID) -- Foreign key relationship to a ClusterBuffer object.


StructuresDOTClassMN: StructureOrIDSite is M:N with DOTClass

ClusterBufferDOTClass: ClusterBuffer is 1:M with DOTClass IDSiteDOTClass1M: StructureOrIDSite is 1:M with DOTClass DOTClassAudit: DOTClass is 1:M with DOTClassAudit

SubTypes: -- The DOTClass feature class contains the segments indicating the calculated or assigned Department of Transportation Office of Pipeline Safety class designations.



The many to many relationships from StructureOrIDSite to HCASegment and DOTClass are used to tabulate the structures that via density create an HCA or DOT class. The one to many relationships from StructureOrIDSite to HCASegment and DOTClass are used to identify a specific identified site that creates an HCA and/or DOT class assignation. 13.5.4 DOTClassCorridor Class Name: DOTClassCorridor Feature Class Geometry:

Implemented as a M-Aware Polygon feature class.

APDM Inheritance:



ActivityEventID (GUID) -- Foreign key to Activity object. CorridorRadius (Double, 15,2) -- Radius of corridor used in

calculations of DOT Class, usually 660 ft. CorridorTolerance (Double, 15,2) -- The + or - tolerance used in

determining the corridor radius. DOTCorridorType (String, 50) opDOTClassCorridorType --

Indicates if a corridor used in DOT Class determination is continuous, or clustered.


DOTClassCorridorAudit: DOTClassCorridor is 1:M with DOTClassCorridorAudit

SubTypes: -- The DOTClassCorridor is a buffer applied to either side of a centerline based on the corridor radius that is used in determining teh DOT Class. 13.5.5 DOTClassSegment Class Name: DOTClassSegment Feature Class Geometry:


APDM Inheritance:



ActivityEventID (GUID) -- Foreign key to Activity object. BIHOStructureCount (Long Integer, 9) – The number of structures

(intended for human occupancy) that created the individual HCA segment (optional).

ClassLength (Double, 15,2) – The 2D/3D length of the class segment (in feet).


November 2010 192

ClassSource (String, 50) opDOTClassSource -- The methodology used to derive/assign the class type to the class segment.

ClusterBufferEventID (GUID) -- Foreign key to ClusterBuffer object.

ClusteredClassType (String, 50) opDOTClassType -- The class designation (Class I, Class II, Class III, Class IV) or the clustered segment.

ClusterDowngrade (String, 50) gnYesNo -- Indicator if the clustering class is lower than the non-clustered DOT Class for the segment.

CorridorWidth (Double, 15,2) -- The width of the corridor surrounding the class.

CorridorTolerance (Double, 15,2) -- The + or - tolerance used in determining the corridor width.

DateCalculated (Date) – The date the DOT Class analysis was performed.

DOTClassEventID (GUID) -- Foreign key to DOTClass object. IdentifiedSite (String, 50) gnYesNo -- Indicator if the cluster

contains an Identified Site IDSiteBufferRadius (Double, 15,2) -- Buffer applied to Site used in

determining DOT Class. MultiUnitResidential (String, 50) gnYesNo -- Indicator if structure

has more than a single family unit. (ex: apartment, condo) Provenance (String, 50) opHCAProvenance) – the method used to

assign/calculate the HCASegment. StructureOrIDSiteEventID (GUID) – Foreign key relationship to

the StructureOrIDSite object that is classified as an Identified Site and created the HCA segment (optional).

UnclusteredClassType (String, 50) opDOTClassType -- The class designation (Class I, Class II, Class III, Class IV) or the un-clustered segment.


StructuresOrIDSiteDOTClassSgtMN: StructureOrIDSite is M:N with DOTClassSegment

IDSiteDOTClassSegment1M: StructureOrIDSite is 1:M with DOTClassSegment

DOTClassSegmentDOTClass: DOTClassSegment is M:1 with DOTClass.

DOTClassSegmentAudit: DOTClassSegment is 1:M with DOTClassSegmentAudit

ClusterBufferDOTClassSgmnt: ClusterBuffer is 1:M with DOTClassSegment

SubTypes: --



The DOTClassSegment feature class contains the segments derived from some form of DOTClass calculaton or assignment. The many to one relationship to DOTClass denotes that DOTClassSegment features are rolled-up to form a DOTClass feature. 13.5.6 HCACorridor Class Name: HCACorridor Feature Class Geometry:

Implemented as a M-Aware Polygon feature class.

APDM Inheritance:



ActivityEventID (GUID) -- Foreign key to Activity object. PIR (Double, 15,2) – the potential impact radius of the original

segment. PIRFactor(Double, 15,2) -- The natural gas energy factor used in

calculating the PIR. (ex: 0.69, 0.73) PIRT (Double 15,2) – A tolerance factor to account for variation in

spatial data accuracy of the features used to determine if a segment is HCA.


HCACorridorAudit: HCACorridor is 1:M with HCACorridorAudit

SubTypes: -- The HCACorridor is the calculated buffer either side of a centerline based on the PIR value that is used in determining the extents of a HighConsequenceArea. 13.5.7 HCARange Class Name: HCARange Feature Class Geometry:


APDM Inheritance:



ActivityEventID (GUID) -- Foreign key to Activity object. AssessmentDate (Date) – The date the HCA analysis ws performed. RangeName (String, 255) – The name or code assigned to the

HCARange that is used in further analysis such as Risk Assessment or mapping.

RiskRanking (Double, 15,2) – An overall Risk Ranking assigned to the HCARange.


November 2010 194


HCARangeSegment: HCARange is 1:M with HCASegment HCARangeAudit: HCARange is 1:M with HCARangeAudit HCARangeRiskAnalysis: HCARange is 1:M with RiskAnalysis

SubTypes: -- The HCARange feature class contains the aggregate segment derived from a rolled up set of HCAClass segments. The one to many relationship to HCASegment denotes that HCASegment features are rolled-up to form an HCARange feature. The one to many relationshop with RiskAnalysis denotes that more than one HCARange can be associated with a RiskAnalysis feature. 13.5.8 HCASegment Class Name: HCASegment Feature Class Geometry:


APDM Inheritance:



ActivityEventID (GUID) -- Foreign key to Activity object. CalculatedLength (Double, 15,2) – The 2D/3D length of the class

segment (in feet). BIHOStructureCount (Long Integer, 9) – The number of structures

(intended for human occupancy) that created the individual HCA segment (optional).

HCAMethod (Long Integer, 9) -- Method used in calculating HCA as described in 49CFR192. (ex: 1 or 2)

HCARangeEventID (GUID) – Foreign key to the HCARange online polyline feature class indicating the rolled up HCA parent segment.

MAOP (Double, 15,2) – The MAOP of the original pipe segment used to calculate the PIR.

OutsideDiameter (String, 50) fcDiameter – The outside diameter of the original segment used to calculate the PIR.

PIR (Double, 15,2) – the potential impact radius of the original segment.

PIRFactor(Double, 15,2) -- The natural gas energy factor used in calculating the PIR. (ex: 0.69, 0.73)

PIRT (Double 15,2) – A tolerance factor to account for variation in spatial data accuracy of the features used to determine if a segment is HCA.

Provenance (String, 50) opHCAProvenance) – the method used to



assign/calculate the HCASegment. DateCalculated (Date) – The date the HCA analysis was performed. StructureOrIDSiteEventID (GUID) – Foreign key relationship to

the StructureOrIDSite object that is classified as an Identified Site and created the HCA segment (optional).


StructuresHCASegmentMN: StructureOrIDSite is M:N with HCASegment

IDSiteHCASegment1M: StructureOrIDSite is 1:M with HCASegment

HCARangeSegment: HCASegment is M:1 with HCARange HCASegmentAudit: HCASegment is 1:M with HCASegmentAudit

SubTypes: -- The HCASegment feature class contains the segments derived from some form of HCA calculaton or assignment. The many to one relationship to HCARange denotes that HCASegment features are rolled-up to form an HCARange feature. The many to many relationships from StructureOrIDSite to HCASegment and DOTClass are used to tabulate the structures that via density create an HCA or DOT class. The one to many relationships from StructureOrIDSite to HCASegment and DOTClass are used to identify a specific identified site that creates an HCA and/or DOT class assignation. 13.5.9 HighConsequenceArea Class Name: HighConsequenceArea Feature Class Geometry:


APDM Inheritance:



AreaType (String, 50) enHCAEncroachmentType – The type of area (e.g., navigable waterway, populated area).

ClassArea (String, 50) enHCAClass – The automatic rating assigned to the reach of pipeline that this area affects.


--

SubTypes: -- The HighConsequenceArea feature class denotes the boundary of high consequence areas that encroach upon the DOT Class Corridor of the pipeline center and effectively drive up


November 2010 196

the HCA class rating of segments of the pipeline. High consequence areas are navigable waterways, ecological reserves, drinking water recharge zones, and densely populated areas. 13.5.10 RiskAnalysis Class Name: RiskAnalysis Feature Class Geometry:


APDM Inheritance:



ConsequenceEconomic (Double, 15,2) – An assigned/calculated economic consequence rating.

ConsequenceEnvironmental (Double, 15,2) – An assigned/calculated loss-of-environmental consequence rating.

ConsequenceLife (Double, 15,2) – An assigned/calculated loss-of-life consequence rating.

ConsequenceProperty (Double, 15,2) – An assigned/calculated loss-of-property consequence rating.

ConsequenceThroughput (Double, 15,2) – An assigned/calculated loss-of-throughput consequence.

POFConstruction (Double, 15,2) – Probability of failure due to construction defects.

POFIncorrectOperation (Double, 15,2) – Probability of failure due to incorrect operations.

POFInternalCorrosion (Double, 15,2) – Probability of failure due to internal corrosion.

POFEquipmentFailure (Double, 15,2) – Probability of failure due to equipment failure.

POFExternalCorrosion (Double, 15,2) – Probability of failure due to external corrosion.

POFManufaturing (Double, 15,2) – Probability of failure due to manufacturing defects.

POFMaterials (Double, 15,2) – Probability of failure due to material defects.

POFOutsideForce (Double, 15,2) – Probability of failure due to an outside force (earth movement).

POFSCC (Double, 15,2) – Probability of failure due to stress, corrosion and cracking.

POFThirdParty (Double, 15,2) – Probability of failure due to third party interference.

POFWeather (Double, 15,2) – Probability of failure due to weather (lightning strikes).



TotalConsequence (Double, 15,2) – Total "loss-of" consequence rating.

TotalPOF (Double, 15,2) – Total probability of failure rating. TotalRisk (Double, 15,2) – Total risk rating for the section of

pipeline. HCARangeEventID (GUID) – The foreign key relationship to the

HCARange feature class. Relationships: (cardinality, optionality, attributes, composite)

RiskAnalysisAudit: RiskAnalysis is 1:M with RiskAnalysisAudit HCARangeRiskAnalysis: RiskAnalysis is M:1 with HCARange

SubTypes: -- The RiskAnalysis feature class stores polylines representing the results of a risk analysis along a reach of the pipeline. Potential risk (probability of failure, rupture, or unplanned release) along the pipeline is calculated based on the structural ability of the pipeline to carry product under pressure. Parameters used for risk analysis might include pipe segment wall thickness, anomaly frequency, soil and other environmental conditions, and coating condition. Risk analysis also entails some quantification of the consequences of a pipeline rupture on property, the environment, and human life. The RiskAnalysis feature class was designed to be customizable and includes suggested attributes. 13.6 Inspection Classes 13.6.1 Anomaly Class Name: Anomaly Feature Class Geometry:


APDM Inheritance:



AnomalyClusterEventID (GUID) – Foreign key relationship with the associated AnomalyCluster.

AnomalyType (String, 50) inAnomalyType– indicates the type of anomaly found – corrosion, dent, gouge, crack etc.

BPRCalculated (Double, 15,2) gnPercentRange – Calculated burst pressure ratio.

BPRPig (Double, 15,2) gnPercentRange – Burst pressure ratio recorded based on values retrieved by an inline PIG run.

BPRVariance (Double, 15,2) gnPercentRange – Variance between calculated burst pressure ratios and burst pressure ratios recorded by an inline PIG run.


November 2010 198

Depth (Double, 15,3) – Depth to the anomaly from ground surface. (Depth of ground cover is used in Risk calculations.)

Length (Double, 15,3) – The length of the anomaly MaximumDiameter (Double, 15,2) – The maximum diameter of the

pipe segment at the anomaly. MinimumDiameter (Double, 15,2) – The minimum diameter of the

pipe segment at the anomaly. Orientation (String, 5) – The location of the anomaly on the pipe

(zero degrees is up). Ovality (Double, 15,2) gnPercentRange – Measure of the ovality of

the pipe segment at the anomaly. RecommendedRemediation (String, 50) inRemediation – Suggested

method of remediation (e.g., repair, replace). RPRCalculated (Double, 15,2) gnPercentRange – Calculated

rupture pressure ratio. RPRPig (Double, 15,2) gnPercentRange – Rupture pressure ratio

recorded by an inline PIG run. RPRVariance (Double, 15,2) gnPercentRange – Variance between

calculated rupture pressure ratios and rupture pressure ratios recorded by an inline PIG run.

Width (Double, 15,3) – The width of the anomaly. Relationships: (cardinality, optionality, attributes, composite)

AnomalyCluster: Anomaly is M:1 with AnomalyCluster InspectionRangeAnomaly: Anomaly is M:N with InspectionRange AnomalyAudit: Anomaly is 1:M with AnomalyAudit

SubTypes: 1 – External Corrosion 2 – Internal Corrosion 3 – Dent 4 – Gouge Note: These subtypes are considered to be examples of a range of possible anomaly types.

The Anomaly feature class is used to describe anomalies in the pipeline system as detected from inline inspection runs of a pigging device. Typical anomalies include corrosion, geometric distortions, and/or material defects such as gouges or dents. The relationship between Anomaly and AnomalyCluster models that an anomaly point can be a member of a cluster of like anomalies. Typically, anomalies are classified according to the kind of inline PIG inspection conducted on the pipe segments of a pipeline system. The relationship between Anomaly and InspectionRange models the fact that an anomaly location can be determined by many different inspections.



13.6.2 AnomalyCluster Class Name: AnomalyCluster Feature Class Geometry:


APDM Inheritance:



AnomalyType (String, 50) inAnomalyType – The type of anomaly cluster (e.g., dents, gouges, corrosion).

AveBPRCalculated (Double, 15,2) gnPercentRange – Calculated average anomaly burst pressure ratio.

AveBPRPig (Double, 15,2) ) gnPercentRange – Calculated average recorded anomaly burst pressure ratio.

AveBPRVariance (Double, 15,2) ) gnPercentRange – Calculated average variance between calculated and recorded anomaly burst pressure ratios.

AveDepth (Double, 15,3) – Calculated average anomaly depth. AveLength (Double, 15,3) – Calculated average anomaly length. AveMaximumDiameter (Double, 15,2) – Calculated average

anomaly maximum diameter. AveMinimumDiameter (Double, 15,2) – Calculated average

anomaly minimum diameter. AveOrientation (String, 5) – Calculated average anomaly

orientation. AveOvality (Double, 15,2)gnPercentRange – Calculated average

anomaly ovality. AveRPRCalculated (Double, 15,2) gnPercentRange – Calculated

average of the calculated anomaly rupture pressure ratio. AveRPRPig (Double, 15,2) gnPercentRange – Calculated average

recorded anomaly rupture pressure ratio. AveRPRVariance (Double, 15,2) gnPercentRange – Calculated

average variance between calculated and recorded anomaly burst pressure ratios.

AveWidth (Double, 15,3) – Calculated average anomaly width. Relationships: (cardinality, optionality, attributes, composite)

AnomalyCluster: AnomalyCluster is 1:M with Anomaly AnomalyClusterAudit: AnomalyCluster is 1:M with

AnomalyClusterAudit

SubTypes: -- The AnomalyCluster feature class contains mean (average) values for a set of anomaly point features.


November 2010 200

One feature in the AnomalyCluster feature class represents a set of anomalies stored as a multipoint shape. The purpose behind the AnomalyCluster feature class is to allow analysis of clustered anomalies (of similar types) discovered during an inline PIG run. 13.6.3 InspectionRange Class Name: InspectionRange Feature Class Geometry:


APDM Inheritance:



InspectionDate (Date) – Date the inspection occurred. InspectionType (String, 50) inInspectionRangeType – Type of

inspection performed – close interval survey, inline pig run, casing survey, aerial survey etc..


InspectionRangeActivity: InspectionRange is M:N with Activity InspectionRangeAnomaly: InspectionRange is M:N with Anomaly InspectionRangeContact: InspectionRange is M:N with Contact InspectionRangeAudit: InspectionRange is 1.M with

InspectionRangeAudit

SubTypes: The InspectionRange feature class represents the length or range of an inline PIG run, the linear extents of an Activity or another type of inspection along a pipeline. Currently there is no published standard format for most of this data. Most of the data returned from an inline PIG run is typically stored in an external data source and is not always easily integrated as part of the GIS. The InspectionRange feature class provides a mechanism to relate this information to a geometric feature in the geodatabase. The relationship between InspectionRange and Anomaly and the relationship between InpectionRange and Contact model the occurrence of many discovered anomalies for an inline run and list a contact person for the contractor who conducted the inline run. Inspection Range also has a many-to-many relationship with Activity (many linear ranges represent the spatial extent of one or more recurring activities). 13.6.4 Leak Class Name: Leak Feature Class Geometry:


APDM ESRI Object Feature Feature Archive OnlineFeature



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

DateRepaired (Date) – The date the leak was repaired. DateReported (Date) – The date the leak was discovered/reported. Depth (Double, 15, 3) – The depth of the leak below the surface of

the ground. LeakCause (String, 50) inLeakCause – The cause of the leak

(e.g., outside force, corrosion). LeakOrigin (String, 50) inLeakOrigin – The origin of the leak on

the pipe (e.g., girth weld, tap). LeakStatus (String, 50) inLeakStatus – The status of the leak

(e.g., no leak, repaired). MethodDetected (String, 50) inLeakDetectionMethod – How the

leak was detected (e.g., leak survey, third party). RepairType (String, 50) inLeakRepairType – Type of repair

(permanent or temporary). Relationships: (cardinality, optionality, attributes, composite)

LeakAudit: Leak is 1:M with LeakAudit

SubTypes: -- The Leak feature class stores information about leaks, ruptures, and unexpected deliveries or releases that are discovered along the pipeline system and repaired. 13.7 Encroachments Classes The Encroachment classes encompass two broad categories of features: 1) structures and identified sites, and 2) line crossings. Structures and identified sites are of particular importance Class and HCA analysis for gas transmission pipelines. The APDM is designed to accommodate the storage of structure and identified site information as depicted in the following diagram:


November 2010 202

Figure 32 The detailed architecture of the structure and identified site example classes are shown below:



Structure and Identified Site Data Model

StructureOrIDSite – Object class representing a structure or identified site for which regulatory information is required.IDSiteArea – A polygon indicating the boundary area of an identified site.NearestPointToLine – A point feature representing the nearest point to a line loop from a structure outline or the point representing an Identified Site.StructureOutline – An polygon representing the outline of a structure building (typically captured from aerial photography)StructureLocation – A single online stationed point representing the location of the StructureOrIDSite or the NearestPointToLine on the pipeline centerline.

The following four scenarios are documented in the previous diagram and are described in detail here:

Structure 1 – Has one StructureOrIDSite object record with four related StructureOutlines. One StructureOutline is considered regulatory-significant. Two NearestToPoint features are created by placing the ‘Near’ points on the outline to each Lineloop that has one or more Primary Reference Mode (PRM) station series features. The lines drawn from the points are used to create three StructureLocations.

Structure 2 – Has one StructureOrIDSite object record with one related StructureOutline. Since only one Lineloop containing PRM station series features is within proximity to the structure outline only a single NearestToPoint and StructureLocation point features are created.

Structure 3 – One StructureOrIDSite object record with one NearestToPoint point representing the structure location. The NearestToPoint was not created from a StructureOutline boundary but was placed at a specific point. A resulting StructureLocation is calculated from the intersection fo the line traced from the NearestToPoint point to the lineloop. Either the NearestToPoint or the StructureLocation can be the first feature placed and from which the location of the other feature is derived. If the NearestToPoint is located from the StructureLocation then the StationLocated attribute in the StructureLocation will be set to true indicating that the stationed position was the provenance for the location of the structure.

Structure 4 – Has one StructureOrIDSite object record located by a single StructureLocation without a offline feature.

OfflineFeature

StructureOrIDSiteEventID (fk)

StructureOutline

(Polygon)

OfflineFeature OnlinePointForOfflineFeature

StructureOrIDSiteEventID (fk)NearestPointToLineEventID (fk)

StructureLocation

Nearest point to line and identified

site points

StructureAuditStructureOrIDSiteEventID (fk)

NameIdentifiedSite <d>IdentifiedSiteType <d>NumberOfStoriesNumberOfUnitsBIHO <d>DaysPerWeekWeeksPerYearOccupantCountImparedMobility <d>StructureStatus <d>StructureOrIDSiteType <d>DateAddedSiteDescription

StructureOrIDSite

NonFacilityObject OfflinePoint

StructureOrIDSiteEventID (fk)StructureOutlineEventID (fk)

NearestPointToLine

Address

Contact

Offline pointattached to outline

edge or cornerOnline location for

NPTL

Stationed locationused to locate

structureor ID Site

IDSiteEventID (fk)

IDSiteArea

One structure may be represented by

the outline of one or more IDSiteAreas

In this case the value for the attriibute

RegulatorySignificant = Yes

enStructureOrIDSiteTypeUnknown-VerifiedUnknown DefaultApartment (Single Story)Apartment (Multi-Story)ArenaAssembly AreaAssisted LivingBarnBarracksBeachBusiness (Single)Business (Multi-Story)CampgroundCemeteryChurchDaycare FacilityFire StationGarageGolf CourseHospitalHotel/Motel (Single-Story)Hotel/Motel (Multi-Story)IndustrialManufacturingNursing HomeOutbuildingOutdoor TheatreParkParking LotPlaygroundPrisonRecreational AreaRecreational FacilityReligious FacilityResidence (Condominium)Residence (Duplex)Residence (Single Family)Residence (Trailer)Residence (Multi-Unit Townhouse)Retirement FacilitySchoolShedStadiumStructure BIHOTheme ParkWarehouse(Coded Value Domain – String)

Structure density can create an HCASegment

Many Structures can create an DOTSegment

A single structure acting as an Identified Site can create an HCA Segment

A single structure acting as an Identified Site can create an DOTClass Segment

HCASegment

HCASegment

DOTClass

DOTClassStructure and Identified Sites are merged into a single object class. Feature classes containing geometric representations of structure locations, outlines, nearest point to lines, identified site points and polygons are related to the StructureOrIDSite object class. Many possible scenarios exist for modeling structures and identified sites for regulatory analysis and reporting purposes. NOTE: The subtypes for the original structure feature class have been removed and a single domain denoting structure and identified site has been created (Domain listing on right )

Figure 33


November 2010 204

Detailed descriptions of the structure and identified site classes, and the line crossing classes, follow. 13.7.1 StructureOrIDSite Class Name: StructureOrIDSite Feature Class Geometry:


APDM Inheritance:



BIHO (String, 50) gnYesNo (required APDM domain) – Indicates if the building is intended for human occupancy. The gnYesNo domain is considered a ‘core’ APDM domain and must be implemented verbatim.

DaysPerWeek (Long Integer, 9) enDaysPerWeek – The number of days per week the structure is occupied.

ImpairedMobility (String, 50) gnYesNo (required APDM domain) – Indicates if a structure or area would be difficult to evacuate, e.g. hospital, prison, or nursing home. The gnYesNo domain is considered a ‘core’ APDM domain and must be implemented verbatim.

OccupantCount (Long Integer, 9) – The number of permanent occupants of structure.

Name (String, 255 ) – The name of the structure or area, e.g. Rose Park Golf Course, Metro Hospital.

NumberOfStories (Long Integer, 9) – The number of stories in a structure, e.g. 6 stories (floors) in a single apartment building. (Used for determining the DOTClass.)

NumberOfUnits (Long Integer, 9) – The number of residential units in a structure, e.g. sixteen units (apartments) in a single apartment building.

StructureStatus (String, 50) enStructureStatus – Indicates how new the structure is (existing, new).

StructureOrSiteType (String, 50) enStructureOrIDSiteType – A description of the structure type and primary usage based on the structure subtype.

WeeksPerYear (Long Integer, 9) enWeeksPerYear – The number of weeks per year the structure is occupied.

DateAdded (Date) – The date that the structure was added to the geodatabase records.

SiteDescription (String, 255) -- General text describing structure or Site.

IdentifiedSite (String, 50) gnYesNo -- Indicator if Site is used in HCA determination.



IdentifiedSiteType (String, 50) enIdentifiedSiteType -- Catagorization of structure or site for HCA determination. (ex: Church, School)


StructureOrIDSiteAddress: StructureOrIDSite is M:N with Address StructureOrIDSiteContact: StructureOrIDSite is M:N with Contact StructureOrIDSiteNPTL: StructureOrIDSite is 1:M with

NearestPointToLine (Optional Relationship) StructureOrIDSiteLocation: StructureOrIDSite is 1:M with

StructureLocation (Optional Relationship) StructureOrIDSiteOutline: StructureOrIdSite is 1:M with

StructureOutline (Optional Relationship) StructureOrIDSiteAudit: StructureOrIDSite is 1:M with

StructureAudit StructuresHCASegmentMN: StructureOrIDSite is M:N with

HCASegment IDSiteHCASegment1M: StructureOrIDSite is 1:M with

HCASegment StructuresDOTClassMN: StructureOrIDSite is M:N with

DOTClass IDSiteDOTClass1M: StructureOrIDSite is 1:M with DOTClass StructureOrIDSiteArea: StructureOrIDSite is 1:M with IDSiteArea

SubTypes: -- The StructureOrIDSite object class stores information pertaining to any structure, identified site or identified site area located within 660 feet of either side of the pipeline centerline (class corridor). The Federal Department of Transportation requires that pipeline companies maintain information regarding any occupied structure within the class corridor of the pipeline. Typically structures are defined as objects related to NearestPointToLine features, which are located off the centerline. A NearestPointToLine feature may then be optionally related to a StructureLocation online point containing a referenced position on the centerline. The Address and Contact relationships model occupancy and owner emergency contact information. The relationship between StructureOrIDSite and StructureOutline allows the storage of one or more structure outlines with a structure point allowing for more flexibility in spatial analysis of proximity of the structure with the pipeline centerline. The relationship between StructureOrIDSite and NearestPointToLine indicates that the structure may have one or more point locations. The relationship between StructureNPTL and StructureOutline indicates that the structure can exist as either or both an offline point and/or offline polygon. The many to many relationships from StructureOrIDSite to HCASegment and DOTClass are used to tabulate the structures that via density create an HCA or DOT class. The one


November 2010 206

to many relationships from StructureOrIDSite to HCASegment and DOTClass are used to identify a specific identified site that creates an HCA and/or DOT class assignation. 13.7.2 NearestPointToLine Class Name: NearestPointToLine Feature Class Geometry:


APDM Inheritance:



StructureOrIDSiteEventID (GUID) – Foreign key relate to EventID attribute in the StructureOrIDSite feature class.

StructureOutlineEventID (GUID) – Foreign key relate to EventID attribute in the Structure feature class.


StructureOrIDSiteNPTL: NearestPointToLine is M:1 with StructureOrIDSite (Optional Relationship)

StructureOutlineNPTL: NearestPointToLine is M:1 with StructureOutline (Optional Relationship)

NPTLStructureLocation: NearestPointToLine is 1:M with StructureLocation (Optional Relationship)

SubTypes: -- The NearestPointToLine feature class contains the location of the nearest point on a structure to a line. The relationship between NearestPointToLine and the StructureOrIDSite Object Class or the StructureOutline feature class models that there may be one or more NearestPointToLine features for a StructureOrIDSite or StructureOutline. The relationship between NearestPointToLine and the StructureLocation feature class models that NearestPointToLine may have one or more StructureOnlineLocaton features. The relationship between NearestPointToLine and StructureOutline indicates that the structure can exist as either or both an offline point and/or offline polygon. 13.7.3 IDSiteArea Class Name: IDSiteArea Feature Class Geometry:


APDM Inheritance:


Attributes: (name, type,

StructureOrIDSiteEventID (GUID) – The foreign key relationship to the StrucutureOrIDSite object.



length, precision, scale, domain, description)


StructureOrIDSiteArea: StructureOrIDSite is 1:M with IDSiteArea

SubTypes: -- In some cases, an identified seat may be represented by a polygon, rather than a point. The IDSiteArea feature class is used to store identified sites that are represented as polygons. 13.7.4 StructureLocation Class Name: StructureLocation Feature Class Geometry:


APDM Inheritance:




NearestPointToLineEventID (GUID) – Foreign key relate to the EventID attribute in the NearestPointToLine feature class.


StructureOrIDSiteLocation: StructureLocation is M:1 with StructureOrIDStie (Optional Relationship)

NPTLStructureLocation: StructureLocation is M:1 with NearestPointToLine (Optional Relationship)

SubTypes: -- The StructureLocation feature class contains the online point locations for a NearestPointToLine feature that falls within a certain distance (usually 660 or 1,000 feet) of the centerline. The relationship between StructureLocation and NearestPointToLine models that many online locations reference an offline structure on the centerline. 13.7.5 StructureOutline Class Name: StructureOutline Feature Class Geometry:



November 2010 208

APDM Inheritance:





StructureOutline: StructureOutline is M:1 with Structure (Optional Relationship)

StructureOutlineNPTL: StructureOutline is 1:M with StructureNPTL (Optional Relationship)

SubTypes: -- The StructureOutline feature class contains the polygon outlines of structures. The relationship between StructureOutline and Structure models that many buildings are associated with a single structure object that is referenced by a point on the centerline. 13.7.6 LineCrossing Class Name: LineCrossing Feature Class Geometry:


APDM Inheritance:



Clearance (Double, 15,2) – The distance of the line crossing above or below the pipeline at the point of crossing.

CrossingType (String, 50) enLCGeography – The type of line crossing based on the line crossing subtype (e.g., road, river).

EasementWidth (Double, 15,2) – The total easement width where the LineCrossing intersects the centerline.

Name (String, 90) – The name of the line crossing (e.g., Kansas Northern Railroad).


LineCrossingLocation: LineCrossing is 1:M with LineCrossingLocation features.

LineCrossingEasement: LineCrossing is 1:M with LineCrossingEasement features.

LineCrossingContact: LineCrossing is M:N with Contact LineCrossingCompany: LineCrossing is M:N with Company LineCrossingAudit: LineCrossing is 1:M with LineCrossingAudit

SubTypes: 1 – Geographical (navigable waterways, drainage, hydrology) 2 – Utility (foreign pipelines, electric wires) 3 – Transportation (roads, fences, political boundaries)



The LineCrossing feature represents a set of linear features (roads, rivers, fences, etc.) that intersect the centerline of the pipeline. Every pipeline company must track any of these features for right-of-way purposes, ownership purposes, and DOT/FERC safety regulations. The LineCrossing feature class has no inherent referential position but relies on the LineCrossingLocation (online point) and LineCrossingEasement (online polyline) to store referenced location information about the line crossing. The relationship between LineCrossing and Contact and the relationship between LineCrossing and Company model the line crossing owner/operator and first contact information for the line crossing. Implementation note: Not all companies digitize the linear feature crossing the pipeline centerline, or do so only sporadically. In the situation where digitization of crossing features is sporadic, the LineCrossing feature class will contain some features with <null> shapes. Those companies who do not digitize crossing features at all may prefer to implement LineCrossing as an object class (table), rather than as a feature class. 13.7.7 LineCrossingEasement Class Name: LineCrossingEasement Feature Class Geometry:


APDM Inheritance:

ESRI Object Feature Feature Archive OnlineFeature OnlinePolyline OnlinePolylineForOfflineFeature


LineCrossingEventID (GUID) – The foreign key to the LineCrossing feature


LineCrossingEasement: LineCrossingEasement is M:1 with LineCrossing

SubTypes: -- The LineCrossingEasement feature class stores the online location of the easement to either side of a LineCrossing feature when it intersects the centerline. 13.7.8 LineCrossingLocation Class Name: LineCrossingLocation Feature Class Geometry:


APDM Inheritance:



November 2010 210


LineCrossingEventID (GUID) – The foreign key relationship to the LineCrossing feature.


LineCrossingLocation: LineCrossingLocation is M:1 with LineCrossing

SubTypes: -- The LineCrossingLocation feature class stores the online location where a LineCrossing feature intersects the centerline. 13.8 Cathodic Protection Classes 13.8.1 CPAnode Class Name: CPAnode Feature Class Geometry:


APDM Inheritance:



AnodeMaterial (String, 50) cpAnodeMaterial – The anode material (e.g., Magnesium, Zinc, Graphite, Steel Pipe)

AnodeType (String, 50) cpAnodeType – The type of anode used (e.g., Galvanic, Impressed Current)

AnodeWeight (String, 50) cpAnodeWeight – The weight of the anode.

CPGroundBedEventID (GUID) – Foreign key relationship with the EventID field of the GroundBed feature class.


CPGroundBedCPAnode: CPAnode is M:1 with CPGroundBed CPAnodeLocation: CPAnode is M:N with CPLocation CPAnodeAudit: CPAnode is 1:M with CPAnodeAudit

SubTypes: -- The CPAnode feature class stores information about the anodes utilized in a pipeline cathodic protection system. Anodes receive electrical current and are sacrificed to reduce the probability of pipeline corrosion. The weight of the anode and the size of the pipeline are factors determining how anodes are placed and managed along a pipeline. The



relationship between CPAnode and CPGroundBed models the fact that one or more anodes are located within a single ground bed. However, the CPGroundBed feature also maintains a NumberOfAnodes attribute that may be used in lieu of its association to CPAnode. The relationship between CPAnode and CPLocation shows that an anode may have one or more online locations. 13.8.2 CPBond Class Name: CPBond Feature Class Geometry:


APDM Inheritance:



BondType (Long Integer, 9) cpBondType – The type of bond used (e.g., interference, continuity)

CriticalBond (Long Integer, 9) gnYesNo (required APDM domain) – Indicates whether or not the bond is critical. The gnYesNo domain is considered a ‘core’ APDM domain and must be implemented verbatim.


CPBondLocation: CPBond is 1:M with CPLocation CPBondAudit: CPBond is 1:M with CPBondAudit

SubTypes: -- The CPBond feature class stores information describing cathodic protection bonds that link one or more bond wires together. Bonds are often placed where nonmetallic fittings or valves join pipe segments together as a means of carrying over (or stopping) electric current from one set of pipes to another. The relationship between CPBond and CPLocation shows that a bond may have one or more online locations. 13.8.3 CPCable Class Name: CPCable Feature Class Geometry:


APDM Inheritance:



CableCoating (String, 50) cpCableCoating – The coating material used on the cable (e.g., HMWPE, plastic).

CableSize (String, 50) cpCableSize – The size of the cable (e.g., 4/0, 2/0, 1, 10).

CableType (String, 50) cpCableType – The type of cable


November 2010 212

(e.g., solid, stranded). ColorCode (String, 50) cpCableColorCode – The color code value

of the cable (e.g., red, black, green). NumberOfCables (String, 50) cpCablesNumberOf – The number of

cables in the CPCable feature (1–4). Relationships: (cardinality, optionality, attributes, composite)

CPCableLocation: CPCable is 1:M with CPLocation (Optional Relationship)

CPCableAudit: CPCable is 1:M with CPCableAudit

SubTypes: -- The CPCable feature class stores information about the cathodic protection cables that carry current to/from different cathodic protection devices and the pipe segments of the pipeline. CPCables provide a physical connection between cathodic protection point features and pipe segment features. The relationship between CPCable and CPLocation shows that a cable may have one or more online point locations. 13.8.4 CPGroundBed Class Name: CPGroundBed Feature Class Geometry:


APDM Inheritance:



AnodeSpacing (String, 50) cpAnodeSpacing – The measured spacing between anode in the ground bed.

BackfillMaterial (String, 50) cpBackfillMaterial – The ground material used to backfill the ground bed.

CPRectifierEventID (GUID) – A foreign key relationship with the EventID of the related CPRectifier.

LocationDescription (String, 255) – Free form description of the feature location.

NumberOfAnodes (Short Integer, 4) – The total number of anodes placed with the ground bed.

WaterSystem (String, 50) gnYesNo (required APDM domain) –Indicates if the ground bed has a water system. The gnYesNo domain is considered a ‘core’ APDM domain and must be implemented verbatim.


CPGroundBedCPAnode: CPGroundBed is 1:M with CPAnode CPRectifierCPGroundBed: CPGroundBed is M:1 with CPRectifier CPGroundBedLocation: CPGroundBed is 1:M with CPLocation CPGroundBedAudit: CPGroundBed is 1:M with

CPGroundBedAudit



SubTypes: -- The CPGroundBed feature class is the location on or off the centerline where one or more anodes are placed. Anodes within a ground bed are used to reduce corrosion caused by the flow of direct current from one part of the metal pipeline to another. The relationships between CPGoundBed and CPAnode and between CPGoundBed and CPRectifier model the configuration that typically one CPRectifier feature has one or more CPGroundBeds, containing one or more CPAnodes. The CPGroundBed feature also maintains a NumberOfAnodes attribute that may be used in lieu of its association to CPAnode. The relationship between CPGroundBed and CPLocation shows that a ground bed may have one or more online locations. 13.8.5 CPLocation Class Name: CPLocation Feature Class Geometry:


APDM Inheritance:



ClassEventID (GUID) – The identifier for the feature that the online point location is representing. The class containing the feature is indicated by the SubTypeCD description value for the class.

CPFeatureEventID (GUID) – A foreign key to any one of the offline CP feature classes storing the EventID of the referenced feature.


CPAnodeLocation: CPLocation is M:N with CPAnode CPBondLocation: CPLocation is M:1 with CPBond CPCableLocation: CPLocation is M:1 with CPCable (Optional

Relationship) CPGroundBedLocation: CPLocation is M:1 with CPGroundBed CPRectifierLocation: CPLocation is M:1 with CPRectifier CPTestStationLocation: CPLocation is M:1 with CPTestStation ClassMetaDataCPLocation: CPLocation is 1:M with

ClassMetaData SubTypes: The CPLocation feature class stores the online locations for CPAnode, CPBond, CPGroundBed, CPRectifier, and the CPTestStation offline point features and the CPCable offline polyline features. The relationship between CPLocation and CPAnode, CPBond, CPGroundBed, CPRectifier, CPCable, and CPTestStation allows a common location table for all corrosion features.


November 2010 214

13.8.6 CPRectifier Class Name: CPRectifier Feature Class Geometry:


APDM Inheritance:



Manufacturer (String, 50) cpRectifierManufacturer – The rectifier manufacturer.

Model (String, 50) cpRectifierModel – The rectifier model type. NumberOfNegatives (Long Integer, 9) cpRectifierNegatives – The

number of negatives on the rectifier (1–4). NumberOfAnodes (Short Integer, 4) – The number of anodes

serving the rectifier. OperatingAmpsOut (Double, 15,2) cpRectifierAmpsOut – Actual

amperage output by rectifier. OperatingVoltsOut (Double, 15,2) cpRectifierVoltage – Actual

volts output by rectifier. PowerSource (String, 50) cpRectifierPowerSource – Power source

for rectifier (e.g., solar, electric). RatedAmpsOut (Double, 15,2) cpRectifierAmpsOut – Maximum

rated amperage output by rectifier. RatedVoltsOut (Double, 15,2) cpRectifierVoltage – Maximum

rated volts output by rectifier. RectifierStackType (String, 50) cpRectifierStackType – The type of

stack used by the rectifier (e.g., silicon bridge, silicon diode). ReplaceByDate (Date) – The date by which the rectifier must be

replaced. Relationships: (cardinality, optionality, attributes, composite)

CPRectifierCPGroundBed: CPRectifier is 1:M with CPGroundBed CPRectifierLocation: CPRectifier is 1:M with CPLocation CPRectifierAudit: CPRectifier is 1:M with CPRectifierAudit

SubTypes: -- The CPRectifier feature class stores information about a rectifier. A rectifier is a cathodic protection device that manages the power conversion from AC (alternating current) to DC (direct current) before it is passed on to a pipeline. A CPCable feature can be used to provide connectivity between a rectifier and a pipe segment. The relationship between CPRectifier and CPGroundBed models that zero or more ground beds serve one rectifier. The relationship between CPRectifier and CPLocation shows that a rectifier may have one or more online locations.



13.8.7 CPTestStation Class Name: CPTestStation Feature Class Geometry:


APDM Inheritance:



TestStationType (String, 50) cpTestStationType – The type of test station (e.g., anode, single wire, bonded).


CPTestStationLocation: CPTestStation is 1:M with CPLocation CPTestStationAudit: CPTestStation is 1:M with

CPTestStationAudit

SubTypes: -- The CPTestStation feature class stores the information describing a cathodic protection test station. Test stations are located at strategic points along a pipeline and are used to take readings and measurements of the cathodic protection system. The relationship between CPTestStaton and CPLocation shows that a test station may have one or more online locations. 13.9 Reading Classes 13.9.1 CIS Reading Class Name: CISReading Feature Class Geometry:


APDM Inheritance:



CompanyEventID (GUID) – The EventID of the Company that is doing the reading.

ContactEventID (GUID) – The EventID of the person doing the reading. DistanceFromPreviousReading (Double, 15,2) – The distance

between the reading and the previous reading. InspectionRangeAuditEventID (GUID) – The EventID of the

associated InspectionRangeAudit record. ReadingDate (Date) – The date on which the reading was taken. ReadingUnits (String, 15) – The measured units of the reading.


November 2010 216

ReadingValue (Double 15, 2) – The value taken from the reading. Relationships: (cardinality, optionality, attributes, composite)

ContactCISReading: CISReading is M:1 with Contact CompanyCISReading: CISReading is M:1 with Company InspRangeAuditCISReading: CISReading is M:1 with

InspectonRangeAudit

SubTypes: -- CIS stands for ‘Close Interval Survey’. CISReading illustrates how a set of readings can be attributed to an AuditClass record (in this case an InspectionAudit). CISReading is related to Company and Contact illustrating how contact and surveyor information can be recorded for a set of readings. Close Interval Surveys are conducted along a pipeline usually by depressing a rod into the ground and recording conductivity readings. The surveys are conducted at small intervals relative to the distance of a pipeline (3 meters or 10 feet or less). Typically, a station value is not known or recorded at the location of the reading and therefore, the position of the reading must be interpolated along a known stationed range (InspectionRange) and the given interval of the survey. Readings are measurements taken at points or ranges along the centerline and are also taken at a specific feature. Taking readings at a series of features denotes a scheduled or required activity such as a survey or inspection. There is much variation in the type of readings taken and the types of data collected during a reading. CISReading is provided as an APDM example construct that is proposed to allow one or more reading tables to be related to any AUDIT table for a given feature. An audit record may have zero or more readings of any type. The audit record provides the link to the activity and the source feature without having to carry many potentially unused attributes for other ‘non-reading’ audit events. The < ReadingType >Reading tables provided as example constructs with the APDM have a many-to-one relationship with the Company object class, which models that each reading is performed by just one Company, but that a Company can perform many readings. The < ReadingType >Reading tables also have a many-to-one relationship with the Contact object class, which models that each reading is performed by just one individual Contact person, but that a Contact can perform many readings. 13.9.2 MeterReading Class Name: MeterReading Feature Class Geometry:


APDM Inheritance:


Attributes: (name, type,

ContactEventID (GUID) – The EventID of the person doing the reading.



length, precision, scale, domain, description)

CompanyEventID (GUID) – The EventID of the Company that is doing the reading.

MeterAuditEventID (GUID) – The EventID of the associated MeterAudit record.

ReadingDate (Date) – The date on which the reading was taken. ReadingUnits (String, 15) – The measured units of the reading. ReadingValue (Double 15, 2) – The value taken from the reading.


ContactMeterReading: MeterReading is M:1 with Contact CompanyMeterReading: MeterReading is M:1 with Company MeterAuditMeterReading: MeterReading is M:1 with MeterAudit

SubTypes: 1 – Flow Reading 2 – Pressure Reading

The MeterReading object class is used to store generic readings (or measurements) of typically fluctuating information taken at various features found on or along a pipeline system. Meters are manufactured, pressurized fittings that are used to monitor flow, pressure, and composition of product as it is transported along a pipeline. MeterReadings are measurements of monitored conditions provided by these fittings which are taken at timed intervals and retained for future use. Therefore, a single Meter provides many MeterReadings over the course of time. MeterReading is provided as an APDM example construct that is proposed to allow one or more reading tables to be related to any Audit table for a given feature. An audit record may have zero or more readings of any type. The audit record provides the link to the activity and the source feature without having to carry many potentially unused attributes for other ‘non-reading’ audit events. The < ReadingType >Reading tables provided as example constructs with the APDM have a many-to-one relationship with the Company object class, which models that each reading is performed by just one Company, but that a Company can perform many readings. The < ReadingType >Reading tables also have a many-to-one relationship with the Contact object class, which models that each reading is performed by just one individual Contact person, but that a Contact can perform many readings.


November 2010 218

14.0 Attributed Relationship Classes Attributed relationship classes are M:N relationship classes that have additional attributes beyond just the foreign keys required to implement the relationship. Attributed relationship classes are relatively rare in the APDM. <class name>Audit is an attributed relationship class type that is core to the model; it is described in the 11.2.2.3 <class name>Audit section of the whitepaper. <class name>Contact Class Name: <class name>Contact Feature Class Geometry:

Implemented as an attributed many-to-many relationship class.

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

<class name>EventID (GUID) – Foreign key to the <class name> object/feature class storing the EventID of the object/feature with which this <class name>Contact record is associated.

ContactEventID (GUID) – Foreign key to the Contact object class. ContactType (String, 50) – (Default = 0) – gnContactType – Brief

job description/organizational position of contact person. Related Tables: <class name>: Origin

Contact: Destination ContactAddress Class Name: ContactAddress Feature Class Geometry:

Implemented as an attributed many-to-many relationship class.


AddressEventID (GUID) – Foreign key to the Address object class. ContactEventID (GUID) – Foreign key to the Contact object class. ContactType (String, 50) – (Default = 0) – gnContactType – Brief

job description/organizational position of contact person.

Related Tables: Contact: Origin Address: Destination

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. A.1 Naming Conventions



A.1.1 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 ‘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 or less 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 CouldAffectSegment and AuditDocument. The default concatenated name is CouldAffectSegmentAuditDocument, which is 31 characters long. Using Method 1, the Relationship Class name is CouldAffectSegAuditDocument (27 characters). Using Method 2, the Relationship Class name is CouldAffectSegmentAuditDocumen (30 characters) A.1.2 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


November 2010 220

The <ForeignClass> represents the name of the Origin Feature/Object Class participating in the relationship with the class containing the foreign key attribute. A.2 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”. A.3 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 DB2 ? ?

Informix ? ? MS Access Memo 63K

Table 13 A.4 Documentation Standards The following are the standards and conventions for describing object/feature classes and relationship classes. A.4.1 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)

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


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) – A globally unique identifier for the class. OperationalStatus (String, 50) gnOperationalStatus (required


November 2010 222

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.


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.

A.4.2 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.


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

CompanyEventID (GUID) – Foreign key to the Company object

class. LineLoopEventID (GUID) – 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

Ibid


November 2010 224

Appendix B – Change Log 4.0 to 5.0 B.1 Model Changes from 4.0 to 5.0 (Synopsis) This list details the changes to the core model. The section is provided as a quick reference for APDM users who want to migrate their databases quickly to APDM 5.0.

• Convert all domains to esriFieldTypeString • Add clRefMode domain • moved PipeFunction attribute from PipeSegment to Lineloop as LineFunction • moved LineType attribute from LineLoop to PipeSegment as PipeJurisdiction • added LineJurisdiction to LineLoop w/ clLineJurisdiction domain (Offshore,

Onshore) • Convert EventID to esriTypeGUID, add GlobalID as esriTypeGlobalID • Long Integer Precision set to 9 • Added AuditObject Abstract Class • Added ActivityExtension Abstract Class • Moved specification field from Fitting to relevant concrete classes • Removed LineLevel and LineOrder attribute from Lineloop • Added XYZ coordinates to point feature abstract classes • Add RouteEventID to all online point/polyline features

• Add Measure and Begin/End Measure values for online point/polyline features

• Created relationships for ROUTE from online features to station series • Removed AltRefMeasure object class and relationships from Online Features

• All relationships touching AltRefMeasure need to be corrected • Remove GroupEventID Field from CenterlinePoint, CenterlineObject abstract

classes • Delete StationSeries and ControlPoint subtypes • Rename APDMClass to ClassMetaData • Redefined ReferenceMode table • Merged ControlPoints from different reference modes into single set of

ControlPoint features • Site is object class (CenterlineObject) with related SitePoint and SitePolygon

feature classes • Dropped between ReferenceMode and ControlPoint • Updated relationships between ReferenceMode and ClassMetaData (formerly

APDMClass) • Updated relationships between ReferenceMode and StationSeries



• Relationship betw relationship een LineLoop and OwnerOperator is 1-M instead of a M-N.

• Where possible removed subtypes and converted subtype values to domains. B.2 Model Changes from APDM 4.0 to APDM 5.0 (Detailed) This list describes in detail the changes to the core model from APDM 4.0 to APDM 5.0. The section is provided as a detailed reference for APDM users who want to migrate their databases to APDM 5.0 from APDM 4.0 and require understanding on why design decisions were made. B.2.1 Domains B.2.1.1 Convert string domains to String Coded Value domains

• Change - Use a string coded value domain as the default in the APDM. Where applicable set all coded value domain fields to type String with a Length of 50 characters. The standard default values for all coded value domains will remain “Unknown” and “Unknown-Verified”

• Reasoning - Defining all coded domain values as string types allow the end-user to see the coded value and the description for a domain field as the same value instead of seeing a ‘numeric’ representation of the description. This allows for better visual recognition of the data using industry standard tools such as SQL and the continued use of domain values for data integrity purposes. Another benefit is that string value fields allow existing database implementations to continue to use numeric values to maintain compatibility with existing enterprise systems. To date research shows that string type coded value domain fields do not affect database performance where the length of the fields remains less than 90 characters in length.

B.2.1.2 Added clRefMode domain

• Included Continuous and Engineering values in this domain (Core only, all other values added for Full)

• Set default value of RefMode field in StationSeries to ‘Continuous’ • Removed relationships to ReferenceMode • Removed relationship to APDMClass (now MetaDataClass)

B.2.1.3 Rename Domains - Move PipeFunction to LineFunction

• fcPipeFunction to clLineFunction as LineFunction • Blowoff • Bypass • Crossover • Design Phase – No Pipe • Header (Trunk)


November 2010 226

• Interconnect • Lateral • Launcher • Kicker • Mainline • Receiver • Storage Line • Tap Line • Well Line

• clLineServiceType to fcPipeJurisdiction as PipeJurisdiction • Distribution • High Pressure Gathering • Low Pressure Gathering • Transmission

• Added clLineJurisdiction to Lineloop as LineJurisdiction • Offshore • Onshore

B.2.2 Changes to Abstract Classes and Meta Data Tables B.2.2.1 EventID to esriTypeGUID. GlobalID field as GlobalID.

• Change - Replace the existing data type for the EventID field in all classes from (String type, 38 length) to the ESRI GUID field type. This change would be applied to the APDMObject and FeatureArchive Abstract Classes.

• Replace all existing EventID style foreign keys that are defined with the (String, 38 length) data type to the new ESRI GUID data type

• Added GlobalID to FeatureArchive and APDMObject abstract classes. • Reasoning - ESRI is supplying two new data types for defining attributes in

ArcGIS. GlobalID is a unique GUID identifier field. The GlobalID field is maintained by the underlying ArcSDE engine and is used to uniquely identify features and objects in a geodatabase regardless of what class those features belong to. ESRI maintains the population of values in any field defined by this data type. The values in field are automatically populated when new features and objects are added to a geodatabase. Using this field would remove one of the largest hurdles facing new users implementing APDM – how to populate the EventID field with GUID values. Only one field within a given class can be defined with this data type. A GlobalID field is required if ArcGIS Replication is to be implemented against a Geodatabase. The GlobalID field type represents all the functionality and parameterizations that have been stipulated for the existing EventID field. It is recommended that the EventID field data type be switched from String 38 to esriTypeGUID. This GUID data type is a predefined GUID style data type that is easier to maintain from the UML level and fully supports the creation of GUID values including validation that the GUID values are



properly formatted. Support of these two field data types are congruent with ESRI’s current technology offering.

B.2.2.2 Long Integer Precision has been set to 9.

• Change - Reset all LongInteger precisions in the APDM UML to 9 • Reasoning - Different RDBMS solutions (Oracle, MS SQL Server) allow

different Long Integer precisions values. Each RDBMS maintains it’s own definition of a Long Integer data type with some setting the precision at 10 digits and others at 9 digits. Currently ArcCatalog does not recognize or support anything defined in a UML document with a precision greater than 9 digits. Ultimately when a geodatabase is created using the Case Tool Wizard in ArcCatalog the underlying RDMBS will set the precision of the Long Integer and Double values regardless of what is specified in the UML. Removing the precision stipulation in the documentation will reduce documentation maintenance work. Remove the Long Integer/Double precision/scale notation from the APDM White Paper.

B.2.2.3 Create an Activity Extension Abstract Class – (added as child of Non-

Facility Object) • Change - Create an Activity Extension Abstract Class that provides an extension

to the Activity Object Class in the event that specific types of activities require more attributes to define a particular activity. The Activity Extension abstract class will have a 0..1 relationship with the Activity Object Class. Classes inheriting from this abstract class will promulgate the relationship and add additional attributes to define the particular activity in more detail.

• Reasoning - (Logical) Requires a 0..1 relationship with the Activity Object Class (this is not present in UML). An activity in the APDM is defined as something that an operator does to a pipeline during the normal course of planning, operating, inspecting, maintaining, repairing, managing, and reporting on a pipeline system. Activities in APDM are left purposefully vague so that they may be implemented as needed by an operator that suits one or more particular business purposes. Activities are also used in APDM to track history, comments and integrate features in separate classes together as unified groups. Some activities (such as ILI inspections, HCA analysis) require additional attributes to describe the activity.

B.2.2.4 Created AuditObject Abstract Class containing:

• ActivityEventID • ActivityDate • (Logical) <ParentClass>EventID (and 1..m wormhole from Parent Class to Audit

Class) • (Logical) (Optional 0..1 optional relationship from Activity to class inheriting

from AuditObject • (Logical) M-N wormhole to ExternalDocument


November 2010 228

B.2.2.5 Created ActivityEvent Abstract Class containing:

• ActivityEventID • (Logical) <ParentClass>EventID (and 1..m wormhole from Parent Class to

ActivityEvent Class) • (Logical) (Optional 0..1 optional relationship from Activity to class inheriting

from ActivityEvent B.2.2.6 Segregated Specification Field for Fittings

• Change - Remove the Specification Field from the APDMFitting Abstract Class. B.2.2.7 Added XYZ Coordinate Attributes

• Change - Added POINT_X, POINT_Y, POINT_Z attributes to OnlinePoint, OnlinePointFacility, OfflinePoint, OfflinePointFacility and ControlPoint

• Set Precision/Scale for these fields to 15, 8 for X and Y • Scale of 8 is designed to handle Latitude/Longitude coordinates gathered

from GPS systems. • Set Precision/Scale for Z to 15, 2

• Reasoning - As existing APDM implementations move to a more event-based paradigm having access to the XYZ coordinates for point features at the attribute level allow display of these events using ArcGIS desktop and field data collection style tools without the need for showing the underlying pipeline centerline station series. Coordinate attributes can also be queried using SQL if needed.

• Adding coordinate values adds an alternate behavior for online features. The feature’s location provenance will be Route and Measure or Coordinate information. The typical approach for locating an online feature is to find the measured position along a route and then derive the coordinate values. If this process is reversed then the coordinate values could be assigned and assuming that the derived location of the feature corresponds to an online location then the measure position can be derived.

• Null values are used as default. Using 0.00 values create false data. B.2.2.8 Add Alternate Reference Mode station values

• Change - Add Alternate Reference Mode station values to Online feature classes. • Added or changed fields to abstract classes inheriting from OnlineFeature

abstract class • Added Measure field • Changed FK field root name from StationSeriesEventID to

SeriesEventID in Online classes • Added RouteEventID to Online classes



• Added or changed fields to in CenterlinePoint abstract class (affects ControlPoint)

• Added MeasureValue field (dropped from ControlPoint) • Added StationValue field (dropped from ControlPoint) • Changed FK field root name from StationSeriesEventID to

SeriesEventID in Online classes • Added RouteEventID to Online classes • Changed relationship name from StationSeriesControlPoint to

SeriesControlPoint • Added 1..M relationship from StationSeries to ControlPoint as

RouteControlPoint (RouteEventID to EventID) • Added to CenterlinePolyline abstract class:

• BeginMeasure (moved from StationSeries concrete class) • EndMeasure (moved from StationSeries concrete class) • BeginSeriesEventID (moved from StationSeries concrete class) • EndSeriesEventID (moved from StationSeries concrete class)

• Added fields to StationSeries Concrete Class • Added ParentStationSeriesEventID field (This field serves as a

self-relate FK from the StationSeries featureclass to itself. Currently ESRI does not support self-relates in the Geodatabase).

• Kept the following names consistent with APDM 4.0 • ParentStationSeriesEventID • FromStationSeriesEventID • ToStationSeriesEventID • StationSeriesName

• Reasoning - This option has been suggested as part of the PODS Spatial working

group and represents an extension to the existing APDM design rather than alteration of what is there. Adding alternate reference mode station values to online feature classes would improve performance by reducing the need to traverse relationship classes from online feature classes to the AltRefMeasure object class. All stationing values would be present in the online feature classes for easy reference, comparison and updating. Three fields would be added to the ReferenceMode APDM Metadata class to denote the field names for each reference mode – one field for point features, two fields (representing begin/end station values) for polyline features.

B.2.2.9 Deleted the AltRefMeasure object class

• Change – The following were deleted: • Deleted M-N relationship between AltRefMeasure and SubsystemRange

(Core only) • Deleted relationships between all Online classes and AltRefMeasure (Full

only)


November 2010 230

• Deleted the SubType binary associations between AltRefMeasure and Reference Mode subtypes.

• Reasoning – Adding alternate reference mode station values to online concrete classes rendered the AltRefMeasure object class obsolete.

B.2.2.10 Removed GroupEventID field from Abstract Classes

• Change - Remove GroupEventID Field from CenterlinePoint, CenterlineObject classes

• Reasoning – GroupEventID was also intended to relate continuous measure control points to engineering stationing control points. Implementing. Merging control points into single features removes the need for a grouping attribute. GroupEventID is continued in OnlinePolylineEvents and OnlinePolylineFacility events since a PRM could be interrupted and therefore a mechanism for relating like attributed online polyline events is required.

B.2.2.11 Deleted StationSeries and ControlPoint Subtypes

• Change – Remove subtypes: • Remove RefMode from ControlPoint • Remove SubTypes from ControlPoint • Remove SubTypes from StationSeries.

• Reasoning – Alternate reference modes are now stored with each concrete class rendering these SubTypes obsolete.

B.2.2.12 Renamed APDMClass table to ClassMetaData.

• Change – • Renamed APDMClassType attribute to ClassType. • Renamed gnAPDMClassType domain to gnClassType. • Renamed relationships from ClassMetaData to CPLocation, RemovedPoint,

RemovedLine, (Full Model Only) • Renamed relationships from ClassMetaData to OnlineLocationClass from

APDMClass<Target_Class_Name> to <Target_Class_Name>ClassID. (Full Model Only)

• PODS Spatial added additional attributes to APDMClass (ClassMetaData) • Reasoning – Removed ‘APDM’ nomenclature from model to match PODS

Spatial. B.2.2.13 Moved META Classes to EventSupport Static Structure Diagram

• They still appear in the Abstract Class section of the Logical Model Poster. • ReferenceMode, • APDMClass, • OnlineLocationClass

• PODS Spatial Notes:



• PODS Spatial uses DateInstalled rather than InstallationDate in FacilityObject, OfflineFacility, OnlineFacility Abstract Classes

• PODS Spatial uses Description rather than Remarks in FeatureArchive Abstract Class

• PODS Spatial adds SourceGCL to FeatureArchive Abstract Class • PODS Spatial renames OfflineFeature Abstract Class to

OfflineFeature_AC. PODS already has a OfflineFeature table. B.2.2.14 Rebuilt Reference Mode Table

• Change – Rebuilt ReferenceMode table to support both continuous measure and engineering stationing.

• Reasoning – The ReferenceMode table contains information about the method of measure used in locating features. The ReferenceMode may be in Continuous, Engineering, MilePost etc.

B.2.2 Concrete Class Modifications B.2.2.1 Change domain fcNotApplicable default value.

• Change - fcNotApplicable default value to 0 rather than -1 which it currently is. • Reasoning - The PipeJoinMethod feature class has an attribute called

Manufacturer that uses the fcNotApplicable coded value domain. This feature class has a SubType field. The different subtype classes each use different domains for the Manufacturer field. The default value for this field is 0. The fcNotApplicable coded value domain does not have a default value of 0. Setting the manufacturer field to a value of 0 for a subtyped feature having the fcNotApplicable domain will cause ArcMap to crash.

B.2.2.2 Segregated Specification Field for Fittings

• Change - Add the Specification Field in the PipeSegment, Valve, Meter, Elbow, Tee, Tap, Reducer, Closure

i. Renamed fcSpecification to fcSpecificationPipe ii. Added Specification field to Valve, Meter, Elbow, Tee, Tap,Reducer,

Closure iii. Added the following domains to handle specifications for the above-

listed classes: 1. fcSpecificationMeter 2. fcSpecificationElbow 3. fcSpecificationTee 4. fcSpecificationReducer 5. fcSpecificationClosure 6. fcSpecificationValve 7. fcSpecificationTap


November 2010 232

• Reasoning - Any feature class or event-based object class that inherits from the APDMFitting Abstract Class will inherit the Specification attribute AND the assigned coded value domain to that attribute. The valid value list of specifications that describe features such as valves and flanges are completely different from each other and, from a database integrity and normalization stand-point, having a single domain containing specification values for both of these feature types would cause data integrity issues as a user may describe a valve with a flange specification. Abstract Classes are supposed to be the lowest and most generic representation of a super class. The specification field is unique to the feature type it is describing and thus must be placed in the concrete classes. Field is deleted from the Core Model but remains in the concrete classes in the full model. • Renamed StationSeriesEventID to RouteEventID • Added SeriesEventID (FK) field

B.2.2.3 Merged Control Points

• Change - Stop maintaining multiple sets of control points for each reference mode.

• Only duplicate control points are stored at equation points. • Reasoning – A control point is a known point of XYZ and M location. There is

no reason to not store multiple M values in the control point feature class. Now the ControlPoint feature class can contain multiple foreign key fields to multiple station series records. See the Merged Control Points section of this document (below) for more information.

B.2.2.4 Renamed PipeFunction to LineFunction

• Change – Redefine the type and function of a pipe to be more indicative of the line.

• Move PipeFunction Attribute to the Lineloop Object Class as LineFunction

• Moved LineType Attribute to the PipeSegment feature class • Added LineJurisdiction (clLineJurisdiction) to LineLoop Object Class.

• Reasoning - The PipeFunction attribute describes the function of a line (mainline, interconnect, branch) rather than that of an individual pipe segment (which is defined as a stick or by Heat number). In APDM lines represent a set of continuous pipe, typically of the same outside diameter, that serves ones one function within the pipeline. APDM is designed to allow operators to describe functionality of a line at the lineloop level and to break the pipeline system into lines based on this functionality. It is conceivable that an APDM implementation will not have a PipeSegment feature class especially for international operators with assets in many countries where the use of APDM is limited to presenting an overview of Pipeline locations rather than detailed pipeline attributes. The LineLoop Object class is a part of the APDM core and is there fore required.



Another consideration is that future integration between ESRI data models would require detailed description and definition of pipelines at the line level to differentiate between transmission, distribution, high and low pressure gathering pipelines. LineJurisdiction was added to differentiate between onshore and offshore pipelines.

B.2.2.5 Turn Site into an Object Class

• Change – Site from a point feature class to a Object Class. Inherits from CenterlineObject.

• Reasoning – A single site can have multiple forms of geometric representation. Usually it is just a single point (attached to the network) and one or more polygons.

i. SiteName and SiteType attributes belong to Site B.2.2.6 Keep SitePoint and add SiteBoundary

• Change -- Keep Site Point as an offline facility feature class. • Keep Siteboundary as an offline Non-Point facility feature class.

• Reasoning -- Sites can be represented as point features, some also have polygonal boundaries. It is common to have more than one polygon representing a site boundary.

B.2.2.7 PipeSegment

• Change – Moved LineType from LineLoop – domain clLineType becomes fcPipeJurisdiction

• Reasoning – Whether a pipe is a transmission, gathering, distribution is completely subjective and applies to the pipe rather than the line. The same line can contain high pressure distribution that is not classified as transmission or low pressure distribution. This is a pipe attribute, not a line attribute and it changes a lot.

B.2.2.7 Valve Information

• Change - Added new fields to Valve with domains as appropriate: • Material with fcValveMaterial • Added Walworth, M&J, Daniel, Foster values to fcValveManufacturer

domain. • ResponseTime (Integer) attribute (Represents the shut-off time for a valve.

Added to support emergency flow restriction device analysis) • NominalPressure attribute to Valve feature class. – added as integer field

• Reasoning - The current set of attributes describing the example valve class do not present a complete view of a valve feature

B.2.2.8 Added OnlineFieldNote

• Change - Break up FieldNote to OnlineFieldNote and OfflineFieldNote


November 2010 234

• Replicate FieldNote and rename to OnlineFieldNote • Associate OnlineFieldNote as OnlinePoint Abstract Class

• Reasoning - More operators are conducting field surveys and bringing back field notes. New pipeline is being built that requires various surveys. Experience is showing that field notes comprise two different types – online and offline. Online field notes typically refer to the beginning and ending of polygon type events that are intersected by the centerline and single occurrences – aka a crossing. Offline field notes refer to locations of features off the centerline like structures. Both sets of data should contain XY and Station location.

B.2.2.9 Modification to StructureOrIDSite

• Change - Added the following attributes: • IdentifiedSite (gnYesNo) • IdentifiedSiteType with enIdentfiedSiteType domain • SiteDescription • Added the following relationships

i. StructureOrIDSiteDOTClassSgtMN: StructureOrIDSite is M:N with DOTClassSegment

ii. StructureOrIDSiteDOTClassSgt1M: StructureOrIDSite is 1:M with DOTClassSegment

• Reasoning – Clarification of Structures or Sites used in HCA determination. B.2.2.10 Modifications to DOTClass

• Change – Added new attributes: • ActivityEventID – M..1 FK relationship field from DOTClass to Activity • CorridorTolerance (Double, 15,2) • IDSiteBufferRadius (Double, 15,2) • ClusterBufferEventID (String, 38) – M..1 FK relationship from DOTClass

to ClusterBuffer • Added new relationships:

i. ActivityDOTClass: DOTClass is M:1 with Activity ii. ClusterBufferDOTClass: DOTClass is 1:1 with ClusterBuffer

• Reasoning – Clarification of DOTClass clustering. B.2.2.11 Modifications to HCARange

• Change – Added the following attributes: • ActivityEventID - M..1 FK relationship field from HCARange to Activity • Added the following relationship: • ActivityHCARange: HCARange is M:1 with Activity

• Reasoning – Clarification of HCARange activity B.2.2.12 Modifications to HCASegment

• Change – Added new attributes:



• ActivityEventID - M..1 FK relationship field from HCASegment to Activity

• PIRFactor (Double, 15,2) • Provenance (String, 50) - opHCAMethod1Provenance (new domain) • HCAMethod (Integer, 9) <Subtype Field> • SubTypes:

1 – Method 1 2 – Method 2

• Added new relationship: ActivityHCASegment: HCASegment is M:1 with ActivityMerged

• Reasoning – Clarification of HCASegment methods and activity. B.2.2.12 Converted Subtypes to Type fields with Domains

• Change – Removed Subtypes from PigStructure, PipeSegment, Tap, Tee, Valve, Marker, Anomaly and InspectionRange and replaced them with domain values where appropriate.

• Reasoning – Subtypes add unnessecary complexity to the APDM. Subtypes are not required to create connectivity rules. Subtypes in these feature classes were not used to apply different domains to fields depending on the subtypes. Subtypes require more maintenance of the Physical Model UML. The benefit of automatic symbology did not out-weigh the negatives for implementing.

B.2.3 Concrete Class Additions B.2.3.1 Well

• Change - Add a Well class to support Gathering pipeline systems. (Full model) • Reasoning - There is an industry effort to integration the energy and APDM

models in conjunction with developing a gathering system model in the short term adding a well feature to model helps the gathering folks out a little.

B.2.3.2 ClusterBuffer

• Change – Add a ClusterBuffer class to support DOTClass clustering (Full Model).

• Reasoning – Contains information supporting DOT Class determination using clustering.

B.2.3.3 DOTClassCorridor

• Change – Add DOTClassCorridor class to support DOT Class analysis (Full Model).

• Reasoning – The DOTClassCorridor holds the buffer polygon used in determining DOT Class for the line loop.


November 2010 236

B.2.3.4 DOTClassSegment • Change – Add DOTClassSegment class to support DOT Class analysis (Full

Model). • Reasoning – The DOTClassSegment is a polyline representation of the lineloop

dynamically segmented to specific DOT classes. B.2.3.5 HCACorridor

• Change – Add HCACorridor class to support HCA analysis (Full Model) • Reasoning – The HCACorridor is a polygon representing the PIR buffer of an

HCA. B.2.4 Relationship Modifications B.2.4.1 Dropped relationship between ReferenceMode and ControlPoint

• There is no RefMode field in control point. • There is no need for a relationship. Control points are reference mode agnostic.

B.2.4.2 Relationships between ReferenceMode and StationSeries

• Repaired relationships between ReferenceMode and StationSeries using RefMode attribute as PK-FK key rather than SubTypeCD.

B.2.4.3 Change in LineLoop/OwnerOperator relationship.

• Change – Change OwnerOperator / LineLoop association from M:N to 1:M • Reasoning - This relationship has always been a M:N from OwnerOPerator to

LineLoop. It really needs to be a 1-M from LineLoop to OwnerOperator. • OwnerOperator acts as the intersection table between Company and

LineLoop. • OwnerOperator has all the meta data required to accurately describe the

company, role, percentage and lineloop. B.2.4.4 Fixed and added relationship classes:

• ElevationPoint M-1 to StationSeries (Non-Core) • MarkerLocation M-1 to StationSeries (Non-Core) • FieldNoteLocation M-1 to StationSeries (Non-Core)

B.2.4.5 Dropped relationships between concrete classes and AltRefMeasure

• Change - The following Online concrete classes were modified in the Full model to remove relationships to AltRefMeasure:

• Casing, Coating, CouldAffectSegment, DOTClass, HCARange, HCASegment, InspectionRange, LineCrossingEasement, OperatingPressure, PipeSegment, PressureTest, RightOfWay, RiskAnalysis, Sleeve, SubSystemRange, Anomaly, AnomalyCluster, Appurtenance, Closure, CPLocation, Elbow, ElevationPoint,



FieldNoteLocation, Instrument, Leak, LineCrossingLocation, MarkerLocation, Meter, PipeJoinMethod, Reducer, StructureLocation, Tap, Tee, Valve, Vessel

• Reasoning – Adding alternate reference mode station values to online concrete classes rendered the AltRefMeasure object class obsolete.


November 2010 238

Appendix C – Example GCS Spatial Reference The following is the spatial reference parameters for a standard Geographic Coordinate System (GCS) C.1 Spatial Reference Parameters for GCS Version of APDM Geographic Coordinate System: Name: GCS_North_American_1983 Alias: Abbreviation: Remarks: Angular Unit: Degree(1.74532925199433E-02) Prime Merdidian: Greenwich(0) Datum: D_North_American_1983 Spheroid: GRS_1980 Semimajor Axis: 6378137 Semiminor Axis: 6356752.31414036 Inverse Flattening: 3.35281068118232E-03 X/Y Domain: Min X: -400 Min Y: -400 Max X: 400 Max Y: 400 Scale: 11258999068426.2 M Domain: Min: -1000000 Max: 90071991547409.9 Scale: 100 Z Domain: Min: -50000 Max: 90071992497409.9 Scale: 100 Appendix D - 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.


November 2010 240

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)

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


November 2010 242

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

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


November 2010 244

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.

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.



November 2010 246

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.

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.


November 2010 248

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.

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


November 2010 250

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.

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.


November 2010 252

L Layer 5. 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.

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

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

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.


November 2010 254

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.

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.


November 2010 256

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.

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


November 2010 258

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.

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


November 2010 260

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.

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.


November 2010 262

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.

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.


November 2010 264

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

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.

magpie-inc.commagpie-inc.com/wp-content/uploads/2013/10/20101103... · 11/3/2010 · table of...

Documents