ArcGIS Pipeline Data Model. Version Reference Guide

ArcGIS® Pipeline Data Model
Version 5.0.1 – Reference Guide

November 2010
APDM V5.0 Reference Guide

ArcGIS Pipeline Data Model Version 5.0
Topic Page
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
November 2010 ii
Topic Page
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
ESRI Technical Paper iii

Topic Page
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
November 2010 iv
Topic Page
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
ESRI Technical Paper v

Topic Page
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
November 2010 vi
Topic Page
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
ESRI Technical Paper vii

Topic Page
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
November 2010 viii

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
ESRI Technical Paper ix

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 x
November 2010
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’
APDM V5.0 Reference Guide 1

November 2010
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
November 2010 2
November 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
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.
November 2010 4
November 2010
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
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
November 2010 6
November 2010
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
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
November 2010 8
November 2010
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
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.
November 2010 10
November 2010
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
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.
November 2010 12
November 2010
• 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
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 rbrook@esri.com, 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) rbrook@esri.com
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
November 2010 14
November 2010
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
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
November 2010 16
November 2010
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
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.
November 2010 18
November 2010
• 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
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
November 2010 20
November 2010
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
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
November 2010 22
November 2010
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
• 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
November 2010 24
November 2010
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
APDM Abstract Class SiteEventID StationSeriesEID Station Value Geometry

(fk)*
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.
Does not have Does not
OnlineFacility Has value Is not created
value have value
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.
Does not
OnlineFacility Has value Has value Is not created
have value
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.
Does not have Does not
OnlineFacility Has value Is created
value have value
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 Does not
-- -- Is created
OfflineNonPointFacility have value
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
Has value -- -- Is created
OfflineNonPointFacility
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.
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
November 2010 26
November 2010
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
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:
November 2010 28
November 2010
Figure 1 – Non-Geometric Features (Sites)

November 2010
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.
November 2010 30
November 2010
• 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
• 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
November 2010 32
November 2010
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
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.
November 2010 34
November 2010
• 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
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.
November 2010 36
November 2010
APDM Abstract Classes Object
AP DM Object
ActivityHierarchy
LineLoopHierarcy
ObjectArchive SubSystemHierarchy
CenterlineObject FacilityObject N onFacilityObject
LineLoop
SubSystem Activity
Object Company
AuditObject AuditObject ExternalDocument
OwnerOperator
<fc>Audit
Feature Metadata Object
FeatureArchive
ReferenceMode ClassMetaData OnlineLocationClasses
ObjectArchive
StationSeries
CenterlineP olyline CenterlineP oint OfflineFeature OfflineFacility OnlineFeature

StationSeries ControlPoint Site
StationSeries
CenterlineP olylineEvent StationSeries OfflineP oint
SubSystemRange
OfflineN onP ointFacility OfflineP ointFacility
Site
OnlineFacility
ESRI Simple Object
OnlineP oint
Site
Relationship Wormhole OnlineP olyline
Inheritance OnlineP ointFor OnlineP ointFacility

OfflineFeature
Relationship Cardinality OnlineP olylineFacility
OnlineP olylineFor
OfflineFeature
APDM Abstract Class Fitting
APDM Core Class

<OnlineFeature>
Figure 3 – High Level APDM Abtract Class Hierarchy

November 2010
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.
November 2010 38
November 2010
Example of APDM Inheritance

Registered classes in [Object]
the geodatabase
must have an Object OBJECTID
ID Field
Elbows are modeled in
Feature classes must [Feature] this APDM as a M-
Aware Point Feature
have a geometry field Shape The Elbow feature Class.
class will appear in the
These fields are used APDM geodatabase This feature class
Elbow
for tracking inline [FeatureArchive] with the following inherits all the
history and for attributes and OBJECTID attributes and
archiving. Each field CreatedBy relationships having relationships from it’s
Shape
as a particular CreatedDate inherited them from a ancestor or parent
purpose. EffectiveFromDate set of APDM abstract CreatedBy APDM abstract
EffectiveToDate classes. CreatedDate classes.
EffectiveFromDate
EventID (pk) EffectiveToDate
GlobalID EventID (pk)
HistoricalState <d> HistoricalState <d>
The feature class is an LastModified LastModified
online feature and is
ModifiedBy ModifiedBy
primarily located by OriginEventID
stationed position OriginEventID
ProcessFlag ProcessFlag
(indicated by the the Remarks
relationships to Remarks
StationSeries and CLEditResponse <d> StationSeries
AltRefMeasure). This CLValidityTolerance
RouteEventID (fk)
feature will respond to OnlineFeature
edits on the centerline InstallationDate
CLEditResponse <d>
using values stored in the InServiceDate
CLValidityTolerance StationSeries Site
CLEditResponse and OperationalStatus <d>
RouteEventID (fk)
CLValidityTolerance SiteEventID (fk)
fields. Measure
Station StationSeries
These attributes indicate OnlineFacility SymbolRotation
that the feature class is POINT_X
going to store facility InstallationDate Site POINT_Y
objects that are installed InServiceDate POINT_Z Attributes and
and put into service. The OperationalStatus <d> SeriesEventID (fk) relationships inherited
relationship to Site allows SiteEventID (fk) DateManufactured from APDM abstract
the feature to be stored Grade class must be
without geometry. InletConnectionType <d> implemented without
OnlineP ointFacility InletDiameter <d> alteration to names or
InletWallThickness <d> cardinality.
Measure Manufacturer <d>
Station Material <d>
SymbolRotation PressureRating <d> Additional attributes
The concrete class StationSeries
POINT_X Specification <d> can be added to this
(Elbow) will store a point class for describing or
feature and needs only a POINT_Y ElbowAngle <d>
defining the features in
single station value. POINT_Z ElbowRadius <d>
this class as unique
SeriesEventID (fk) instances of elbows.
Fitting ESRI Simple Object
An elbow is considered a DateManufactured Relationship Wormhole

fitting and inherits the Grade
standard attributes that InletConnectionType <d>
describe the physical Inheritance
InletDiameter <d>
aspects of a fitting. InletWallThickness <d>
Relationship Cardinality
Manufacturer <d>
Material <d> Note: Diagramming the APDM
The elbow feature class is PressureRating <d> abstract classes in this manner APDM Abstract Class
a concrete reduces redundancy in the depiction

implementation of the of attributes for each concrete class APDM Concrete Class
APDM abstract class Elbow in the logical model diagram.
inheritance tree.
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
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
November 2010 40
November 2010
Figure 5 – APDM 5.0 Abstract Classes (Page 1)

November 2010
Figure 6 – APDM 5.0 Abstract Classes (Page 2)
November 2010 42
November 2010
10.2.5.1 APDMObject
Class Name: APDMObject

Feature Class Not Applicable.
Geometry:
APDM ESRI Simple Object (Ancestor)
Inheritance: ObjectArchive (Child - Abstract)
ActivityHierarchy (Child - Core)
InstrumentParameter (Child - Example)
LineLoopHierarchy (Child - Core)
SubSystemHierarchy (Child - Core)
Attributes: EventID (GUID) – A unique identifier for the class.
(name, type, length, precision, scale,
domain, description) GlobalID (GUID) – A globally unique identifier for the class.
Relationships: None
(cardinality, optionality, attributes,
composite)
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
10.2.5.2 ObjectArchive
Class Name: ObjectArchive

Geometry:
APDM ESRI Simple Object  APDMObject (Ancestors - Abstract)
Inheritance: CenterlineObject (Child - Abstract)
FacilityObject (Child - Abstract)
NonFacilityObject (Child - Abstract)
Attributes: OriginEventID (GUID) – The original GUID for a feature.
domain, description) 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
November 2010 44
November 2010
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.
Relationships: None
composite)
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

Geometry:
APDM ESRI Simple Object  APDMObject  ObjectArchive (Ancestor
Inheritance: - Abstract)
AltRefMeasure (Child - Core)

November 2010
LineLoop (Child - Core)

SubSystem (Child - Core)
Attributes: OperationalStatus (String, 30) gnOperationalStatus (required
domain, description) 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.
Relationships: None
composite)
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

Geometry:
APDM ESRI Simple Object  APDMObject  ObjectArchive (Ancestors
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
November 2010 46
November 2010

status of an object within the APDM. Status is used to describe
domain, description)
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.
Relationships: None
composite)
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 Implemented as an Object Class.
Geometry:
APDM ESRI Object  APDM Object  Object Archive 
Inheritance: 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
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

Geometry:
Inheritance: 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.
November 2010 48
November 2010
10.2.5.7 FacilityObject
Class Name: FacilityObject

Geometry:
APDM ESRI Simple Object  APDMObject  ObjectArchive (Ancestors
ValveOperator (Child – Example)
Attributes:
domain, description) 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
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’.
Relationships: Site<FacilityObject class name> (core): Each FacilityObject class is
composite) 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

Geometry:
APDM ESRI Simple Object  ESRI Simple Feature (Optional)
Inheritance: CenterlinePolyline (Child - Abstract)
CenterlinePoint (Child - Abstract)
OfflineFeature (Child - Abstract)
OfflineFacility (Child - Abstract)
OnlineFeature (Child - Abstract)
Attributes: CreatedBy (String, 45) – User ID of the operator who created the
domain, description) 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
November 2010 50
November 2010
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
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.
Relationships: None
composite)
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
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 M Aware polyline feature class.
Geometry:
APDM ESRI Simple Object  ESRI Simple Feature (Optional) 
Inheritance: FeatureArchive (Ancestors - Abstract)
CenterlinePolylineEvent (Child - Abstract)
StationSeries (Child - Core)
Attributes: OperationalStatus (String, 30) gnOperationalStatus (required
domain, description) APDM domain) – A domain value indicating the status of a
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
Relationships: None
composite)
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.
November 2010 52
November 2010
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 May be implemented as an M Aware polyline feature class or as an
Geometry: object class used to build ESRI event themes.
Inheritance: FeatureArchive  CenterlinePolyline (Ancestors - Abstract)
SubSystemRange (Child - Core)
Attributes: RouteEventID (GUID) – Foreign key to a Continuous station series
domain, description) 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’.
Relationships: StationSeries<CenterlinePolylineEvent name> (core):
composite) 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
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 Implemented as an M Aware point feature class.
Geometry:
ControlPoint – (Child - Core)
Attributes: CLControl (String, 30) gnYesNo (required APDM domain) – A
domained, notes) 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
Point_Z (Double, 15, 2) – Z axis (Elevation) measure of the Point
November 2010 54
November 2010
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: StationSeries<CenterlinePoint class name> (core): <CenterlinePoint
(cardinality, optionality, composite,
inheritance) 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 Implemented as an Non-M-Aware Polyline or Non-M-Aware
Geometry: Polygon feature class
AlignmentSheet – (Child - Example)
HighConsequenceArea – (Child - Example)
LineCrossing – (Child - Example)
RemovedLine – (Child - Example)

November 2010
StructureOutline – (Child - Example)

IDSiteArea – (Child - Example)
Attributes: Status (String, 30) gnStatus (required APDM domain) – Defines the
domained, notes) 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.
Relationships: Each and every Offline Feature may have zero or more online
inheritance) 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 Implemented as an Non-M-Aware Point feature class
Geometry:
Inheritance: FeatureArchive  OfflineFeature (Ancestors - Abstract)
DocumentPoint – (Child - Example)
FieldNote – (Child - Example)
RemovedPoint – (Child - Example)
SitePoint – (Child - Example)
NearestPointToLine – (Child - Example)
Attributes: Point_X (Double, 15, 2) – X axis (East-West) geographic
domained, notes) coordinate of the Point feature.
November 2010 56
November 2010
feature.
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.
Relationships: None
inheritance)
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 Implemented as an Non-M Aware Polygon feature class
Geometry:
Site – (Child - Core)
Attributes: InServiceDate (Date) - Represents the date a piece of equipment is
domained, notes) actually put in service and is used primarily for accounting
purposes. The InServiceDate date may be later than the
installation date.
Note that InstallationDate is important for risk analysis.

November 2010

by the APDM.
Relationships: Each and every OfflineFacility may have zero or more online
inheritance) 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 Implemented as a Non-M Aware Polygon or Non-M Aware
Geometry: polyline feature class
Inheritance: FeatureArchive  OfflineFacility (Ancestors - Abstract)
CPCable – (Child - Example)
PIGStructure – (Child – Example)
Attributes: SiteEventID (GUID, FK) – Indicates the site (e.g. compressor
domained, notes) 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
Relationships: Site<OffilneNonPointFacility class name> (core):
inheritance) <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
November 2010 58
November 2010
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 Implemented as an Non-M Aware Point feature class
Geometry:
Inheritance: FeatureArchive  OfflineFacility (Ancestors - Abstract)
CPAnode – (Child - Example)
CPBond – (Child – Example)
CPGroundBed – (Child – Example)
CPRectifier – (Child – Example)
CPTestStation – (Child – Example)
Marker – (Child – Example)
Attributes: SiteEventID (GUID, FK) – Indicates the site (e.g. compressor
domained, notes) 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
alignment sheets.
Relationships: Site<OfflinePointFacility class name> (core): <OfflinePointFacility
inheritance) 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
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 Implemented as an M-Aware Polyline feature or an M Aware Point
Geometry: feature class or an Object Class representing an event table.
Inheritance: FeatureArchive (Ancestors – Abstract)
Attributes: CLEditResponse (Long Integer, 9) clEditResponse (required
domained, notes) 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.
Relationships: StationSeries<OnlineFeature class name> (core): <OnlineFeature
inheritance) 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.
November 2010 60
November 2010
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 Implemented as an M-Aware Polyline feature or an Object Class
Geometry: representing an Event table.
Inheritance: 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)
Attributes: BeginMeasure (Double, 15, 2) - A measure value along a
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 an

November 2010

the linear feature.
Status (String, 30) gnStatus (required APDM domain) – Defines the
Relationships: Each and every OnlinePolyline may have zero or more
inheritance) 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.
November 2010 62
November 2010
10.2.5.19 OnlinePolylineForOfflineFeature
Class Name: OnlinePolylineForOfflineFeature

Inheritance: FeatureArchive  OnlineFeature  OnlinePolyline (Ancestors –
Abstract)
LineCrossingEasement (Child – Example)
Attributes: BeginOffsetAngle (Double, 15, 2) - The angle of the vector from
domained, notes) 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.).
Relationships: Each and every OnlinePolylineForOfflineFeature must be the
inheritance) 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
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 Implemented as an M-Aware Point feature or an Object Class
Inheritance: FeatureArchive  OnlineFeature (Ancestors – Abstract)
Anomaly – (Child - Example)
AnomalyCluster – (Child - Example)
ElevationPoint – (Child - Example)
Leak – (Child - Example)
Attributes: Measure (Double, 15, 2) – A measure value along an Engineering
domained, notes) 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.
Status (String, 30) gnStatus (required APDM domain) – Defines the
feature.
November 2010 64
November 2010

alignment sheets.
Relationships: Each and every OnlinePoint may be represented by zero or more
inheritance) 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

Inheritance: FeatureArchive  OnlineFeature  OnlinePoint (Ancestors –
Abstract)
CPLocation (Child – Example)
FieldNoteLocation (Child – Example)
LineCrossingLocation (Child – Example)
MarkerLocation (Child – Example)
StructureLocation (Child – Example)
Attributes: <OfflineFeature>EventID (GUID, String, 38, FK) – Indicates the
domained, notes) 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
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.).
Relationships: Each and every OnlinePointForOfflineFeature must be the online
inheritance) 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 Implemented as an M-Aware Polyline feature class, an M-Aware
Geometry: Point feature class or an Object class representing an Event table.
Inheritance: FeatureArchive  OnlineFeature (Ancestors - Abstract)
Attributes: InServiceDate (Date) - Represents the date a piece of equipment is
domained, notes) actually put in service and is used primarily for accounting
purposes. The date in the InServiceDate field may be later than
November 2010 66
November 2010
the installation date.

Note that InstallationDate is important for risk analysis.
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
Relationships: Site<OnlineFacility class name>: <OnlineFacility class name> is
inheritance) 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

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

Continuous station series used to position and locate the start of
domained, notes)
the linear feature.

EndMeasure (Double, 15, 2) – A measure value along an
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.
Relationships: None.
inheritance)
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

Inheritance: FeatureArchive  OnlineFeature  OnlineFacility (Ancestors –
Abstract)
Appurtenance – (Child - Example)
Instrument – (Child - Example)
PipeJoinMethod – (Child - Example)
Tap – (Child - Example)
Valve – (Child - Example)
Vessel – (Child, Example)
Attributes: Measure (Double, 15, 2) – A measure value along an Engineering
domained, notes) station series used to position and locate the point feature.
November 2010 68
November 2010
Station (Double, 15, 2) – A measure value along a Continuous

station series used to position and locate the point feature on the
centerline.
feature.
such as CAD. Allows all point symbols within the APDM to be
alignment sheets.
Relationships: None
inheritance)
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 Implemented as an M-Aware Point feature or an Object class
Inheritance: FeatureArchive  OnlineFeature  OnlineFacility 
OnlinePointFacility (Ancestors – Abstract)
Closure – (Child - Example)
Elbow – (Child - Example)
Meter – (Child - Example)
Reducer – (Child - Example)
Tee – (Child - Example)
Attributes: DateManufactured (Date) – The date the fitting or facility was
domained, notes) manufactured.
Grade (String, 30) fcGrade - The grade at which the fitting material

November 2010
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: None
inheritance)
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,
November 2010 70
November 2010
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 Object Class
Geometry:
Feature Dataset: --
APDM Class --
Type:
Attributes: ClassEventID (GUID) – A unique identifier for the class.
domained, notes) 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.
Relationships: ClassOriginClass (core): ClassMetaData is 1:M with
inheritance) OnlineLocationClass

November 2010
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 • OfflinePointFacility
• APDMObject • OfflineNonPointFacility
• AuditObject • OnlineFeature
• CenterlineObject • OnlinePolyline
• FacilityObject • OnlinePolylineForOfflineFeature
• NonFacilityObject • OnlinePoint
• CenterlinePolyline • OnlinePointForOfflineFeature
• CenterlinePolylineEvent • OnlineFacility
• CenterlinePoint • OnlinePolylineFacility
• OfflineFeature • OnlinePointFacility
• OfflinePoint • Fitting
• OfflineFacility
10.3.1.3 OnlineLocationClass
Class Name: OnlineLocationClass

Geometry:
Feature Dataset: --
APDM Class --
November 2010 72
November 2010
Type:
Other Notes: --
Attributes: OriginClassEventID (GUID) – A unique identifier for the ‘offline’
domained, notes) 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.
Relationships: ClassOriginClass (core): OnlineLocationClass is M:1 with
inheritance) 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

Geometry:
Feature Dataset: --
APDM Class --
Type:
Attributes: RefMode (String, 50) – clRefMode (Default=Continuous) –
domained, notes) 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
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.
Relationships: ReferenceModeStationSeries (core): ReferenceMode is 1:M with
inheritance) 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
November 2010 74
November 2010
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
Figure 7 – Reference Mode Basis
November 2010 76
November 2010
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
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
November 2010 78
November 2010
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
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:
November 2010 80
November 2010
Figure 10 – CL Edit Response (Part 1)

November 2010
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:
November 2010 82
November 2010
Figure 11 – CL Edit Response (Part 2)

November 2010
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
November 2010 84
November 2010
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
Figure 12 – CL XY Edit Response
November 2010 86
November 2010
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
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
November 2010 88
November 2010
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
CLZEditResponse behavior is depicted below:
Figure 14 – CL Z Edit Response
November 2010 90
November 2010
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
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 RefModeMeasureR RefModeUnits <d> RefModeType <d> RefModeBasis <d> IsPRM ParentRefMode
(root for FK) ootName <d>
Continuous Route Measure Feet Uninterrupted and 3D Geoid Yes <NULL>

Adjustable
Engineering Series Station Feet Interrupted and Not 3D Geoid No Continuous
Adjustable
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.
November 2010 92
November 2010
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
• 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
• 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.
November 2010 94
November 2010
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
OnlinePolyline & OnlinePoint related to StationSeries

[Object] [Object] [Object]
OBJECTID OBJECTID OBJECTID
[Feature] [Feature] [Feature]
Shape Shape Shape
[FeatureArchive] [FeatureArchive] [FeatureArchive]
GlobalID GlobalID GlobalID
EventID (pk) EventID (pk) EventID (pk)
CreatedBy CreatedBy CreatedBy
CreatedDate CreatedDate CreatedDate
EffectiveFromDate EffectiveFromDate EffectiveFromDate
EffectiveToDate EffectiveToDate EffectiveToDate
HistoricalState <d> HistoricalState <d> HistoricalState <d>
LastModified LastModified LastModified
ModifiedBy ModifiedBy ModifiedBy
OriginEventID OriginEventID OriginEventID
ProcessFlag ProcessFlag ProcessFlag
Remarks Remarks Remarks
OnlineFeature CenterlinePolyline OnlineFeature
CLEditResponse <d> BeginMeasure CLEditResponse <d>
CLValidityTolerance <d> EndMeasure CLValidityTolerance <d>
RouteEventID (fk) BeginStation RouteEventID (fk)
OnlinePolyline EndStation OnlinePoint
OperationalStatus <d>
BeginMeasure Measure
StationSeries
EndMeasure SeriesEventID
BeginSeriesEventID SeriesName Station
BeginStation SeriesOrder Status <d>
EndSeriesEventID ParentStationSeriesEventID (sfk) SymbolRotation
EndStation LineLoopEventID (fk) Poiint_X
Status <d> FromConnectionStationValue Point_Y
InspectionRange FromSeriesEventID (sfk) Point_Z
ToConnectionStationValue
InspectionDate ToSeriesEventID (sfk) Leak
RefMode <d> (fk) DateRepaired
Contact
DateReported
Depth
Activity LeakCause <d>
ControlPoint
LeakOrigin <d>
Lineloop
LeakStatus <d>
Object MethodDetected <d>
SubSystemRange RepairType <d>
OBJECTID
ReferenceMode
EventID (pk)
RefMode <d>
RefModeMeasureRootName
RefModeBasis <d>
RedModeType <d>
RefModeUnits <d>
IsPRM <d>
ParentRefModeEventID (fk)
RefModeRootName
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
November 2010 96
November 2010
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 RefModeMeasureR RefModeUnits <d> RefModeType <d> RefModeBasis <d> IsPRM ParentRefMode
e (root for FK) ootName <d>
Continuous Route Measure Feet Uninterrupted and 3D Geoid Yes <NULL>

Adjustable
Engineering Series Station Feet Interrupted and Not 3D Geoid No Continuous
Adjustable
Table 1
LineLoop Q1
Figure 17
This table outlines two forms of linear

Continuous Station Series A
referencing: continuous measure and
0.0 10.0 20.0 40.0 50.0 60.0 engineering stationing. Each linear
referencing method is stored in the
ReferenceMode object class as a single
25.0 35.0
Engineering Station Series
record or object. Therefore each object is
0.0 10.0 1 20.0 40.0 50.0 3 60.0 identified by an EventID value. The
20.0
0.0
Continuous Measure object has a
RefMode of ‘Continuous’. This value is
15.0 2 5.0
derived from the clRefMode domain.
Control Points This domain value is applied to the
0.0 10.0 20.0
20.0
40.0 50.0 60.0 RefMode attribute of the StationSeries
0.0 feature class. The
15.0 5.0 RefModeMeasureRootName describes
the root name used for all ‘Measure’
Resulting APDM Control Points
attributes in each Online (and the
0.0,0.0 10.0,10.0 20.0,20.0 40.0,40.0
d h
50.0,50.0
j
60.0,60.0
StationSeries and ControlPoint) feature
i
b c
20.0,20.0
e
0.0,40.0
k
class. An OnlinePoint feature class will
f g
15.0,25.0 5.0,35.0 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

November 2010
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
November 2010 98
November 2010
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.
LIneLoop In the APDM 5.0, duplicate control
Attribute Value points have been merged. Each control
ObjectID 1
GlobalID {A298F545-4209-4CA5-9E2F-CE7F8C50E2A3}
point will contain one attribute for each
EventID (pk) {F3004B6A-40A6-49A6-B951-7F4F15D27E7E} reference mode. The only time that
CreatedBy Pcgv
CreatedDate 10/05/2009
control points are duplicated are at
EffectiveFromDate 1/1/2009 ‘equations’ representing the linking of
EffectiveToDate <Null>
HistoricalState <d> Current
two ‘interrupted’ style station series
LastModified 10/05/2009 belonging to the same parent ‘non-
ModifiedBy Pcgv
OriginEventID <Null>
interrupted’ style station series. The
ProcessFlag <Null> lower diagram (above) now shows
Remarks APDM 5.0 LineLoop Example
OperationalStatus <d> Active
control points (b-k) with ‘engineering’
LineName station value (black) and a ‘continuous’
Q1
Q1
LineFunction <d> Transmission measure value (red).

LineJurisdiction <d> Onshore
Table 2

November 2010
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- {73B57D7B-195F-4940- {ECD9C22F-855A-483A- {10DE1E6D-

8035-FD52804B5DDD} 8E0F-0A1B6542F6C3} 93F3-8E618F1C5E78} 43E3-45CA-
A50B-
CA7F5E2127FB}
EventID (pk) {4AE67B70-2B52-4DED- {8914F122-C505-4A4F- {85CE58EB-0F7B-4EF3- {789633DF-727C-
89D8-6E8C88CAFC2A} B335-2DBF7F0D4140} 9584-36F23B3D0461} 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 APDM 5.0 Engineering APDM 5.0 Engineering APDM 5.0
StationSeries Example StationSeries Example StationSeries Example 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 <Null> {4AE67B70-2B52-4DED- {4AE67B70-2B52-4DED- {4AE67B70-2B52-
(fk) 89D8-6E8C88CAFC2A} 89D8-6E8C88CAFC2A} 4DED-89D8-
6E8C88CAFC2A}
LIneLoopEventID (fk) {F3004B6A-40A6-49A6- {F3004B6A-40A6-49A6- {F3004B6A-40A6-49A6- {F3004B6A-
B951-7F4F15D27E7E} B951-7F4F15D27E7E} B951-7F4F15D27E7E} 40A6-49A6-
B951-
7F4F15D27E7E
}
FromConnectionStation <Null> <Null> <Null> <Null>
Value
FromSeriesEventID <Null> <Null> <Null> <Null>
ToConnectionStationVal <Null> <Null> <Null> <Null>

ue
ToSeriesEventID <Null> <Null> <Null> <Null>
RefMode Continuous Engineering Engineering Engineering

Table 3
November 2010 100

November 2010
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 GUID GUID GUID GUID GUID GUID GUID GUID GUID GUID
(pk)
CreatedBy Pcgv Pcgv Pcgv Pcgv Pcgv Pcgv Pcgv Pcgv Pcgv Pcgv
CreatedDat 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/2 10/05/2009
e 009
EffectiveFr 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/200 1/1/2009
omDate 9
EffectiveTo <Null> <Null> <Null> <Null> <Null> <Null> <Null> <Null> <Null> <Null>
Date
HistoricalSt Current Current Current Current Current Current Current Current Current Current
ate <d>
LastModifie 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/2 10/05/2009
d 009
ModifiedBy Pcgv Pcgv Pcgv Pcgv Pcgv Pcgv Pcgv Pcgv Pcgv Pcgv
OriginEvent <Null> <Null> <Null> <Null> <Null> <Null> <Null> <Null> <Null> <Null>
ID
ProcessFla <Null> <Null> <Null> <Null> <Null> <Null> <Null> <Null> <Null> <Null>
g
Remarks b c d e f g h i j k
Operational Active Active Active Active Active Active Active Active Active Active
Status <d>
RouteEvent {4AE67B {4AE67B7 {4AE67B7 {4AE67B7 {4AE67B7 {4AE67B7 {4AE67B7 {4AE67B7 {4AE6 {4AE67B
ID (fk) 70-2B52- 0-2B52- 0-2B52- 0-2B52- 0-2B52- 0-2B52- 0-2B52- 0-2B52- 7B70- 70-2B52-
4DED- 4DED- 4DED- 4DED- 4DED- 4DED- 4DED- 4DED- 2B52- 4DED-
89D8- 89D8- 89D8- 89D8- 89D8- 89D8- 89D8- 89D8- 4DED 89D8-
6E8C88C 6E8C88C 6E8C88C 6E8C88C 6E8C88C 6E8C88C 6E8C88C 6E8C88C - 6E8C88C
AFC2A} AFC2A} AFC2A} AFC2A} AFC2A} AFC2A} AFC2A} AFC2A} 89D8- AFC2A}
6E8C
88CA
FC2A}
MeasureVa 0 10 20 20 25 35 40 40 50 60
lue
SeriesEven {8914F12 {8914F12 {8914F12 {85CE58 {85CE58 {85CE58 {85CE58 {789633D {7896 {789633D
tID (fk) 2-C505- 2-C505- 2-C505- EB-0F7B- EB-0F7B- EB-0F7B- EB-0F7B- F-727C- 33DF- F-727C-
4A4F- 4A4F- 4A4F- 4EF3- 4EF3- 4EF3- 4EF3- 4CD0- 727C- 4CD0-
B335- B335- B335- 9584- 9584- 9584- 9584- B216- 4CD0- B216-
2DBF7F0 2DBF7F0 2DBF7F0 36F23B3 36F23B3 36F23B3 36F23B3 9E5EBF5 B216- 9E5EBF5
D4140} D4140} D4140} D0461} D0461} D0461} D0461} 507B9} 9E5E 507B9}
BF550
7B9}
StationValu 0 10 20 20 15 5 0 40 50 60
e
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 No No No No No No No No No No
<d>
CLStationE Assigned Assigned Assigned Assigned Assigned Assigned Assigned Assigned Assigned Assigned
ditRespons

November 2010
e <d>
CLXYEditR Assigned Assigned Assigned Assigned Assigned Assigned Assigned Assigned Assigned Assigned
esponse
<d>
CLZEditRe Assigned Assigned Assigned Assigned Assigned Assigned Assigned Assigned Assigned Assigned
sponse
<d>
SymbolRot 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
ation
ControlPoin 0.0 0.0 0.0 0.0 -90.0 +90.0 +90.0 0.0 -90 0.0
tAngle
ControlPoin PI PI PI PI PI PI PI PI PI PI
tType <d>
PIDirection None None None RT LT LT RT None None None
<d>
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
LineLoop Q1
In this example Inspection Range features

(b,c,d,e) and Leak features (f, g) are
Continuous Station Series A
located on LineLoop Q1. In APDM 5.0
0.0 10.0 20.0 40.0 50.0 60.0
both the measure values from Continuous
Station Series A and station values from
25.0 35.0
Engineering Station Series 1, 2 and 3 are
Engineering Station Series
0.0 10.0 1 20.0 40.0 50.0 3 60.0
recorded with the features.
20.0
0.0
The following tables illustrate both sets of
15.0 2 5.0
features and the FK relationships between
Inspection Range and Leak Features
those features and the StationSeries
f g feature class.
b c e
d
Each inspection range feature belongs on
the Q1 route as denoted by the
November 2010 102

November 2010
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- {59C8A169-3578-4118- {061FE0EC-1D1E-4CDC-976E- {811062D1-E1C6-

A872-B77FD5DE15E8} AAD3-FF6F79FEBD93} 5A938FB7ECE3} 4A5E-8921-
1C5C8BC8492D}
EventID (pk) {76F605CD-6FB5-452C- {4BE3CB84-7E7A-430F- {60FABB8B-7148-404F-90F5- {E34B4F7C-2DFB-
8947-2C64E9C76D5D} AAFD-3F6CA20DF9E2} B1A14F0320A0} 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 APDM 5.0 APDM 5.0 InspectionRange APDM 5.0
InspectionRange Example InspectionRange Example Example d InspectionRange
b c
Example e
CLEditResponse Relative Relative Relative Relative
<d>
CLValidityTolerance 0.00 0.00 0.00 0.00
RouteEventID (fk) {4AE67B70-2B52-4DED- {4AE67B70-2B52-4DED- {4AE67B70-2B52-4DED-89D8- {4AE67B70-2B52-
89D8-6E8C88CAFC2A} 89D8-6E8C88CAFC2A} 6E8C88CAFC2A} 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- {73B57D7B-195F-4940- {73B57D7B-195F-4940-8E0F- {789633DF-727C-
8E0F-0A1B6542F6C3} 8E0F-0A1B6542F6C3} 0A1B6542F6C3} 4CD0-B216-
9E5EBF5507B9}
EndSeriesEventID {73B57D7B-195F-4940- {73B57D7B-195F-4940- {789633DF-727C-4CD0-B216- {789633DF-727C-
8E0F-0A1B6542F6C3} 8E0F-0A1B6542F6C3} 9E5EBF5507B9} 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
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 {789633DF-727C-4CD0-B216-9E5EBF5507B9}
{85CE58EB-0F7B-4EF3-9584-36F23B3D0461}
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
November 2010 104

November 2010
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
LineLoop Q1
In APDM 5.0 control points sharing
the same XYZ coordinate but
different reference modes are merged
Continuous Station Series A into a single control point. In the
0.0 10.0 20.0 40.0 50.0 60.0 diagram below the APDM 5.0
control points are shown. Instead of
25.0 35.0
duplicate points being maintained for
all sets of control points only a single
Continuous Control Points
0.0 10.0 20.0 40.0 50.0 60.0
point is saved. Non-equation control
points B, C, F, G, J, and K are
merged into a single point. Equation
25.0 35.0 points D, E, H, I now require two
points – one for each engineering
Engineering Station Series station series at the equation, rather
0.0 10.0 1 20.0 40.0 50.0 3 60.0 than the three points that were
20.0
0.0 required in APDM 5.0.
15.0 2 5.0
To facilitate the merging of control
Engineering Control Points points new attributes are required to
0.0 10.0 20.0 40.0 50.0 60.0 manage this data. The diagram in the
20.0
0.0 following page shows the new
additions to the ControlPoint feature
15.0 5.0
class schema. Each control point
Resulting APDM Control Points must have a two foreign key
0.0,0.0 10.0,10.0 20.0,20.0 40.0,40.0 50.0,50.0 60.0,60.0 attributes – one for each reference
d h j
b c
20.0,20.0
e i k mode. Each Control point must have
0.0,40.0
f g two measure or station value
15.0,25.0 5.0,35.0
attributes – one for each reference
mode.

November 2010
StationSeries and ControlPoint FeatureClasses

[Object] [Object]
OBJECTID OBJECTID
[Feature] [Feature]
Shape Shape
[FeatureArchive] [FeatureArchive]
GlobalID GlobalID
EventID (pk) EventID (pk)
CreatedBy CreatedBy
CreatedDate CreatedDate
EffectiveFromDate EffectiveFromDate
EffectiveToDate EffectiveToDate
LastModified LastModified
OriginEventID OriginEventID
Remarks Remarks
CenterlinePolyline CenterlinePoint
BeginMeasure OperationalStatus <d>
EndMeasure RouteEventID (fk)
BeginStation MeasureValue
EndStation SeriesEventID (fk)
OperationalStatus <d> StationValue
StationSeries Point_X
Point_Y
SeriesName
Point_Z
SeriesOrder
CLControl <d>
ParentStationSeriesEventID (sfk)
CLStationEditResponse <d>
LineLoopEventID (fk)
CLXYEditResponse <d>
FromConnectionStationValue
CLZEditResponse <d>
FromSeriesEventID (sfk)
SymbolRotation
ToSeriesEventID (sfk) ControlPoint
RefMode <d> (fk)
ControlPointAngle
ControlPointType <d>
PIDirection <d>
ControlPoint
Lineloop
GeoMetaData
SubSystemRange
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.
November 2010 106

November 2010
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
• 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:
November 2010 108

November 2010
APDM Core
CenterlineP oint CenterlineP olyline
ControlP oint StationSeries

ControlPointAngle StationSeriesName OnlineFeature
ControlPointType <d> SeriesOrder
PIDirection <d> ParentStationSeriesEventID (fk) ClassMetaData
FromConnectionStationValue ReferenceMode
FromStationSeriesEventID (fk)
GeoMetaData ToConnectionStationValue
ToStationSeriesEventID (fk)
RefMode <d>
ControlPointAudit
ControlPointEventID (fk)
StationSeriesAudit
StationSeriesEventID (fk)
CenterlineObject OfflineFacility
SubSystem LineLoop Site

SubSystemName LineName SiteName
LineFunction <d> SiteType <d>
LineJurisdiction <d>
OwnerOperator
Contact SiteAudit
Product
SiteEventID (fk)
SubSystemHierarchy
LineLoopHierarchy
SubSystemHierarchy
LineLoopHierarchy
Contact
SubSystemAudit LineLoopAudit OnlineFacility

SubSystemEventID (fk) LineLoopEventID (fk)
CenterlineP olylineEvent
FacilityObject
SubSystemRange
SubSystemEventID (fk)
StationSeries
Figure 21

November 2010
AP DM Object APDM Core (Continued)

GeoMetaData
LineLoopHierarchy Activity ActivityHierarchy ExternalDocument

ParentLineLoopEventID (fk) ActivityDate ParentActivityEventID (fk) DocumentDescription
ChildLineLoopEventID (fk) ActivityDescription ChildActivityEventID (fk) DocumentType <d>
ActivityName FileName
ActivityType <d> FilePath
LineLoop HyperLink
LineLoop
GeoDatabase
InspectionRange
SubSystemHierarchy Transmission (FeatureDataset)
ControlPoint (Core)
ParentSubsystemEventID (fk)
ChildSubsystemEventID (fk) Site (Core)
<classname>Audit
StationSeries (Core)
<classname>EventID (PK)
ActivityDate SubSystemRange (Core)
SubSystem
ActivityEventID (PK) Activity (Core)
SubSystem ActivityHierarchy (Core)
<parent class> ClassMetaData (Metadata)

Company (Core)
N onFacilityObject ControlPointAudit (Core)
ExternalDocument (Core)
LineLoop (Core)
LineLoopAudit (Core)
LineLoopHierarchy (Core)
Product OwnerOperator Company OnlineLocationClass (Metadata)
Product <d> CompanyEventID (fk) CompanyLabel OwnerOperator (Core)
LineLoopEventID (fk) CompanyName
OwnerPercentage <d> CompanyType <d> Product (Core)
OwnerType <d> ReferenceMode (MetaData)
LineLoop SiteAudit (Core)
StationSeriesAudit (Core)
SubSystem (Core)
SubSystemAudit (Core)
SubSystemHierarchy (Core)
Legend
ESRI Simple Object
NOTE: The Catalog View does not
Metadata Object show any relationship classes Only
APDM Abstract Class feature and object classes are
OBJECTID
shown.
APDM Audit Class
Relationship Wormhole
ReferenceMode ClassMetaData OnlineLocationClasses
Wormhole to non-Core
Class RefMode <d> ClassType <d> OriginClassEventID (fk)
Wormhole to APDM RefModeMeasureRootName ClassEventID (pk) OnlineLocationClassEventID (fk)
Abstract Class RefModeBasis <d> ClassName OnlineLocationMechanism <d>
RedModeType <d> RequiresGeometry
Inheritance RefModeUnits <d>
IsPRM <d>
Relationship Cardinality ParentRefMode (fk) CPOnlineLocation
RefModeRootName The metadata classes represent a set of object
Subtype RemovedPoint classes that are used to hold information
about the reference modes, information about
(fk) Foreign Key each concrete class inheriting from an ‘APDM
StationSeries RemovedLine Abstract Class’ and information about which
‘offline’ APDM classes have related ‘online’
<d> Domain Attribute
polyline or ‘online’ point classes.
Figure 22
November 2010 110

November 2010
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 Implemented as an Object Class
Geometry:
Inheritance: NonFacilityObject (Ancestors – Abstract)
Attributes: ActivityDate (date) – The date on which the activity occurred.
(name, type, length, ActivityDescription (String, 120) – A description or categorization
precision, scale,
domained, notes) of the activity.
ActivityName (String, 90) – A title or description of the activity.
ActivityType (String, 50) – gnActivityType – The type of activity.
Relationships: ActivityChildActivity (core): Activity is 1:M with

(cardinality, optionality, ActivityHierarchy
composite, inheritance)
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
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 Implemented as an Object Class
Geometry:
APDM ESRI Object  APDM Object (Ancestors – Abstract)
Inheritance:
Attributes: ParentActivityEventID (GUID) – A foreign key to Activity storing
(name, type, length, the EventID of an activity that represents a “parent” hierarchy
precision, scale,
domained, notes) 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.
Relationships: ActivityChildActivity (core): Activity is 1:M with
(cardinality, optionality, ActivityHierarchy
ActivityParentActivity (core): Activity is 1:M with
ActivityHierarchy
November 2010 112

November 2010
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
11.1.2.3 <class name>Audit
Class Name: <class name>Audit

Geometry:
Inheritance: NonFacilityObject  AuditObject (Ancestors – Abstract)
Attributes: ActivityDate (Date) – The date on which an activity for this
(name, type, length, particular feature/object occurred. This date does not necessarily
precision, scale,
domained, notes) 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.
Relationships: Activity<class name>Audit (core relationship type): Activity is 1:M
(cardinality, optionality, 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.
November 2010 114

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

Geometry:
Attributes: CompanyLabel (String, 45) – Additional label, acronym, or
(name, type, length, designation used for the company.
precision, scale,
domained, notes) 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
(cardinality, optionality, 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

Geometry:
Attributes: DocumentDescription (String, 120) – A textual description of the
(name, type, length, document.
precision, scale,
domained, notes) 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: ExternalDocumentGeoMetaData: ExternalDocument is 1:M with
(cardinality, optionality, GeoMetaData
<class name>AuditDocument (core relationship type): <class
name>Audit is M:N with ExternalDocument
ActivityExternalDocument (core): Activity is M:N with
ExternalDocument
November 2010 116

November 2010
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 Implemented as an Object class.
Geometry:
Inheritance: CenterlineObject (Ancestors – Abstract)
Attributes: LineName (String, 45) – Name of the pipeline.
(name, type, length, LineFunction (String, 50) clLinefunction -- designates current
precision, scale,
domained, notes) 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
(cardinality, optionality, 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.
November 2010 118

November 2010
Lineloops Transmission System Example – Physical View

a
B
Lineloops represent the primary method of organizing and locating features ACME Transmission PL
on or along the centerline of a pipeline system. A Lineloop represents one or (Logical) Lineloop #1
more Primary Reference Mode (PRM) StationSeries features connected from
end point to endpoint forming a single line or route without breaks. Lineloops C
are used to identify the pipelines of a system. Lineloops form the base unit for ACME 12" Main 10" Main B
analysis and reporting. No StationSeries feature can exist without belonging (Physical) Lineloop #2 (Physical)
to a LineLoop. Between the two classes the pipeline centerline is formed. Lineloop #5
Reference mode behavior, particularly in the instance of a centerline re-route,
is governed by the extent of an individual lineloop. 10" Lateral
(Physical)
There are two kinds of Lineloops as 10" Main A Lineloop #6
determined by the relationship between
[Object] the LineLoop object class and the
(Physical) Lineloop #4 D
StationSeries feature class. A
Logical – A Logical Lineloop has no (0) ACME 10" Main
AP DM Object related child StationSeries features. (Logical) Lineloop #3
Physical – A physical Lineloop has 1 or
EventID (pk) more related child StationSeries features a – This diagram represents the ACME Transmission Pipeline Company.
belonging to the PRM. 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
Each and every network) belongs to one or more logical line loops. And ultimately all
lineloops belong the the ‘ACME Transmission PL’ parent lineloop. The
[ObjectArchive] Lineloop may have
logical view is presented below.
one or more parent
Lineloops.
Each and every Transmission System Example – Logical View
CenterlineObject Lineloop may be the b
GroupEventID child of one or more

ACME Transmission PL
OperationalStatus <d> parent Lineloops.
ACME 12" Main has StationSeries
ACME 10" Main

LineLoop LineLoopHierarchy
10" Main A has StationSeries
LineName ParentLineLoopEventID (fk)
10" Main B has StationSeries
LineFunction <d> ChildLineLoopEventID (fk)
LineJurisdiction <d> 10" Lateral has StationSeries
b – This diagram represents the ACME Transmission Pipeline Company

showing the relationships between the LineLoop and the
The difference LineLoopHierarchy object classes. Each Lineloop exists as a record in the
between a physical Lineloop object class. For every parent-child relationship between
OwnerOperator Lineloops a record is placed in the LineLoopHierarchy object class. These
and logical Lineloop is
relationships are illustrated by the hierarchy view (above) and the pseudo-
based on the number tables showing each individual text line in the box as a record in the class.
StationSeries
of Primary Reference
Mode StationSeries Logical LineLoop
Product
features the Lineloop is Physical LineLoop
related to. Related StationSeries
LineLoopAudit
LineLoopEventID (fk) LineLoop LineLoopHierarchy
#1 - ACME Transmission PL ACME Transmission PL, ACME 12" Main
#2 - ACME 12" Main ACME Transmission PL, ACME 10" Main
#3 - ACME 10" Main ACME Pipeline System, 10" Lateral
#4 - 10" Main A ACME 10" Main, 10" Main A
#5 - 10" Main B ACME 10" Main, 10" Main B
#6 - 10" Lateral
Figure 23

November 2010
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
November 2010 120

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

Geometry:
Inheritance:
Attributes: ParentLineLoopEventID (GUID) - Foreign key to a parent
(name, type, length, LineLoop object.
precision, scale,
domained, notes) ChildLineLoopEventID (GUID) - Foreign key to a child LineLoop
object.
Relationships: LineLoopChildLineLoop (core): LineLoop is 1:M with
(cardinality, optionality, 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
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
November 2010 122

November 2010
pipelines. In this case, both connecting pipelines may be considered parents of the
interconnect line.
11.1.2.8 OwnerOperator
Class Name: OwnerOperator

Geometry:
Attributes: CompanyEventID (GUID) – Foreign key to the Company object
(name, type, length, class.
precision, scale,
domained, notes) 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’.
Relationships: LineLoopOwnerOperator (core): LineLoop is 1:M with
(cardinality, optionality, 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

Geometry:
Attributes: Product (String, 50) – clProduct (Default=Unknown) – Product
(name, type, length, type, e.g. ‘Oil’, ‘Natural Gas’
precision, scale,
domained, notes)
Relationships: LineLoopProduct (core): LineLoop is M:N with Product
(cardinality, optionality,

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

Geometry:
APDM ESRI Object  APDMObject  ObjectArchive 
Attributes: SiteName (String, 45) – The name of the site.
(name, type, length, SiteType (String, 50) opSiteType –The type of site contained within
precision, scale,
domained, notes) the boundary (e.g., meter station, compressor station)
Relationships: SiteAudit (core): Site is 1:M with SiteAudit
(cardinality, optionality, 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
November 2010 124

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

Geometry:
Attributes: SubSystemName (String, 45) – The name or label that identifies the
(name, type, length, subsystem.
precision, scale,
domained, notes)
Relationships: SubSystemChildSubSystem (core): SubSystem is 1:M with
(cardinality, optionality, 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
subsystems. As is the case with LineLoop, there is no distinction between physical and
logical subsystem records in the SubSystem table.
Subsystems Operations SubSystem Example

SubSystems represent an secondary method of organizing and locating
features on or along the centerline of a pipeline system. A Subsystem
Operating Divisions
ion #4 District 3
B
(Logical) SubSystem #2 vis m
represents an operationally significant area, boundary, unit or n Di Syste (Physical)
r b -9
jurisdiction that the pipeline centerline passes through. This area may a
ste Su
)
SubSystem #7
SSR -10
be demarcated by a polygonal boundary or a beginning and ending Ea gical SSR
o -6
stationed position along the centerline. SubSystems provide a s i on (L C SSRR-7
vi #3 SS
mechanism for sub-dividing the centerline into SubSystem ranges Di em
rn yst
(Centerline Polyline Events similar to Online Polylines). SubSystem ste ubS -5
ranges tie the Subsystem to the centerline by having a relationship with We ical) S SSR SS
(Lo
g -3
StationSeries which is related directly to a Lineloop. In this manner the SSRR-4 R-
8
intersection between SubSystems and Linelloops can be derived. SS
-1
SSRR-2 SS
There are two kinds of SubSystems SS R-
[Object] as determined by the relationship 11
D
between the SubSystem object class
and the SubSystemRange feature A District 2 District 4
class. District 1 (Physical) (Physical)
(Physical) SubSystem #5 SubSystem #6 SubSystem #8
AP DM Object Logical – A Logical SubSystem has
EventID (pk) no (0) related child SubSystemRange a – This diagram represents the ACME Transmission Pipeline Company and the
features. Operating Divisions and Districts that are used to organize the pipeline into
Physical – A physical SubSystem manageable units. The pipeline is divided into two divisions (Western and
has 1 or more related child Eastern). Each division is divided into two districts (District 1, 2 and District 3, 4
SubSystemRange features. respectively. The portion of the centerline that intersects the district boundaries is
used to create SubSystem range (SSR) CenterlinePolylineEvent features. The
Each and every logical view is presented below.
[ObjectArchive] SubSystem may

have one or more
parent Operations SubSystem Example – Logical View
SubSystems.
Each and every
b ACME Transmission PL
CenterlineObject SubSystem may
be the child of one Operating Divisions
OperationalStatus <d> or more parent
Western Division
SubSystem. Logical SubSystem
Physical SubSystem District #1

SubSystem Rnage
SSR1
SubSystem SubSystemHierarchy
SSR2
SubSystemName ParentSubSystemEventID (fk) b – This diagram represents the
District #2
ChildSubSystemEventID (fk) ACME Transmission Pipeline
Company showing the relationships SSR3
between the SubSystem and the
SubSystemHierarchy object Eastern Division SSR4
classes. Each SubSystem exists as
Contact a record in the SubSystem object District #3
class. For every parent-child SSR5
relationship between SubSystems
Site a record is placed in the SSR6
SubSystem object class. These
SSR7
relationships are illustrated by the
SubSystemAudit The difference between a
hierarchy view (above) and the SSR8
pseudo-tables (below) showing
SubSystemEventID (fk) physical and logical each individual line in the box as a District #4
SubSystem is based on the record in the class. Note also the
SSR9
number of color coding showing the
CenterlineP olylineEvent SubSystemRange features relationships between the Physical SSR10
SubSystems records and the
the SubSystem is related
related SubSystemRange features. SSR11
to.
Operations SubSystem Example – Physical View

SubSystemRange c
SubSystem SubSystemHierarchy SubSystemRange
SubSystemEventID (fk)
#1 - ACME Transmission PL ACME Transmission PL, Operating Divisions SubSystemRange-1
#2 - Operating Divisions ACME Transmission PL, Operating Divisions SubSystemRange-2
StationSeries #3 - Western Division Operating Divisions, Western Division SubSystemRange-3
#4 - Eastern Division Operating Divisions, Eastern Division SubSystemRange-4
#5 - District #1 Western Division, District #1 SubSystemRange-5
AltRefMeasure #6 - District #2 Western Division, District #2 SubSystemRange-6
#7 - District #3 Eastern Division, District #3 SubSystemRange-7
#8 - District #4 Eastern Division, District #4 SubSystemRange-8
SubSystemRange-9
SubSystemRange are located SubSystemRange-10
on the centerline as events or SubSystemRange-11
features and therefore must be
related to a Primary Reference c – This diagram shows the three SubSystem object/feature classes. Each SubSystem may
Mode StationSeries feature. 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.
November 2010 126

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

Geometry:
Inheritance:
Attributes: ParentSubSystemEventID (GUID) - Foreign key to a parent
(name, type, length, SubSystem object.
precision, scale,
domained, notes) ChildSubSystemEventID (GUID) - Foreign key to a child
SubSystem object.
Relationships: SubSystemChildSubSystem (core): SubSystem is 1:M with
(cardinality, optionality, 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
November 2010 128

November 2010
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
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 Implemented as an M-Aware (and optionally Z-Aware) Point
Geometry: Feature class.
APDM ESRI Feature  FeatureArchive  CenterlinePoint (Ancestors –
Inheritance: Abstract)
Attributes: ControlPointAngle (Double, 15, 2) – The magnitude of direction
(name, type, length, angle marking the change in vector direction (deflection) of the
precision, scale,
domained, notes) 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’).
Relationships: RouteControlPoint (core): StationSeries is 1:M with ControlPoint
(cardinality, optionality, SeriesControlPoint (core): StationSeries is 1:M with ControlPoint
ControlPointAudit (core): ControlPoint is 1:M with
ControlPointAudit.
GeoMetaData (core): ControlPoint is M:N with GeoMetaData.
November 2010 130

November 2010
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
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.
LineLoop Q1
Figure 27
Continuous Station Series A Changes from Version 4.0

0.0 10.0 20.0 40.0 50.0 60.0 to Version 5.0
Only a single set of control

25.0 35.0 points will be maintained in
APDM 5.0. In APDM 4.0 a
Continuous Control Points
complete set of control
0.0 10.0 20.0 40.0 50.0 60.0
points was maintained for
each station series feature.
APDM5.0 default
25.0 35.0
implementation requires a
‘continuous’ measure route
Engineering Station Series station series be present for
0.0 10.0 1 20.0 40.0 50.0 3 60.0 each physical LineLoop
20.0
0.0
object in the model. Each
vertex of the continuous
15.0 2 5.0 measure route station series
feature will have a control
Engineering Control Points point. The control point will
0.0 10.0 20.0 40.0 50.0 60.0 now contain the XYZ values
20.0
0.0 of the vertex and a foreign
key and measure field for
15.0 5.0 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
Resulting APDM Control Points of the second engineering
0.0,0.0 10.0,10.0 20.0,20.0 40.0,40.0 50.0,50.0 60.0,60.0 station series.
d h j
b c e i k
20.0,20.0 0.0,40.0
f g
15.0,25.0 5.0,35.0
November 2010 132

November 2010
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.
StationSeries and ControlPoint FeatureClasses

[Object] [Object]
OBJECTID OBJECTID
[Feature] [Feature]
Shape Shape
[FeatureArchive] [FeatureArchive]
GlobalID GlobalID
EventID (pk) EventID (pk)
CreatedBy CreatedBy
CreatedDate CreatedDate
EffectiveFromDate EffectiveFromDate
EffectiveToDate EffectiveToDate
LastModified LastModified
OriginEventID OriginEventID
Remarks Remarks
CenterlinePolyline CenterlinePoint
BeginMeasure OperationalStatus <d>
EndMeasure RouteEventID (fk)
BeginStation MeasureValue
EndStation SeriesEventID (fk)
OperationalStatus <d> StationValue
StationSeries Point_X
Point_Y
SeriesName
Point_Z
SeriesOrder
CLControl <d>
ParentStationSeriesEventID (sfk)
CLStationEditResponse <d>
CLXYEditResponse <d>
FromConnectionStationValue
CLZEditResponse <d>
FromSeriesEventID (sfk)
SymbolRotation
ToSeriesEventID (sfk) ControlPoint
RefMode <d> (fk)
ControlPointAngle
ControlPointType <d>
PIDirection <d>
ControlPoint
Lineloop
GeoMetaData
SubSystemRange
Figure 29

November 2010
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 Implemented as an M-Aware (and optionally Z-Aware) Polyline
APDM ESRI Feature  FeatureArchive  CenterlinePoint (Ancestors –
Inheritance: Abstract)
Attributes: LineLoopEventID (GUID) – The foreign key to a record in the
(name, type, length, LineLoop class. Each StationSeries feature must be associated
precision, scale,
domained, notes) 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.
Relationships: RouteControlPoint (core): StationSeries is 1:M with ControlPoint.
(cardinality, optionality, SeriesControlPoint (core): StationSeries is 1:M with ControlPoint.
LineLoopStationSeries (core): LineLoop is 1:M with StationSeries
November 2010 134

November 2010
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
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
November 2010 136

November 2010

APDM ESRI Feature  FeatureArchive  CenterlinePolyline 
Inheritance: CenterlinePolylineEvent (Ancestors – Abstract)
Attributes: SubSystemEventID (GUID) - Foreign key to a SubSystem object.
(name, type, length,
precision, scale,
domained, notes)
Relationships: SubSystemRange (core): SubSystem is 1:M with SubSystemRange
(cardinality, optionality, 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
EventID SubSystemEventID (Name)

1 4 (District 1) Table 11
2 4 (District 1)
3 5 (District 2) The SubSystemRange features from the two examples
4 5 (District 2) are recorded in the SubSystemRange feature table as
5 6 (District 3) follows (GUIDs are replaced with the integer IDs from
6 6 (District 3) the diagrams for clarity). SubSystemRange implements
7 6 (District 3)
8 7 (District 4)
a many-to-one relationship with SubSystem; each
9 7 (District 4) subsystem is comprised of one or more
10 7 (District 4) SubSystemRange feature. SubSystemRange implements
11 9 (Washington County) two many-to-one relationships with StationSeries; the
12 9 (Washington County) location and station values for each SubSystemRange
13 9 (Washington County) feature are constrained by the associated route or
14 9 (Washington County)
continuous station series and the interrupted
15 9 (Washington County)
16 10 (Jefferson County) engineering station series.
17 10 (Jefferson County)
18 10 (Jefferson County)

November 2010
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:
November 2010 138

November 2010
=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)
1 = Conceptual
2 = Proposed
4 = Active
8 = Inactive

November 2010
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 = 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
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
1 = Not Applicable
2 = Assigned
3 = Derived
4 = Interpolated
5 = Fixed
November 2010 140

November 2010
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 = 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 = 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

November 2010
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 = 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:
November 2010 142

November 2010
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 = 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:
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 = Yes
2 = No

November 2010
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
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.
November 2010 144

November 2010
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
• 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
• 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
• 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
• 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
November 2010 146

November 2010
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
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
November 2010 148

November 2010
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
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.
November 2010 150

November 2010
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
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)
November 2010 152

November 2010
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
• 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.
November 2010 154

November 2010
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 Implemented as a Point feature class.
Geometry:
APDM ESRI Object  Feature  Feature Archive  OfflineFacility 
Inheritance: OfflinePointFacility
Attributes: None.
(name, type,
length, precision,
scale, domain,
description)
Relationships: SitePoint: SitePoint is 1..1 with Site
(cardinality,
optionality,
attributes,
composite)
SubTypes: --
Notes: SitePoint is used to indicate the center point of a site.
13.1.2 SiteBoundary
Class Name: SiteBoundary

Feature Class Implemented as a Polygon feature class.
Geometry:
Inheritance: OfflineNonPointFacility
Attributes: None.
(name, type,
length, precision,

November 2010
scale, domain,
description)
Relationships: SiteBoundary: SiteBoundary is 1..1 with Site
(cardinality,
optionality,
attributes,
composite)
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 Implemented as an M-Aware Point feature class.
Geometry:
APDM ESRI Object  Feature  Feature Archive  OnlineFeature 
Inheritance: OnlineFacility  OnlinePointFacility
Attributes: AppurtenanceType (String, 50) fcAppurtenanceType – The
(name, type, appurtenance type (e.g., anchor rod, river weight).
length, precision,
scale, domain,
description)
Relationships: AppurtenanceAudit: Appurtenance is 1:M with AppurtenanceAudit
(cardinality,
optionality,
attributes,
composite)
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.
November 2010 156

November 2010
Geometry:
Inheritance: OnlineFacility  OnlinePolylineFacility
Attributes: CasingLength (Short Integer, 4) – The length of the casing unit
(name, type, along the pipeline.
length, precision, CrossingType (String, 50) fcCasingCrossingType – The type of line
scale, domain, crossing over the pipeline (e.g., road, railroad).
description) 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.
Relationships: CasingAudit: Casing is 1:M with CasingAudit
(cardinality,
optionality,
attributes,
composite)
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
Class Name: Closure

Geometry:
Inheritance: OnlineFacility  OnlinePointFacility  Fitting
Attributes: ClosureType (String, 50) fcClosureType – The type of closure
(name, type, (e.g., blind flange, hinged, plug).
length, precision, Specification (String, 50) fcSpecificationClosure -- The
scale, domain, specification the closure was manufactured to. The API, ANSI,
description) ASTM and other organizations all publish specifications.
Specification include characteristics like ovality, wall thickness
variation, test requirements, strength, etc. (e.g., ANSI, API 5).
Relationships: ClosureAudit: Closure is 1:M with ClosureAudit
(cardinality,
optionality,
attributes,
composite)
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

Geometry:
Attributes: CoatingCondition (String, 50) fcCoatingCondition – The last
(name, type, known condition of the coating (e.g., disbonded, intact).
length, precision, CoatingLength (Double, 15,2) – The length of the coating
scale, domain, application.
description) 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) –
November 2010 158

November 2010
Indicates if coating was applied to inside of pipe. The gnYesNo

domain is considered a ‘core’ APDM domain and must be
implemented verbatim.
Relationships: CoatingAudit: Coating is 1:M with CoatingAudit
(cardinality,
optionality,
attributes,
composite)
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

Geometry:
Attributes: ElbowAngle (Double, 15,2) gnAngle (required APDM domain) –
(name, type, The angle the elbow bends the pipeline (e.g., 30°, 45°). The
length, precision, gnAngle domain is considered a ‘core’ APDM domain and must
scale, domain, be implemented verbatim.
description) 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.
Relationships: ElbowAudit: Elbow is 1:M with ElbowAudit
(cardinality,
optionality,
attributes,
composite)
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
manufactured in angle increments of 15 degrees. Elbow features are designed to carry

pressurized product.
13.2.6 Instrument
Class Name: Instrument

Geometry:
Attributes: Manufacturer (String, 50) fcInstrumentManufacturer – The
(name, type, instrument manufacturer.
length, precision, Model (String, 50) instrUnknownModel – The instrument model
scale, domain, (model domain is dependent on instrument type).
description) SerialNumber (String, 30) – The instrument serial number.
DateManufactured (Date) – The date the instrument was
manufactured.
InstrumentName (String, 80) – The instrument name or description.
Relationships: InstrumentParameter: Instrument is 1:M with InstrumentParameter

(cardinality, InstrumentAudit: Instrument is 1:M with InstrumentAudit
optionality,
attributes,
composite)
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
November 2010 160

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

Geometry:
Attributes: MeterFunction (String, 50) fcMeterFunction – The main function
(name, type, the meter provides (e.g., check, custody transfer)
length, precision, MeterName (String, 30) – An organizational name or number
scale, domain, assigned to the meter.
description) 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
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
Relationships: MeterAudit: Meter is 1:M with MeterAudit

(cardinality,
optionality,
attributes,
composite)
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

Geometry:
Attributes: BarrelDiameter (String, 50) fcDiameter (required APDM domain) –
(name, type, The outer diameter of the barrel or pipe of the structure. The
length, precision, fcDiameter domain is considered a ‘core’ APDM domain and
scale, domain, must be implemented verbatim.
description) 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
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
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.
November 2010 162

November 2010
Relationships: PigStructureAudit: PigStructure is 1:M with PigStructureAudit

(cardinality,
optionality,
attributes,
composite)
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

Geometry:
Attributes: Insulated (String, 50) gnYesNo (required APDM domain) –
(name, type, Indicates if the join method is insulated (used to delineate
length, precision, cathodic projection zones). The gnYesNo domain is considered a
scale, domain, ‘core’ APDM domain and must be implemented verbatim.
description) 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
PressureRating (String, 50) fcPressureRating(required APDM
domain) – The pressure rating of the structure. The
fcPressureRating domain is considered a ‘core’ APDM domain
Relationships: PipeJoinMethodAudit: PipeJoinMethod is 1:M with

(cardinality, PipeJoinMethodAudit
optionality,
attributes,
composite)

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

Geometry:
Attributes: BendRadius (Double, 15,2) gnRadius – The radius from a
(name, type, centerpoint to the ends of the pipe segment.
length, precision, DateManufactured (Date) – The date the pipe segment was
scale, domain, originally manufactured.
description) 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
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
November 2010 164

November 2010
of the pipes that form the pipe segment.

material that pipes were constructed of (e.g., PVC, steel). The
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
OutletWallThickness (String, 50) fcWallThickness (required
APDM domain) – The outlet wall thickness of the pipe segment.
The fcWallThickness domain is considered a ‘core’ APDM
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
domain) – Indicates the operating pressure of the pipe segment.
The fcPressureRating domain is considered a ‘core’ APDM
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
Relationships: PipeSegment: PipeSegment is 1:M with PipeSegmentAudit
(cardinality,
optionality,
attributes,
composite)
SubTypes:

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

Geometry:
Attributes: OutletConnectionType (String, 50) fcConnectionType(required
(name, type, APDM domain) – The inlet connection type (e.g., weld, thread).
length, precision, The fcConnectionType domain is considered a ‘core’ APDM
scale, domain, domain and must be implemented verbatim.
description) 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.
Relationships: ReducerAudit: Reducer is 1:M with ReducerAudit
November 2010 166

November 2010
(cardinality,
optionality,
attributes,
composite)
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

Geometry:
Attributes: Grade (String, 50) fcGrade – The grade of the material from which
(name, type, the sleeve is constructed.
length, precision, NominalDiameter (String, 50) fcDiameter (required APDM
scale, domain, domain) – The nominal outside diameter of the sleeve. The
description) fcDiameter domain is considered a ‘core’ APDM domain and
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
Relationships: SleeveAudit: Sleeve is 1:M with SleeveAudit
(cardinality,
optionality,
attributes,
composite)
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
13.2.13 Tap
Class Name: Tap

Geometry:
Attributes: BranchConnectionType (String, 50) fcBranchConnectionType –
(name, type, Description of a reinforcing structure around the tap (e.g., saddle,
length, precision, full encirclement).
scale, domain, Capacity (Short Integer, 4) – A measure of the tap flow capacity
description) 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
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
material that the tap is constructed with (e.g., steel, PVC) . The
Metered (String, 50) gnYesNo (required APDM domain) –
Indicates if the tap contains a meter as part of the feature. The
domain) – The pressure rating of the tap. The fcPressureRating
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
TapType (String, 50) fcTapType– The function or style of the tap
November 2010 168

November 2010
(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: TapAudit: Tap is 1:M with TapAudit
(cardinality,
optionality,
attributes,
composite)
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

Geometry:
Attributes: BranchConnectionType (String, 50) fcConnectionType (required
(name, type, APDM domain) – The element used to connect the branch to the
length, precision, main pipe (e.g., weld, flange, thread). The fcConnectionType
scale, domain, domain is considered a ‘core’ APDM domain and must be
description) implemented verbatim.
BranchDiameter (String, 50) fcDiameter (required APDM domain)
– The outside diameter of the branch pipe. The fcDiameter
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
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
tee was manufactured to. The API, ANSI, ASTM and other
Relationships: TeeAudit: Tee is 1:M with TeeAudit
(cardinality,
optionality,
attributes,
composite)
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

Geometry:
Attributes: Automated (String, 50) gnYesNo (required APDM domain) –
(name, type, Indicates if the valve automatically opens or closes in certain
length, precision, circumstances. The gnYesNo domain is considered a ‘core’
scale, domain, APDM domain and must be implemented verbatim.
description) 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
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
PresentPosition (Long Integer, 9) gnPresentPosition– The current
November 2010 170

November 2010
position the valve is set at (Open/Closed).

PressureRating (Long Integer, 9) fcPressureRating (required APDM
domain) – The pressure rating of the valve. The fcPressureRating
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
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.
Relationships: ValveAudit: Valve is 1:M with ValveAudit
(cardinality, ValveGeoMetaData: Valve is M:N with GeoMetaData
optionality, ValveOperator: Valve is 1:M with ValveOperator
attributes,
composite)
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

Geometry:
APDM ESRI Object  APDM Object  Object Archive  FacilityObject
Inheritance:

November 2010
Attributes: OperatorType (String, 50) fcValveOperatorType– The operator

(name, type, used to open/close the valve (e.g., gas, manual, electric).
length, precision, ValveEventID (GUID) – Foreign key relate to EventID attribute in
scale, domain, the Valve feature class.
description)
Relationships: ValveOperator: ValveOperator is M:1 with Valve
(cardinality, ValveOperatorAudit: ValveOperator is 1:M with
optionality, ValveOperatorAudit
attributes,
composite)
SubTypes: --
The ValveOperator feature class describes a non-geometric object related to a particular

site.
13.2.17 Vessel
Class Name: Vessel

Geometry:
Attributes: Manufacturer (String, 50) fcFittingManufacturer (required APDM
(name, type, domain) – The manufacturer of the vessel. The
length, precision, fcFittingManufacturer domain is considered a ‘core’ APDM
scale, domain, domain and must be implemented verbatim.
description) 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).
Relationships: VesselAudit: Vessel is 1:M with VesselAudit
(cardinality,
optionality,
attributes,
composite)
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
November 2010 172

November 2010

Geometry:
Attributes: APINumber (String, 50) -- Well identifier assigned by API (ex: 42-
(name, type, 501-20130-03-00)
length, precision, CompletionDate (Date) -- Date on which drilling was completed.
scale, domain, GeologicFormation(String, 50) -- Name of target formation. (ex:
description) 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
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: WellAudit: Well is 1:M with WellAudit
(cardinality,
optionality,
attributes,
composite)
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

Geometry:
Inheritance: OnlinePoint
Attributes: FeatureElevation (Double, 15, 2) – Depth of a pipeline feature
(name, type, below ground surface.
length, precision, GroundElevation (Double, 15, 2) – Elevation of the ground at a

November 2010
scale, domain, specific location.

description) MeasurementDate (Date) – Date the elevation value was recorded.
WaterElevation (Double, 15, 2) – Depth of a pipeline feature below
water surface.
Relationships: ElevationPointAudit: ElevationPoint is 1:M with
(cardinality, ElevationPointAudit
optionality,
attributes,
composite)
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

Geometry:
APDM ESRI Object  Feature  Feature Archive  OfflineFeature 
Inheritance: OfflinePoint
Attributes: FieldNoteType (String, 50) opFNCultural – The type of field note
(name, type, (e.g., structure location, routing angle) based on the subtype of
length, precision, the field note.
scale, domain,
description)
Relationships: FieldNoteAudit: FieldNote is 1:M with FieldNoteAudit
(cardinality, FieldNoteGeoMetaData: FieldNote is M:N with GeoMetaData
optionality, FieldNoteLocation: FieldNote is 1:M with FieldNoteLocation
attributes,
composite)
SubTypes: 1 – Cultural Note
2 – Environmental Note
3 – Facility Note
4 – Geopolitical Note
5 – Hydrology Note
November 2010 174

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

Geometry:
Inheritance: OnlinePoint  OnlinePointForOfflineFeature
Attributes: FieldNoteEventID (GUID) – Foreign key relate to EventID
(name, type, attribute in the FieldNote feature class.
length, precision,
scale, domain,
description)
Relationships: FieldNoteLocation: FieldNoteLocation is M:1 with FieldNote
(cardinality,
optionality,
attributes,
composite)
SubTypes: --
13.3.4 Marker
Class Name: Marker

Geometry:
Attributes: MarkerNumber (String, 15) – An organizational name, code, or
(name, type, number identifying the marker.
length, precision, MarkerType (String, 50) opMarkerType – The type of marker –
scale, domain, mile post, aerial marker, above ground marker, monument,
description) survey point etc.

November 2010
Relationships: MarkerAudit: Marker is 1:M with MarkerAudit

(cardinality, MarkerLocation: Marker is 1:M with MarkerLocation
optionality,
attributes,
composite)
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

Geometry:
Attributes: MarkerEventID (GUID) – Foreign key relate to EventID attribute in
(name, type, the Marker feature class.
length, precision,
scale, domain,
description)
Relationships: MarkerLocation: MarkerLocation is M:1 with Marker
(cardinality,
optionality,
attributes,
composite)
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

Geometry:
November 2010 176

November 2010
Attributes: FieldNoteType (String, 50) opFNCultural – The type of field note
(name, type, (e.g., structure location, routing angle) based on the subtype of
length, precision, the field note.
scale, domain,
description)
Relationships: OnlineFieldNoteAudit: OnlineFieldNote is 1:M with
(cardinality, OnlineFieldNoteAudit
optionality,
attributes,
composite)
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

Geometry:
Inheritance: OnlinePolyline
Attributes: ActualPressure (Short Integer, 4) – The recorded or established
(name, type, pressure for a reach along a pipeline.
length, precision, AgreedToPressure (Short Integer, 4) – The agreed-to pressure
scale, domain, between client and customer for a reach of a pipeline.
description) 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
(cardinality, OperatingPressureAudit: OperatingPressure is 1:M with

optionality, OperatingPressureAudit
attributes,
composite)
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

Geometry:
Attributes: MinAdjustedPressure (Short Integer, 4) – The minimum adjusted
(name, type, pressure of the pressure test
length, precision, MinDesignPressure (Short Integer, 4) – The minimum design
scale, domain, pressure of the pressure test
description) PreTest (String, 50) gnYesNo (required APDM domain) – Indicates
if a pretest was conducted before the actual pressure test. The
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: PressureTestAudit: PressureTest is 1:M with PressureTestAudit

(cardinality,
November 2010 178

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

Geometry:
Attributes: EasementWidth (Double, 15,2) – The width of the easement to
(name, type, either side of the right-of-way feature
length, precision, ParcelNumber (String, 30) – Records the parcel identification
scale, domain, number the right-of-way feature passes through and can be used
description) 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
Relationships: RightOfWayContact: RightOfWay is M:N with Contact
(cardinality, RightOfWayAddress: RightOfWay is M:N with Address
optionality, RightOfWayAudit: RightOfWay is 1:M with RightOfWayAudit
attributes,
composite)
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
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

Geometry:
Inheritance: NonFacilityObject
Attributes: City (String, 45) – City name.
(name, type, County (String, 45) – County name.
length, precision, Country (String, 60) – Country name.
scale, domain, StateProvince (String, 45) – State or Province name.
description) 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.
Relationships: CompanyAddress: Address is M:N with Company
(cardinality, ContactAddress: Address is M:N with Contact
optionality, RightOfWayAddress: Address is M:N with RightOfWay
attributes, StructureOrIDSiteAddress: Address is M:N with
composite) 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

Geometry:
November 2010 180

November 2010
APDM ESRI Object  Feature  Feature Archive  OfflineFeature

Inheritance:
Attributes: SheetName (String, 45) – An organizational name or code that
(name, type, identifies the alignment sheet.
length, precision, SheetNumber (String, 45) – An organizational name, code, or alias
scale, domain, that identifies the alignment sheet.
description) SheetType (String, 50) – gnAlignmentSheetType – The type of
alignment sheet (e.g., engineering, new construction).
Relationships: --
(cardinality,
optionality,
attributes,
composite)
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

Geometry:
Attributes: ContactType (String, 50) gnContactType – Brief job
(name, type, description/organizational position of contact person.
length, precision, Email (String, 45) – E-mail address.
scale, domain, Fax (String, 45) – Fax number.
description) 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.
Relationships: ContactAddress: Contact is M:N with Address
(cardinality, LineCrossingContact: Contact is M:N with LineCrossing
optionality, StructureOrIdSiteContact: Contact is M:N with StructureOrIDSite
attributes, RightOfWayContact: Contact is M:N with RightOfWay

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

Geometry:
Attributes: DPName (String, 45) – A name, alias, or other identifier for the
(name, type, document point.
length, precision,
scale, domain,
description)
Relationships: DocumentPointExternalDoc: DocumentPoint is M:N with
(cardinality, ExternalDocument
optionality,
attributes,
composite)
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.
November 2010 182

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

Geometry:
Attributes: DateCollected (Date) – The date the original or previous point
(name, type, location was recorded.
length, precision, ExternalDocumentEventID (GUID) – Foreign key relationship to
scale, domain, the associated ExternalDocument.
description) 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: ExternalDocumentGeoMetaData: GeoMetaData is M:1 with
(cardinality, ExternalDocument
optionality, FieldNoteGeoMetaData: GeoMetaData is M:N with FieldNote
attributes, ValveGeoMetaData: GeoMetaData is M:N with Valve
composite) 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
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

Geometry:
APDM ESRI Object  APDMObject
Inheritance:
Attributes: InstrumentEventID (GUID) – Foreign key to the parent Instrument
(name, type, feature.
length, precision, ParameterType (String, 50) instrUnknownParameter – The
scale, domain, parameter type; dependent on the SubTypeCD Domain assigned
description) is the instr<SubtypeName>Parameter domain.
ParameterValue (String, 80) – The value of the parameter (number
values are stored as string).
Relationships: InstrumentParameter: InstrumentParameter is M:1 with Instrument
(cardinality,
optionality,
attributes,
composite)
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
November 2010 184

November 2010
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 Implemented as a Polyline feature class.
Geometry:
Inheritance:
Attributes: Attributes (String, 4000) – The concatenated name/value pairs of
(name, type, the removed features attributes
length, precision, BeginStationSeriesEventID (GUID) – Foreign key relationship with
scale, domain, BeginStationSeries attribute of the parent StationSeries.
description) 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.
Relationships: RemovedLineAudit: RemovedLine is 1:M with RemovedLineAudit

(cardinality, ClassMetaDataRemovedLine: RemovedLine is M:1 with
optionality, ClassMetaData
attributes,
composite)
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
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

Geometry:
Attributes: Attributes (String, 4000) – The concatenated name/value pairs of
(name, type, the removed features attributes.
length, precision, ClassEventID (GUID) – Foreign key relationship to the original
scale, domain, feature class for the removed feature.
description) 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.
Relationships: RemovedPointAudit: RemovedPoint is 1:M with
(cardinality, RemovedPointAudit
optionality, ClassMetaDataRemovedPoint: RemovedPoint is M:1 with
attributes, ClassMetaData
composite)
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
November 2010 186

November 2010
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
Regulatory Segments – HCA and DOT

HCA and DOT OnlineP olyline HCA Liquids
Class for Gas OnlineP olyline
HCASegment HCARange DOTClass

ActivityEventID (fk) ActivityEventID (fk) ActivityEventID(fk)
CouldAffectSegment
BIHOStructureCount AssessmentDate CalculatedLength
CalculatedLength RangeName ClassType <d>
DateCalculated RiskRanking ClassSource <d>
HCARangeEventID (fk) ClusterBufferEventID (fk) CASegmentsAudit
MAOP CorridorWidth
OutsideDiameter CorridorTolerance HCARangeEventID (fk)
PIRFactor RiskAnalysis DateCalculated
PIR IDSiteBufferRadius
PIRT Activity StructureOrIDSiteEventID OfflineFeature
Provenance <d> (fk)
SturctureOrSiteEventID (fk) HCARangeAudit A single structure
acting as an
HCARangeEventID (fk) Identified Site can
create an DOTClass
Segment
A single structure acting HighConsequenceArea

as an Identified Site can StructureOrIDSite Many
create an HCA Segment
Structures can AreaType <d>
create an
Many Structures can
create an HCASegment StructureOrIDSite DOTSegment ClassArea <d>
Activity HCARange
The aggregate segment derived from a rolled up set of
HCACLass segments.
HCASegmentAudit DOTClassAudit
AssessmentCalculated (Date) - Date the HCA analysis
HCASegmentEventID (fk) DOTClassEventID (fk) was performed.
RangeName (String) – A name or code assigned to the
APDM 4.0 has revised the schema for High Consequence Area and DOT Class analysis HCARange that is used in further analysis such as
for both gas and liquid transportation systems. The examples provided for gas are more Risk Assessment or mapping.
detailed than those for liquids. The biggest change from APDM 3.0-4.0 is the specification RiskRanking (Double) – An overall Risk Ranking
assigned to the HCARange.
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 DOTClass
Segments indicating the calculated or assigned Department of
cause HCASegments. The inclusion of the HCARange feature class allows Transportation Office of Pipeline Safety class
HCASegments to be aggregated or ‘rolling up’ to form HCARange segments which solely designations.
indicating areas of high consequence along the pipelne should a rupture occur.
ActivityEventID (GUID) – The EventID of the Activity Object
HCASegment representing the calculation or determination of DOT
Class.
A segment derived from some form of HCA calculation or assignment.
CalculatedLength (Double) – The 2D/3D length of the class
segment (in feet).
ActivityEventID (GUID) – The EventID of the Activity Object representing the calculation or
ClassType <Domain> (opDOTClassType) – The class
determination of HCA.
designation assigned to the class.
BIHOStructureCount (Long Int) - The number of structures (buildings intended for human occupancy)
ClassSource <Domain> (opDOTClassSource) – The
that created the individual HCA segment (optional).
methodology used to derive/assign the class type to the
CalculatedLength (Double) - Calcuated 2D/3D length of class segment in feet.
segment.
DateCalculated (Date) - Date the HCA analysis was performed.
ClusterBufferEventID (GUID) – Foreign key of the cluster
HCARangeEventID (GUID) – The foreign key to the HCARange online polyline feature class indicating
buffer that was used to create DOT Class III or IV
the rolled up HCA parent segment.
segments
MAOP (Double) - The MAOP of the original operating pressure or dynamically segmented feature used
CorridorWidth (Double) – The width of the corridor
to calculate the PIR.
surrounding the class (?).
OutsideDiameter <Domain> (fcOutsideDiameter) - The outside diameter of the original pipe or
CorridorTolerance (Double) – The tolerance used to extend the
dynamically segmented feature used to calculate the PIR.
corridor buffer.
PIR (Double) – The potential impact radius of the original segment.
DateCalculated (Date) – The date the class value was
PIRT (Double) - A tolerance factor to account for variation in spatial data accuracy of the features used
determined and assigned to the class segment.
to determine if a segment is HCA.
IDSiteBufferRadius (Double) – The buffer distance surrounding
Provenance <Domain> (opHCAProvenance) – The method used to assign/calculate the HCAClass
the IDSite causing Class II or IV.
segment.
StructureOrIDSiteEventID (GUID) – The EventID of the object
TotalPIR (double) - The total PIR (PIR+PIRT) for a HCAClass segment.
class containing the Structures that were the cause of a
StructureOrIDSiteEventID (GUID) – The EventID of the object class containing the Identified Sites that
created DOT segment (optional).
were the cause of a created HCA segment (optional).
HighConsequenceArea
CouldAffectSegments A polygonal area the if affected by a liquids spill will result in
The segments affected as the results of a liquid spill. 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.
Figure 31
November 2010 188

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

Geometry:
Inheritance:
Attributes: ActivityEventID (GUID) -- Foreign key to Activity object.
(name, type, BufferRadius (Double, 15,2) -- Radius of buffer used in clustered
length, precision, calculations of DOT Class
scale, domain, BufferTolerance (Double, 15,2) -- The + or - tolerance used in
description) determining the cluster radius.
Relationships: ClusterBufferAudit: ClusterBuffer is 1:M with ClusterBufferAudit

(cardinality,
optionality,
attributes,
composite)
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

Geometry:
Attributes:
(name, type,
length, precision,
scale, domain,
description)
Relationships: CouldAffectSegmentAudit: CouldAffectSegment is 1:M with
(cardinality, CouldAffectSegmentAudit
optionality,
attributes,
composite)
SubTypes: --

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

Geometry:
(name, type, CalculatedLength (Double, 15,2) – The 2D/3D length of the class
length, precision, segment (in feet).
scale, domain, ClassType (String, 50) opDOTClassType – The class designation
description) (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.
Relationships: StructuresDOTClassMN: StructureOrIDSite is M:N with
(cardinality, DOTClass
optionality, ClusterBufferDOTClass: ClusterBuffer is 1:M with DOTClass
attributes, IDSiteDOTClass1M: StructureOrIDSite is 1:M with DOTClass
composite) 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.
November 2010 190

November 2010
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 Implemented as a M-Aware Polygon feature class.
Geometry:
Inheritance:
(name, type, CorridorRadius (Double, 15,2) -- Radius of corridor used in
length, precision, calculations of DOT Class, usually 660 ft.
scale, domain, CorridorTolerance (Double, 15,2) -- The + or - tolerance used in
description) determining the corridor radius.
DOTCorridorType (String, 50) opDOTClassCorridorType --
Indicates if a corridor used in DOT Class determination is
continuous, or clustered.
Relationships: DOTClassCorridorAudit: DOTClassCorridor is 1:M with
(cardinality, DOTClassCorridorAudit
optionality,
attributes,
composite)
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

Geometry:
(name, type, BIHOStructureCount (Long Integer, 9) – The number of structures
length, precision, (intended for human occupancy) that created the individual HCA
scale, domain, segment (optional).
description) ClassLength (Double, 15,2) – The 2D/3D length of the class
segment (in feet).

November 2010
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.
Relationships: StructuresOrIDSiteDOTClassSgtMN: StructureOrIDSite is M:N
(cardinality, with DOTClassSegment
optionality, IDSiteDOTClassSegment1M: StructureOrIDSite is 1:M with
attributes, DOTClassSegment
composite) DOTClassSegmentDOTClass: DOTClassSegment is M:1 with
DOTClass.
DOTClassSegmentAudit: DOTClassSegment is 1:M with
DOTClassSegmentAudit
ClusterBufferDOTClassSgmnt: ClusterBuffer is 1:M with
DOTClassSegment
SubTypes: --
November 2010 192

November 2010
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 Implemented as a M-Aware Polygon feature class.
Geometry:
Inheritance:
(name, type, PIR (Double, 15,2) – the potential impact radius of the original
length, precision, segment.
scale, domain, PIRFactor(Double, 15,2) -- The natural gas energy factor used in
description) 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.
Relationships: HCACorridorAudit: HCACorridor is 1:M with HCACorridorAudit
(cardinality,
optionality,
attributes,
composite)
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

Geometry:
(name, type, AssessmentDate (Date) – The date the HCA analysis ws performed.
length, precision, RangeName (String, 255) – The name or code assigned to the
scale, domain, HCARange that is used in further analysis such as Risk
description) Assessment or mapping.
RiskRanking (Double, 15,2) – An overall Risk Ranking assigned to
the HCARange.

November 2010
Relationships: HCARangeSegment: HCARange is 1:M with HCASegment

(cardinality, HCARangeAudit: HCARange is 1:M with HCARangeAudit
optionality, HCARangeRiskAnalysis: HCARange is 1:M with RiskAnalysis
attributes,
composite)
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

Geometry:
(name, type, CalculatedLength (Double, 15,2) – The 2D/3D length of the class
length, precision, segment (in feet).
scale, domain, BIHOStructureCount (Long Integer, 9) – The number of structures
description) (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
November 2010 194

November 2010
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).
Relationships: StructuresHCASegmentMN: StructureOrIDSite is M:N with
(cardinality, HCASegment
optionality, IDSiteHCASegment1M: StructureOrIDSite is 1:M with
attributes, HCASegment
composite) 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.

13.5.9 HighConsequenceArea
Class Name: HighConsequenceArea

Geometry:
Inheritance:
Attributes: AreaType (String, 50) enHCAEncroachmentType – The type of
(name, type, area (e.g., navigable waterway, populated area).
length, precision, ClassArea (String, 50) enHCAClass – The automatic rating
scale, domain, assigned to the reach of pipeline that this area affects.
description)
Relationships: --
(cardinality,
optionality,
attributes,
composite)
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
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

Geometry:
Attributes: ConsequenceEconomic (Double, 15,2) – An assigned/calculated
(name, type, economic consequence rating.
length, precision, ConsequenceEnvironmental (Double, 15,2) – An
scale, domain, assigned/calculated loss-of-environmental consequence rating.
description) 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).
November 2010 196

November 2010
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: RiskAnalysisAudit: RiskAnalysis is 1:M with RiskAnalysisAudit
(cardinality, HCARangeRiskAnalysis: RiskAnalysis is M:1 with HCARange
optionality,
attributes,
composite)
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

Geometry:
Attributes: AnomalyClusterEventID (GUID) – Foreign key relationship with
(name, type, the associated AnomalyCluster.
length, precision, AnomalyType (String, 50) inAnomalyType– indicates the type of
scale, domain, anomaly found – corrosion, dent, gouge, crack etc.
description) 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
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
RPRVariance (Double, 15,2) gnPercentRange – Variance between
calculated rupture pressure ratios and rupture pressure ratios
Width (Double, 15,3) – The width of the anomaly.
Relationships: AnomalyCluster: Anomaly is M:1 with AnomalyCluster
(cardinality, InspectionRangeAnomaly: Anomaly is M:N with InspectionRange
optionality, AnomalyAudit: Anomaly is 1:M with AnomalyAudit
attributes,
composite)
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.
November 2010 198

November 2010
13.6.2 AnomalyCluster
Class Name: AnomalyCluster

Geometry:
Attributes: AnomalyType (String, 50) inAnomalyType – The type of anomaly
(name, type, cluster (e.g., dents, gouges, corrosion).
length, precision, AveBPRCalculated (Double, 15,2) gnPercentRange – Calculated
scale, domain, average anomaly burst pressure ratio.
description) 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: AnomalyCluster: AnomalyCluster is 1:M with Anomaly
(cardinality, AnomalyClusterAudit: AnomalyCluster is 1:M with
optionality, AnomalyClusterAudit
attributes,
composite)
SubTypes: --
The AnomalyCluster feature class contains mean (average) values for a set of anomaly
point features.

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

Geometry:
Attributes: InspectionDate (Date) – Date the inspection occurred.
(name, type, InspectionType (String, 50) inInspectionRangeType – Type of
length, precision, inspection performed – close interval survey, inline pig run,
scale, domain, casing survey, aerial survey etc..
description)
Relationships: InspectionRangeActivity: InspectionRange is M:N with Activity
(cardinality, InspectionRangeAnomaly: InspectionRange is M:N with Anomaly
optionality, InspectionRangeContact: InspectionRange is M:N with Contact
attributes, InspectionRangeAudit: InspectionRange is 1.M with
composite) 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

Geometry:
November 2010 200

November 2010
Attributes: DateRepaired (Date) – The date the leak was repaired.
(name, type, DateReported (Date) – The date the leak was discovered/reported.
length, precision, Depth (Double, 15, 3) – The depth of the leak below the surface of
scale, domain, the ground.
description) 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: LeakAudit: Leak is 1:M with LeakAudit
(cardinality,
optionality,
attributes,
composite)
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
Figure 32
The detailed architecture of the structure and identified site example classes are shown
below:
November 2010 202

November 2010
Structure and Identified Site Data Model

N onFacilityObject OfflineP oint OfflineFeature OnlineP ointForOfflineFeature
(Polygon)
StructureOrIDSite NearestPointToLine StructureOutline StructureLocation

Name StructureOrIDSiteEventID (fk) StructureOrIDSiteEventID (fk) StructureOrIDSiteEventID (fk)
IdentifiedSite <d> StructureOutlineEventID (fk) NearestPointToLineEventID (fk)
IdentifiedSiteType <d>
NumberOfStories Offline point
attached to outline
NumberOfUnits Nearest point to Stationed location
edge or corner
BIHO <d> line and identified Online location for used to locate
DaysPerWeek site points NPTL structure
WeeksPerYear or ID Site
OccupantCount
ImparedMobility <d>
A single structure acting as an Identified Site can create an HCA Segment HCASegment
Structure density can create an HCASegment
StructureStatus <d>
StructureOrIDSiteType <d> Many Structures can create an DOTSegment
DateAdded A single structure acting as an Identified Site can create an DOTClass Segment
HCASegment
SiteDescription
One structure may DOTClass

Address be represented by
the outline of one or
more IDSiteAreas Structure and Identified Sites are merged into
Contact a single object class. Feature classes DOTClass
In this case the value
for the attriibute containing geometric representations of
RegulatorySignificant
= Yes
structure locations, outlines, nearest point to
StructureAudit lines, identified site points and polygons are
enStructureOrIDSiteType
related to the StructureOrIDSite object class. Unknown-Verified
StructureOrIDSiteEventID (fk)
Many possible scenarios exist for modeling Unknown  Default
structures and identified sites for regulatory Apartment (Single Story)
OfflineFeature analysis and reporting purposes. NOTE: The
Apartment (Multi-Story)
Arena
subtypes for the original structure feature class Assembly Area
have been removed and a single domain Assisted Living
Barn
denoting structure and identified site has been Barracks
IDSiteArea created (Domain listing on right ) Beach
IDSiteEventID (fk) Business (Single)
Business (Multi-Story)
Campground
StructureOrIDSite – Object class representing a structure or identified site for which regulatory information is Cemetery
required. Church
IDSiteArea – A polygon indicating the boundary area of an identified site. Daycare Facility
NearestPointToLine – A point feature representing the nearest point to a line loop from a structure outline or Fire Station
the point representing an Identified Site. Garage
StructureOutline – An polygon representing the outline of a structure building (typically captured from aerial Golf Course
Hospital
photography) Hotel/Motel (Single-Story)
StructureLocation – A single online stationed point representing the location of the StructureOrIDSite or the Hotel/Motel (Multi-Story)
NearestPointToLine on the pipeline centerline. Industrial
Manufacturing
The following four scenarios are documented in the previous diagram and are described in detail here: Nursing Home
Outbuilding
Outdoor Theatre
Structure 1 – Has one StructureOrIDSite object record with four related StructureOutlines. One Park
StructureOutline is considered regulatory-significant. Two NearestToPoint features are created by placing the Parking Lot
‘Near’ points on the outline to each Lineloop that has one or more Primary Reference Mode (PRM) station Playground
series features. The lines drawn from the points are used to create three StructureLocations. Prison
Recreational Area
Structure 2 – Has one StructureOrIDSite object record with one related StructureOutline. Since only one Recreational Facility
Religious Facility
Lineloop containing PRM station series features is within proximity to the structure outline only a single Residence (Condominium)
NearestToPoint and StructureLocation point features are created. Residence (Duplex)
Residence (Single Family)
Structure 3 – One StructureOrIDSite object record with one NearestToPoint point representing the structure Residence (Trailer)
location. The NearestToPoint was not created from a StructureOutline boundary but was placed at a specific Residence (Multi-Unit Townhouse)
point. A resulting StructureLocation is calculated from the intersection fo the line traced from the Retirement Facility
School
NearestToPoint point to the lineloop. Either the NearestToPoint or the StructureLocation can be the first Shed
feature placed and from which the location of the other feature is derived. If the NearestToPoint is located from Stadium
the StructureLocation then the StationLocated attribute in the StructureLocation will be set to true indicating Structure BIHO
that the stationed position was the provenance for the location of the structure. Theme Park
Warehouse
Structure 4 – Has one StructureOrIDSite object record located by a single StructureLocation without a offline (Coded Value Domain – String)
feature.
Figure 33

November 2010
Detailed descriptions of the structure and identified site classes, and the line crossing
classes, follow.
13.7.1 StructureOrIDSite
Class Name: StructureOrIDSite

Geometry:
Attributes: BIHO (String, 50) gnYesNo (required APDM domain) – Indicates
(name, type, if the building is intended for human occupancy. The gnYesNo
length, precision, domain is considered a ‘core’ APDM domain and must be
scale, domain, implemented verbatim.
description) 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
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.
November 2010 204

November 2010
IdentifiedSiteType (String, 50) enIdentifiedSiteType --

Catagorization of structure or site for HCA determination. (ex:
Church, School)
Relationships: StructureOrIDSiteAddress: StructureOrIDSite is M:N with Address
(cardinality, StructureOrIDSiteContact: StructureOrIDSite is M:N with Contact
optionality, StructureOrIDSiteNPTL: StructureOrIDSite is 1:M with
attributes, NearestPointToLine (Optional Relationship)
composite) 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.


November 2010

13.7.2 NearestPointToLine
Class Name: NearestPointToLine

Geometry:
Attributes: StructureOrIDSiteEventID (GUID) – Foreign key relate to EventID
(name, type, attribute in the StructureOrIDSite feature class.
length, precision, StructureOutlineEventID (GUID) – Foreign key relate to EventID
scale, domain, attribute in the Structure feature class.
description)
Relationships: StructureOrIDSiteNPTL: NearestPointToLine is M:1 with
(cardinality, StructureOrIDSite (Optional Relationship)
optionality, StructureOutlineNPTL: NearestPointToLine is M:1 with
attributes, StructureOutline (Optional Relationship)
composite) 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

Geometry:
Inheritance:
Attributes: StructureOrIDSiteEventID (GUID) – The foreign key relationship
(name, type, to the StrucutureOrIDSite object.
November 2010 206

November 2010
length, precision,
scale, domain,
description)
Relationships: StructureOrIDSiteArea: StructureOrIDSite is 1:M with IDSiteArea
(cardinality,
optionality,
attributes,
composite)
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

Geometry:
length, precision, NearestPointToLineEventID (GUID) – Foreign key relate to the
scale, domain, EventID attribute in the NearestPointToLine feature class.
description)
Relationships: StructureOrIDSiteLocation: StructureLocation is M:1 with
(cardinality, StructureOrIDStie (Optional Relationship)
optionality, NPTLStructureLocation: StructureLocation is M:1 with
attributes, NearestPointToLine (Optional Relationship)
composite)
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

Geometry:

November 2010

Inheritance:
length, precision,
scale, domain,
description)
Relationships: StructureOutline: StructureOutline is M:1 with Structure (Optional
(cardinality, Relationship)
optionality, StructureOutlineNPTL: StructureOutline is 1:M with
attributes, StructureNPTL (Optional Relationship)
composite)
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

Geometry:
Inheritance:
Attributes: Clearance (Double, 15,2) – The distance of the line crossing above
(name, type, or below the pipeline at the point of crossing.
length, precision, CrossingType (String, 50) enLCGeography – The type of line
scale, domain, crossing based on the line crossing subtype (e.g., road, river).
description) 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).
Relationships: LineCrossingLocation: LineCrossing is 1:M with
(cardinality, LineCrossingLocation features.
optionality, LineCrossingEasement: LineCrossing is 1:M with
attributes, LineCrossingEasement features.
composite) 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)
November 2010 208

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

Geometry:
Inheritance: OnlinePolyline  OnlinePolylineForOfflineFeature
Attributes: LineCrossingEventID (GUID) – The foreign key to the
(name, type, LineCrossing feature
length, precision,
scale, domain,
description)
Relationships: LineCrossingEasement: LineCrossingEasement is M:1 with
(cardinality, LineCrossing
optionality,
attributes,
composite)
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

Geometry:

November 2010
Attributes: LineCrossingEventID (GUID) – The foreign key relationship to the

(name, type, LineCrossing feature.
length, precision,
scale, domain,
description)
Relationships: LineCrossingLocation: LineCrossingLocation is M:1 with
(cardinality, LineCrossing
optionality,
attributes,
composite)
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

Geometry:
Attributes: AnodeMaterial (String, 50) cpAnodeMaterial – The anode material
(name, type, (e.g., Magnesium, Zinc, Graphite, Steel Pipe)
length, precision, AnodeType (String, 50) cpAnodeType – The type of anode used
scale, domain, (e.g., Galvanic, Impressed Current)
description) AnodeWeight (String, 50) cpAnodeWeight – The weight of the
anode.
CPGroundBedEventID (GUID) – Foreign key relationship with the
EventID field of the GroundBed feature class.
Relationships: CPGroundBedCPAnode: CPAnode is M:1 with CPGroundBed
(cardinality, CPAnodeLocation: CPAnode is M:N with CPLocation
optionality, CPAnodeAudit: CPAnode is 1:M with CPAnodeAudit
attributes,
composite)
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
November 2010 210

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

Geometry:
Attributes: BondType (Long Integer, 9) cpBondType – The type of bond used
(name, type, (e.g., interference, continuity)
length, precision, CriticalBond (Long Integer, 9) gnYesNo (required APDM domain)
scale, domain, – Indicates whether or not the bond is critical. The gnYesNo
description) domain is considered a ‘core’ APDM domain and must be
Relationships: CPBondLocation: CPBond is 1:M with CPLocation
(cardinality, CPBondAudit: CPBond is 1:M with CPBondAudit
optionality,
attributes,
composite)
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

Geometry:
Attributes: CableCoating (String, 50) cpCableCoating – The coating material
(name, type, used on the cable (e.g., HMWPE, plastic).
length, precision, CableSize (String, 50) cpCableSize – The size of the cable
scale, domain, (e.g., 4/0, 2/0, 1, 10).
description) CableType (String, 50) cpCableType – The type of cable

November 2010
(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: CPCableLocation: CPCable is 1:M with CPLocation (Optional
(cardinality, Relationship)
optionality, CPCableAudit: CPCable is 1:M with CPCableAudit
attributes,
composite)
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

Geometry:
Attributes: AnodeSpacing (String, 50) cpAnodeSpacing – The measured
(name, type, spacing between anode in the ground bed.
length, precision, BackfillMaterial (String, 50) cpBackfillMaterial – The ground
scale, domain, material used to backfill the ground bed.
description) 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
Relationships: CPGroundBedCPAnode: CPGroundBed is 1:M with CPAnode
(cardinality, CPRectifierCPGroundBed: CPGroundBed is M:1 with CPRectifier
optionality, CPGroundBedLocation: CPGroundBed is 1:M with CPLocation
attributes, CPGroundBedAudit: CPGroundBed is 1:M with
composite) CPGroundBedAudit
November 2010 212

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

Geometry:
Attributes: ClassEventID (GUID) – The identifier for the feature that the
(name, type, online point location is representing. The class containing the
length, precision, feature is indicated by the SubTypeCD description value for the
scale, domain, class.
description) CPFeatureEventID (GUID) – A foreign key to any one of the
offline CP feature classes storing the EventID of the referenced
feature.
Relationships: CPAnodeLocation: CPLocation is M:N with CPAnode
(cardinality, CPBondLocation: CPLocation is M:1 with CPBond
optionality, CPCableLocation: CPLocation is M:1 with CPCable (Optional
attributes, Relationship)
composite) 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
13.8.6 CPRectifier
Class Name: CPRectifier

Geometry:
Attributes: Manufacturer (String, 50) cpRectifierManufacturer – The rectifier
(name, type, manufacturer.
length, precision, Model (String, 50) cpRectifierModel – The rectifier model type.
scale, domain, NumberOfNegatives (Long Integer, 9) cpRectifierNegatives – The
description) 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: CPRectifierCPGroundBed: CPRectifier is 1:M with CPGroundBed
(cardinality, CPRectifierLocation: CPRectifier is 1:M with CPLocation
optionality, CPRectifierAudit: CPRectifier is 1:M with CPRectifierAudit
attributes,
composite)
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.
November 2010 214

November 2010
13.8.7 CPTestStation
Class Name: CPTestStation

Geometry:
Attributes: TestStationType (String, 50) cpTestStationType – The type of test
(name, type, station (e.g., anode, single wire, bonded).
length, precision,
scale, domain,
description)
Relationships: CPTestStationLocation: CPTestStation is 1:M with CPLocation
(cardinality, CPTestStationAudit: CPTestStation is 1:M with
optionality, CPTestStationAudit
attributes,
composite)
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

Geometry:
Attributes: CompanyEventID (GUID) – The EventID of the Company that is
(name, type, doing the reading.
length, precision, ContactEventID (GUID) – The EventID of the person doing the
scale, domain, reading.
description) 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
ReadingValue (Double 15, 2) – The value taken from the reading.

Relationships: ContactCISReading: CISReading is M:1 with Contact
(cardinality, CompanyCISReading: CISReading is M:1 with Company
optionality, InspRangeAuditCISReading: CISReading is M:1 with
attributes, InspectonRangeAudit
composite)
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

Geometry:
Attributes: ContactEventID (GUID) – The EventID of the person doing the
(name, type, reading.
November 2010 216

November 2010
length, precision, CompanyEventID (GUID) – The EventID of the Company that is

scale, domain, doing the reading.
description) 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.
Relationships: ContactMeterReading: MeterReading is M:1 with Contact
(cardinality, CompanyMeterReading: MeterReading is M:1 with Company
optionality, MeterAuditMeterReading: MeterReading is M:1 with MeterAudit
attributes,
composite)
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
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 Implemented as an attributed many-to-many relationship class.
Geometry:
Attributes: <class name>EventID (GUID) – Foreign key to the <class name>
(Name, type, object/feature class storing the EventID of the object/feature with
length, precision, which this <class name>Contact record is associated.
scale, domain, ContactEventID (GUID) – Foreign key to the Contact object class.
notes) 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 Implemented as an attributed many-to-many relationship class.
Geometry:
Attributes: AddressEventID (GUID) – Foreign key to the Address object class.
(Name, type, ContactEventID (GUID) – Foreign key to the Contact object class.
length, precision, ContactType (String, 50) – (Default = 0) – gnContactType – Brief
scale, domain, job description/organizational position of contact person.
notes)
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
November 2010 218

November 2010
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
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.
November 2010 220

November 2010
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 Describe geometry as “Implemented as an M-Aware Polyline
Geometry: feature class” or “Implemented as an Object Class” or
“Implemented as an Object Class used to build ‘Event’ themes.
APDM List the APDM abstract and ESRI Core classes from which this
Inheritance: 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)
Attributes: Describe each attribute by name, type, (length, precision, scale, and
(name, type, domain name if applicable) and a description of the attribute
length, precision, including a reason why it was incorporated in the model.
scale, domain,
description) Example:
EventID (GUID) – A globally unique identifier for the class.

November 2010

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
Relationships: Describe the relationships this class has to other classes in the
(cardinality, model. The format for describing relationships is to list the name,
optionality, if the relationship is considered Core (and therefore must be
attributes, implemented), the origin class, the relationship cardinality and
composite) 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 Describe geometry as “Implemented as an M-Aware Polyline
Geometry: feature class” or “Implemented as an Object Class” or
“Implemented as an Object Class used to build ‘Event’ themes.
Implemented as an attributed many-to-many relationship class.

Attributes: Describe each attribute by name, type, (length, precision, scale, a
(Name, type, domain name if applicable) and a description of the attribute
length, precision, including a reason why it was incorporated in the model.
scale, domain,
notes) 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.
November 2010 222

November 2010
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
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
November 2010 224

November 2010
• 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
• 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
November 2010 226

November 2010
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
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
November 2010 228

November 2010
• 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
• 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:
November 2010 230

November 2010
• 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
• 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.
November 2010 232

November 2010
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
• 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:
November 2010 234

November 2010
• 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
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,
November 2010 236

November 2010
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
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
November 2010 238

November 2010
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
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
November 2010 240

November 2010
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
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.
November 2010 242

November 2010
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
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.
November 2010 244

November 2010
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
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.
November 2010 246

November 2010
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
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.
November 2010 248

November 2010
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
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
November 2010 250

November 2010
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
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
November 2010 252

November 2010
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
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.
November 2010 254

November 2010
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
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
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
corresponds to only one record in the second table.
November 2010 256

November 2010
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
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.
November 2010 258

November 2010
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
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.
November 2010 260

November 2010
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
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
November 2010 262

November 2010
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
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
November 2010 264

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

ArcGIS Pipeline Data Model. Version Reference Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ArcGIS Pipeline Data Model. Version Reference Guide

Uploaded by

Copyright:

Available Formats

ArcGIS® Pipeline Data Model

Version 5.0.1 – Reference Guide

APDM V5.0 Reference Guide

10.2.5.3 CenterlineObject ..................................................................................... 45

ESRI Technical Paper iii

11.1.2.3 <class name>Audit ............................................................................... 114

13.1.1 SitePoint ................................................................................................... 155

ESRI Technical Paper v

13.5.3 DOTClass ................................................................................................. 190

A.4.1 Object or Feature Class ................................................................. 221

ESRI Technical Paper vii

B.2.3.1 Well ........................................................................................................ 235

November 2010 viii

ESRI Technical Paper ix

Table 7 ............................................................................................................................ 104

A byproduct of encapsulating behavior is the concept and rule of APDM compliance. As

APDM V5.0 Reference Guide 1

Another question common to operators considering adoption of the APDM is whether

Submitted on behalf of the APDM Standing Committee.

The APDM is designed to store information found in gathering and transmission

APDM V5.0 Reference Guide

2.0 What Is the APDM?

APDM V5.0 Reference Guide

3.0 Why Use the APDM?

3.1 The Business Case

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

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

Improvement Act of 2002 resulted in amendments to CFR Title 49 § 192 Subpart O –

Operational Complexity – As technology and business management practices evolve,

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

APDM V5.0 Reference Guide

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

In response to above challenges, many operators are focusing on a strategy of operational

APDM V5.0 Reference Guide

Reduced software development / software purchase expenditures – Spatially enabling a

To equal out-of-the-box APDM geodatabase functionality requires excessive investment

3.2 The Technical Case

ESRI geodatabase technology is still relatively new compared to traditional RDBMS

APDM V5.0 Reference Guide

editing via topology; geoprocessing; raster-based spatial analysis; geo-statistical analysis;

4.0 History of the APDM

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

5.0 APDM Standing Committee

APDM V5.0 Reference Guide

• ESRI Petroleum User Group Meeting (Spring)

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

• GITA Oil and Gas Conference (Fall)

• Robert Brook (ESRI Pipeline Industry Manager) rbrook@esri.com

7.0 Difference Between a Standard and a Template

8.0 Design Rationale – The Geodatabase

APDM V5.0 Reference Guide

9.0 Core Elements

9.1 Stationing and Station Equations

APDM V5.0 Reference Guide

• Despite the recent mainstream introduction of GIS systems to the pipeline

• It is cumbersome to repeatedly enter 15+ digit coordinate values to locate

• Linear referencing and dynamic segmentation of spatially coincident linear

• Stationing is the only mathematical mechanism to systematically account for any

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

• Continuous – Stationing starts at a set value and continuously and cumulatively

APDM V5.0 Reference Guide

9.1.2 Arbitrary (Pseudo-distance Based)