ArcGIS® Pipeline Data Model
Version 4.0 - Core
Abstract and Core Classes
An ESRI ® Technical Paper • May 2007
ESRI 380 New York St., Redlands, CA 92373-8100, USA • TEL 909-793-2853 • FAX 909-793-5953 • E-MAIL [email protected] • WEB www.esri.com
May 2007
Copyright © 2007 ESRI
All rights reserved.
Printed in the United States of America.
The information contained in this document is the exclusive property of ESRI. This work is protected
under United States copyright law and other international copyright treaties and conventions. No part of
this work may be reproduced or transmitted in any form or by any means, electronic or mechanical,
including photocopying and recording, or by any information storage or retrieval system, except as
expressly permitted in writing by ESRI. All requests should be sent to Attention: Contracts Manager,
ESRI, 380 New York Street, Redlands, CA 92373-8100, USA.
The information contained in this document is subject to change without notice.
U.S. GOVERNMENT RESTRICTED/LIMITED RIGHTS
Any software, documentation, and/or data delivered hereunder is subject to the terms of the License
Agreement. In no event shall the U.S. Government acquire greater than RESTRICTED/LIMITED
RIGHTS. At a minimum, use, duplication, or disclosure by the U.S. Government is subject to restrictions
as set forth in FAR §52.227-14 Alternates I, II, and III (JUN 1987); FAR §52.227-19 (JUN 1987) and/or
FAR §12.211/12.212 (Commercial technical Data/Computer Software); and DFARS §252.227-7015 (NOV
1995) (technical Data) and/or DFARS §227.7202 (Computer Software), as applicable.
Contractor/Manufacturer is ESRI, 380 New York Street, Redlands, CA 92373-8100, USA.
ESRI, the ESRI globe logo, ArcCatalog, ArcGIS, ArcIMS, ArcMap, ArcObjects, ArcPad,
ArcSDE, ArcToolbox, www.esri.com, and @esri.com are trademarks, registered
trademarks, or service marks of ESRI in the United States, the European Community, or
certain other jurisdictions. Other companies and products mentioned herein are
trademarks or registered trademarks of their respective trademark owners.
May 2007
ArcGIS Pipeline Data Model
Version 4.0
Abstract and Core Classes
An ESRI Technical Paper
Contents
Page
Forward ....................................................................................................... 1
Executive Summary ...................................................................................... 3
1.0 Introduction............................................................................................ 5
2.0 What Is the APDM? ................................................................................. 5
3.0 Why Use the APDM?................................................................................ 6
3.1 The Business Case................................................................................ 6
3.2 The Technical Case............................................................................. 10
4.0 History of the APDM .............................................................................. 12
5.0 APDM Steering Committee ..................................................................... 13
6.0 APDM Technical Committee.................................................................... 13
7.0 Difference Between a Standard and a Template....................................... 14
8.0 Design Rationale ................................................................................... 14
9.0 Core Elements ...................................................................................... 15
9.1 Stationing and Station Equations ......................................................... 16
9.1.1 Distance Based ............................................................................. 18
9.1.2 Arbitrary (Pseudo-distance Based).................................................. 18
9.2 The Centerline (Routes, Measures, and Events) .................................... 19
9.3 Hierarchy........................................................................................... 20
9.4 Coincident Geometry .......................................................................... 21
9.5 Events Versus Features ....................................................................... 21
10.0 APDM Conceptual Model ...................................................................... 22
10.1 APDM Abstract Classes/Metadata Overview......................................... 23
10.2 APDM Abstract Classes...................................................................... 23
10.2.1 What is an abstract class?............................................................ 24
10.2.2 Why are abstract classes used? .................................................... 24
10.2.3 Duplication of Attributes within APDM abstract classes ................... 25
10.2.4 Inheritance (How to read the APDM Logical Model Poster).............. 26
10.2.5 Abstract Class Definitions............................................................. 30
10.2.5.1 APDMObject .......................................................................................... 33
10.2.5.2 ObjectArchive ......................................................................................... 33
10.2.5.3 CenterlineObject ..................................................................................... 35
ESRI Technical Paper
i
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Contents
Page
10.2.5.4 NonFacilityObject................................................................................... 36
10.2.5.5 FacilityObject.......................................................................................... 37
10.2.5.6 FeatureArchive........................................................................................ 38
10.2.5.7 CenterlinePolyline................................................................................... 40
10.2.5.8 CenterlinePolylineEvent ......................................................................... 41
10.2.5.9 CenterlinePoint ....................................................................................... 42
10.2.5.10 OfflineFeature ....................................................................................... 43
10.2.5.11 OfflinePoint........................................................................................... 44
10.2.5.12 OfflineFacility....................................................................................... 45
10.2.5.13 OfflineNonPointFacility ....................................................................... 46
10.2.5.14 OfflinePointFacility .............................................................................. 47
10.2.5.15 OnlineFeature........................................................................................ 48
10.2.5.16 OnlinePolyline ...................................................................................... 49
10.2.5.17 OnlinePolylineForOfflineFeature ......................................................... 50
10.2.5.18 OnlinePoint ........................................................................................... 52
10.2.5.19 OnlinePointForOfflineFeature .............................................................. 53
10.2.5.20 OnlineFacility ....................................................................................... 54
10.2.5.21 OnlinePolylineFacility .......................................................................... 55
10.2.5.22 OnlinePointFacility ............................................................................... 56
10.2.5.23 Fitting.................................................................................................... 56
10.3 APDM Metadata................................................................................ 57
10.3.1 Class-level Metadata.................................................................... 58
10.3.1.1 ReferenceMode ....................................................................................... 58
10.3.1.2 APDMClass ............................................................................................ 67
10.3.1.3 OnlineLocationClass............................................................................... 68
10.3.2 Feature-level Metadata ................................................................ 77
10.3.2.1 Online Event Feature-Level Metadata Attributes ................................... 78
10.3.2.2 ControlPoint Feature-Level Metadata Attributes.................................... 82
10.4 APDM Core Classes and Relationships................................................. 89
10.4.1 EventID...................................................................................... 94
10.4.2 Core Object Classes..................................................................... 94
10.4.2.1 Activity ................................................................................................... 94
10.4.2.2 ActivityHierarchy ................................................................................... 95
10.4.2.3 AltRefMeasure........................................................................................ 97
10.4.2.4 <class name>Audit ................................................................................. 98
10.4.2.5 Company ............................................................................................... 100
10.4.2.6 ExternalDocument ................................................................................ 101
10.4.2.7 LineLoop............................................................................................... 102
10.4.2.8 LineLoopHierarchy............................................................................... 106
10.4.2.9 OwnerOperator ..................................................................................... 108
10.4.2.10 Product ................................................................................................ 108
10.4.2.11 SubSystem........................................................................................... 109
May 2007
ii
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Contents
Page
10.4.2.12 SubSystemHierarchy........................................................................... 112
10.4.3 Core Feature Classes ..................................................................114
10.4.3.1 ControlPoint.......................................................................................... 114
10.4.3.2 Site ........................................................................................................ 116
10.4.3.3 StationSeries ......................................................................................... 117
10.4.3.4 SubSystemRange .................................................................................. 119
10.5 APDM Core Domains ........................................................................121
10.5.1 Required Domains ......................................................................122
10.5.1.1 gnOperationalStatus.............................................................................. 122
10.5.1.2 gnStatus................................................................................................. 122
10.5.1.3 clStationEditResponse .......................................................................... 123
10.5.1.4 clXYEditResponse................................................................................ 123
10.5.1.5 clZEditResponse ................................................................................... 123
10.5.1.6 gnOnlineLocationMechanism............................................................... 124
10.5.1.7 gnHistoricalState................................................................................... 124
10.5.1.8 gnAngle................................................................................................. 124
10.5.1.9 clEditResponse...................................................................................... 125
10.5.1.10 gnAPDMClassType ............................................................................ 125
10.5.1.11 gnRefModeBasis................................................................................. 126
10.5.1.12 gnRefModeType ................................................................................. 126
10.5.1.13 gnRefModeUnits................................................................................. 126
10.5.1.14 gnYesNo ............................................................................................. 127
10.5.1.15 gnRequiresGeometry .......................................................................... 127
10.5.2 APDM Compliance .........................................................................127
10.5.3 Non Geometric Features ................................................................129
10.5.4 Topology......................................................................................134
10.5.5 Centerline ....................................................................................134
10.5.6 Structure......................................................................................136
11.0 Implementation Issues .......................................................................136
11.1 The APDM and ‘Inline’ History...........................................................136
11.1.1 Inline History Implementation .....................................................138
11.2 Using the APDM in a Versioned Geodatabase Environment ..................141
11.3 Features as Events, Events as Features .............................................142
11.4 Topology and the Geometric Network................................................142
11.5 Developing Applications ...................................................................143
11.6 The APDM and Other Pipeline Data Models ........................................144
11.7 Conversion To/From PODS and ISAT .................................................145
11.8 Getting Data into the Model..............................................................145
12.0 Model Future......................................................................................146
Appendix A - Standards and Conventions.....................................................147
Naming Conventions ...............................................................................147
Class Names ........................................................................................147
ESRI Technical Paper
iii
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Contents
Page
Foreign Keys ........................................................................................148
Use of Feature Datasets ..........................................................................148
Maximum String Size ...............................................................................149
Documentation Standards........................................................................149
Object or Feature Class.........................................................................149
Attributed Relationship Class .................................................................150
Appendix B - Glossary ................................................................................152
A ...........................................................................................................152
B ...........................................................................................................153
C ...........................................................................................................154
D ...........................................................................................................157
E ...........................................................................................................159
F ...........................................................................................................160
G ...........................................................................................................161
H ...........................................................................................................163
I ............................................................................................................163
J............................................................................................................164
K ...........................................................................................................165
L............................................................................................................165
M...........................................................................................................167
N ...........................................................................................................168
O ...........................................................................................................168
P ...........................................................................................................171
Q ...........................................................................................................173
R ...........................................................................................................173
S ...........................................................................................................175
T ...........................................................................................................177
U ...........................................................................................................178
V ...........................................................................................................178
W ..........................................................................................................178
X ...........................................................................................................179
Y ...........................................................................................................179
Z ...........................................................................................................179
Appendix 3 – APDM 3.0 to APDM 4.0 Conversion Utility Script .......................180
Disclaimer ..............................................................................................180
ConvertAPDM3to4 ...................................................................................182
May 2007
iv
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Forward
It has always been the intent of the ArcGIS Pipeline Data Model (APDM) Technical
Committee to keep pace with the technology released by Environmental Systems
Research Institute (ESRI). One of the primary purposes of the APDM is to explore how
ESRI technology can be best utilized for the pipeline industry. Every year ESRI unfolds
new approaches to spatial analysis, new data structures, and new desktop and server
tools. These new capabilities impact the APDM in wonderful and challenging ways. The
question often arises “When will the APDM become stable?” The uniform response is “It
is stable, but it will always evolve.”
It is fair to say that the APDM Version 4.0 represents a significant step forward from the
APDM Version 3.0. The APDM Version 1.0 strove to capture the salient information
about the pipeline world. Version 2.0 sought to define the APDM as a customizable
template that could be extended to meet end user needs, and Version 3.0 sought to refine
the information captured in the previous two releases and align it with the ArcGIS 9.0
technology offered by ESRI. The focus of Version 4.0 has been to define, capture and
store the ‘behavior’ of pipeline systems, particularly that of reference modes (stationing)
and response to ‘centerline’ editing. In addition, Version 4.0 is designed to take
advantage of ArcGIS 9.2 technology.
A byproduct of encapsulating behavior is the concept and rule of APDM compliance. As
more operators adopt the APDM and more vendors develop applications for the APDM,
the need for ‘interoperability’ becomes paramount. Interoperability can be loosely
defined as ‘the exchange of and description of data, schema and behavior between
different implementations, and within a single APDM implementation.’ A requirement
for ‘interoperability’ is ‘compliance’ to the rules of the APDM. What was called the
‘core’ in the APDM 3.0 is still the ‘core’ in the APDM 4.0. Core refers to those schema
items that are required. What were called the ‘conceptual’ classes in the APDM 3.0 are
now referred to as ‘abstract’ classes in the APDM 4.0. The abstract classes denote the set
of ‘required’ attributes, domains and relationships that make an APDM 4.0 model
compliant. The APDM 4.0 abstract classes are expanded and refined in comparison to
Version 3.0.
The whitepaper, the logical model diagram and the physical Unified Modeling Language
(UML) model have all been re-worked to consistently reflect the ‘compliance’ structure
within the APDM. If all feature and object classes within a particular APDM
implementation properly inherit from the APDM abstract classes and metadata structures,
then the implementation is considered compliant. Compliant APDM implementations
facilitate data sharing and easier application development since the root behavior is now
defined within the model. Essentially, the APDM Version 4.0 still adheres to the
principal that an end user editing and updating features within an APDM geodatabase can
do so using out-of-the-box ESRI software tools.
ESRI Technical Paper
1
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Another question common to operators considering adoption of the APDM is whether
any one vendor ‘owns’ the APDM and controls it. The answer to this question is “Yes,
ESRI owns the APDM.” However, while ESRI owns the APDM, control of the APDM
rests with the pipeline industry at large via the APDM Steering and Technical
committees. ESRI does not consider itself a standards body, nor does the APDM consider
itself a ‘standard’ data model.
The APDM is available on the web for free to all ESRI users (www.apdm.net). The
model is open to everyone, even to competing interests. The APDM is founded on the
supposition that an open and free model, supported by the volunteer efforts of ESRI
pipeline users, will confer lasting benefits on the entire ESRI pipeline community. The
goal of the APDM is to publish a data model that can be used to facilitate consensus and
interaction between various pipeline interests working with ESRI technology. The
APDM is a template-based model (just like every other model available from ESRI) that
works on a common ‘abstract’ model that can be expanded to suit the needs of any
pipeline operation. This allows operators to create value-added data model
implementations that can support the tools and applications specific to their organization,
and yet still remain APDM compliant.
Lastly, you will soon discover the APDM is rife with its own peculiar, pipeline-specific
terminology and nomenclature. Every effort has been made to present the material in a
readable and understandable fashion. This document contains a wealth of information
describing the structure, content and semantic behavior of the APDM. Please let us know
if the material requires revision or clarification.
Submitted on behalf of the APDM Technical and Steering Committees.
May, 2007
May 2007
2
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Executive Summary
Today’s pipeline operating environment is more demanding than ever. In order to be
successful, pipeline companies must not only provide a competitive return on investment
to shareholders, but also ensure healthy relationships with other stakeholders including
regulatory agencies, the public at large, emergency responders, environmental interest
groups, customers and suppliers. In response to these pressures, many operators are
focusing on a strategy of operational excellence. Operational excellence implies an
effective infrastructure for knowledge and data management, data analysis, and reporting.
For many pipeline companies, a deployment of ESRI’s Geographic Information System
(GIS) technology utilizing the ArcGIS Pipeline Data Model (APDM) can provide a
superior platform for data management. Superior data management results in improved
pipeline integrity management, together with attendant improvements in productivity,
cost reduction and cost avoidance.
The APDM is designed to store information found in gathering and transmission
pipelines, particularly gas and liquid systems. The APDM is expressly designed for
implementation as an object-relational ESRI geodatabase for use with ESRI's ArcGIS®
and ArcSDE® products. The APDM is the only pipeline data model designed to take full
advantage of ESRI’s advanced GIS spatial data management and analysis technology.
Unlike other available pipeline data models, the APDM can only be implemented with
ESRI geodatabase technology.
The APDM is intended to be a flexible data model template that any pipeline company
can readily modify to suit its own needs. Companies with existing relational databases
may choose to migrate to the APDM to take advantage of the ESRI geodatabase data
management environment. Such companies are expected to extensively modify the
APDM template to conform the APDM to the requirements of their existing data stores.
For companies without an existing data model, the APDM ships with a variety of
optional, example classes (analogous to relational database tables) which can be used to
store many types of pipeline information.
All of the features in the APDM can be organized into one of three categories: 1)
Abstract classes, 2) Core classes, and 3) Optional Classes. The abstract classes define the
framework of the APDM; all other classes in the APDM inherit properties, relationships
and behaviors from one of the APDM abstract classes. The APDM abstract classes are
required elements of the model. The core classes are those object, feature and relationship
classes, together with associated domains, that are required to maintain APDM
compliance. The core classes define the APDM centerline features, stationing attributes,
and supporting model elements. The optional classes are defined in a separate document
(ArcGIS Pipeline Data Model Version 4.0 Optional Classes). The optional classes are
included as implementation examples, but none of them are required elements of the
model. The optional classes are included to provide a starting template for companies
with no existing pipeline data model.
ESRI Technical Paper
3
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
The APDM was initiated in 2002. The intellectual property of the APDM is owned by
ESRI. Ongoing maintenance and enhancement of the content and structure of the APDM
is governed by and performed by the elected members of the pipeline industry managed
APDM Steering and Technical committees, respectively.
May 2007
4
May 2007
ArcGIS Pipeline Data Model Version 4.0
Abstract & Core Classes
1.0 Introduction
This technical paper explains the ArcGIS Pipeline Data Model (APDM) and is intended
for those interested in implementing a transmission pipeline geodatabase using ESRI®
ArcGIS® software. The document is written for pipeline GIS professionals, company
managers, developers, and graphic system operators. It provides a detailed description of
the objects in the model, how the model is organized, and suggestions on how the model
can be implemented within an organization. The document assumes that the reader has a
working knowledge of common pipeline terminology and pipeline-specific GIS terms,
such as stationing, centerline, station series, and control points, and a working knowledge
of ESRI linear referencing technology. A glossary is provided to explain terms pertinent
to the APDM. This document concentrates on the abstract and core classes of the APDM;
the optional classes that are distributed as implementation examples are discussed in a
separate document, ArcGIS Pipeline Data Model Version 4.0 Optional Classes.
2.0 What Is the APDM?
The ArcGIS Pipeline Data Model is designed for storing information pertaining to
gathering and transmission pipelines, particularly gas and liquid systems. The APDM
was expressly designed for implementation as an ESRI geodatabase for use with ESRI's
ArcGIS and ArcSDE® products. A geodatabase is an object-relational construct for
storing and managing geographic data as features within an industry-standard relational
database management system (RDBMS).
The APDM is developed and governed by Steering and Technical Committees under the
umbrella of ESRI. The Steering and Technical committees include representatives from
pipeline and pipeline vendor companies. ESRI helps facilitate the development and use of
the APDM to serve the needs of their client base. While ESRI owns the APDM, control
of the APDM is vested in the user community. The APDM model and supporting
documentation is freely available and accessible to everyone via the web at
www.apdm.net.
ESRI does not consider itself a standards body; therefore, in keeping with the spirit of
other published ESRI models, the APDM is not intended to be a comprehensive or all
encompassing model. Rather, the APDM is designed to be a starting template of core
elements from which a pipeline company can craft a model tailored to its business needs
by adding features or refining existing features within the rules defined by the APDM
template. A primary objective of the model is to account for linear referencing of features
(stationing). Most transmission pipeline companies refer to the location of features or
ESRI Technical Paper
5
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
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-ofthe-box ESRI technology referred to as routes and measures.
The APDM is designed as a starting point. It is neither the purpose nor the focus of the
APDM technical committee to design a model that is a comprehensive description of all
possible features found in a pipeline system. Nor is it the intention of the model to
prescribe a rigorous methodology or standard approach to modeling pipeline systems.
The model’s intent is to provide a set of core objects and attributes that describe and
effectively handle stationing, plus a core set of abstract classes by which most, if not all,
pipeline features can be categorized. The purpose behind providing a core set of features
is to provide pipeline and vendor companies with a consistent framework for developing
applications against the model, and for data transfer between existing databases. By this
approach, any pipeline company can add features to the model, modify existing features
in the model, or subtract features from the model as required by business needs. The core
elements of the model remain a small subset of the features found in the model. Any new
features added must fall into one of the abstract APDM classes including referenced and
non-referenced features, and online and offline features. Another focus of the APDM is
to develop a model that end users can implement and add data to without the need for
custom code or development efforts. This is achieved by using core ESRI technology that
allows any pipeline company to develop a tailored data model that meets its business
needs while maintining compatibility with ESRI tools.
3.0 Why Use the APDM?
A variety of factors are driving pipeline operators towards more advanced and effective
pipeline data management tools; these business drivers provide the ultimate impetus for a
pipeline company to adopt ESRI geodatabase technology and the APDM. Of course,
there are other options besides ESRI geodatabase technology and the APDM for
managing pipeline data, but an APDM geodatabase implementation offers several
advantages over available alternatives in terms of efficiency, effectiveness, reliability,
cost, and capability. The business and technical cases for the APDM are outlined below.
3.1 The Business Case
The pipeline operating environment is more demanding than ever. In order to be
successful, pipeline companies must not only provide a competitive Return on Investment
(ROI) to shareholders, but also ensure healthy relationships with other stakeholders
including regulatory agencies, the public at large, emergency responders, environmental
interest groups, customers and suppliers. Any successful pipeline company must develop
effective strategies for dealing with the following challenges:
Profitability – The ultimate goal of a pipeline operator is to achieve maximum
profitability while maintaining safe and reliable system that meets or exceeds industry
and regulatory standards.
May 2007
6
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Regulatory Pressure – In the wake of tragic accidents such as the Bellingham, WA
incident of 1999, public outcry elicited a response from the federal government in the
form of increasingly demanding and prescriptive regulations. The Pipeline Safety
Improvement Act of 2002 resulted in amendments to CFR Title 49 § 192 Subpart O –
Pipeline Integrity Management, and CFR Title 49 § 195 Subpart F – Operations &
Maintenance (§ 195.450 High Consequence Areas, and § 195.452 Pipeline Integrity
Management) for interstate gas and liquids transmission pipeline operators, respectively.
These new regulations require operators to develop an unprecedented level of knowledge
regarding their pipelines and environments in which they operate in order to create highly
detailed pipeline Integrity Management Programs (IMP’s). Annual audits performed by
the Pipeline and Hazardous Materials Safety Administration’s (PHMSA) Office of
Pipeline Safety (OPS) under the auspices of the U.S. Department of Transportation
(DOT) are designed to enforce regulatory compliance. Failure to comply can result in
spectacular fines and disruption of business operations; this makes the IMP a critical
element of any pipeline company’s profitability strategy. Effective integrity management
also implies optimized availability of pipeline assets for operations resulting in increased
revenue and increased opportunities for operational cost reduction through improved
operational efficiency and reliability.
Operational Complexity – As technology and business management practices evolve,
organizations such as pipeline companies are becoming increasingly complex in nature.
Increasingly the activities of a business unit are dependent upon and/or affect the
activities of other units. For example, Control Centers interact with Engineering
departments to design and monitor line pressures, likewise relying on Emergency
Response and Environmental groups to respond to incidents, further demanding a tight
integration with frontline Field and ROW personnel to execute on site activities. Almost
every activity within a pipeline organization requires coordination across multiple
business units. This evolving complexity presents challenges and opportunities for cost
reduction by increasing efficiency and greater output through discovering and realizing
synergies.
Aging Infrastructure – Much of the nation’s pipeline infrastructure is approaching the
latter stages of its original designed service life. Successful management of aged
pipelines requires extraordinary diligence and attention to detail. Modern inline
inspection, direct assessment, and close interval survey methods are all critical elements
of an effective Baseline Assessment Plan (BAP) and ongoing mitigation plans, but these
tools and processes all produce tremendous volumes of information. Failure to effectively
manage and analyze this information leads to inefficient or even fatally flawed mitigation
plans. Thus, effective data analysis and management is key to service reliability,
operational cost reduction and cost avoidance strategies.
Suburban expansion – Formerly rural pipeline Rights Of Way (ROW) are being
increasingly encroached on by suburbia. This trend can dramatically increase One Call
ESRI Technical Paper
7
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
response and public notification burdens, potential for third party damage, complexity of
risk analysis, and the financial, operational, litigable and regulatory consequences of an
unintended product release. Effective strategies for dealing with suburban encroachment
are a critical aspect of any pipeline company’s cost optimization strategy.
Mergers, Acquisitions & Restructuring – As pipeline systems change hands, many
companies find themselves faced with the tasks of integrating staffs, business processes
and workflows, and data management systems. Failure to do so results in increased
operating costs through staff inefficiency, and increased regulatory exposure.
‘Graying’ of the Workforce – For many pipeline companies, much of the corporate
knowledge base is stored in the brains of senior staff. As these employees retire, critical
knowledge is irretrievably lost. Whenever such knowledge is lost, unnecessary cost is
incurred to reproduce it. In some cases the consequences of lost knowledge can be dire
from both an operational and financial standpoint. Thus, an effective knowledge and data
management infrastructure becomes an important cost reduction and cost avoidance tool.
In response to above challenges, many operators are focusing on a strategy of operational
excellence achieved through the incorporation of new technology and processes to
integrate and optimize the organization. In the Information Age, operational excellence
implies an effective infrastructure for knowledge and data management, data analysis and
reporting. Increasingly, operators are realizing that the traditional hardcopy-based or
CAD-based data management environment is simply not up to the task. Indeed, for some
of the more prescriptive regulations such as gas or liquids High Consequence Area
(HCA) analysis, a GIS-based platform is practically required. As discussed below, ESRI
geodatabase technology and the APDM provide a superior foundation for data and
knowledge management.
For pipeline operators, an effectively implemented data management system based on the
APDM can becomes an integral part of the operations and asset management framework.
Effective implementation enables increased productivity, cost reduction and cost
avoidance. Increased productivity is achieved through optimized maintenance planning
and execution with reduced downtime, resulting in greater output and increased available
capacity for operations. Cost reduction is achieved through increased staff and
operational efficiency and reductions in rework and unnecessary work. Cost avoidance is
improved through increased operational safety and reliability, and through reductions in
regulatory fines, unfavorable litigation judgments, and ultimately, avoidance of consent
decrees and corrective actions.
An effective data management platform such as APDM can reduce the time it takes to
perform tasks such as data maintenance and integration, freeing company personnel to
spend more time on critical functions such as analysis of and response to information.
More time is available for preventive maintenance activities, project planning and
oversight, and other work in need of completion. Likewise, by automating traditionally
May 2007
8
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
manual and inefficient functions, overtime can be reduced and in some cases, headcount
can be reduced as well, thereby reducing operating costs. For example, the APDM
enables deployment of advanced mobile electronic field data collection and
communication. In many cases, the conversion from paper forms to electronic data
capture can result in a 20-40% reduction in time spent on a given activity by field
inspectors and technicians. For a full time inspector paid $50K per year, the net savings
can range from $10-20K per inspector. Based on the size of the organization, this alone
can amount to significant savings when implemented throughout the company.
Other expenses typically reduced with implementation of the APDM include the
reduction and in many cases elimination of time spent integrating disparate data sets and
the time and cost to create and update maps and drawings. Further, advanced data
integration and analysis is enabled and can be used to justify project deferrals or even
avoidance. For example, the integration and assessment of Close Interval Survey (CIS)
data combined with InLine Inspection (ILI) data can be used to develop engineered
criteria for adequate cathodic protection levels, which many times justifies the deferral of
projects such as Cathodic Protection (CP) installations, excavations and rehabilitation
projects. It should not be unexpected that a mature implementation of an enterprise data
management system based on the APDM can reduce pipeline maintenance costs by as
much as 5-10%. For a pipeline company with an annual maintenance budget of $20 MM,
this can result in savings in excess of $1MM per year. Eventually, the extension of the
system to facilities and tank farms may further extend the ability to reduce operating
expenses.
A significant benefit from any solution is the ability for it to lead to increased revenues.
In the case of the APDM, it is a platform that when implemented effectively will lead to
better informed decision making, faster data collection, communication and processing
and rapid response to identified needs. New capabilities can enable the monitoring of
anomalies versus shutdown and excavation, the optimization of maintenance planning
and scheduling to reduce unnecessary work and the better coordination of needed work.
Over time, it should be expected that an enterprise-wide improvement in information
management, communication and decision making will lead to improvements in capacity
availability and utilization of anywhere from 2-10%. Conservatively speaking, if
available capacity can be increased by 1% on a gasoline system that on average transports
1MM barrels per day at a revenue of 1$ per barrel, then increased revenue could amount
to on average over $10,000 per day.
Increased productivity, cost reduction and cost avoidance are important factors in
improving ROI, but ROI is only one part of a balanced scorecard. Many pipeline
companies are focused on being excellent corporate citizens. An effective platform based
on the APDM can become an important tool for maintaining a positive image and good
relationships with all of the pipeline’s important stakeholders: regulatory agencies, the
public, emergency responders, environmental groups, customers and suppliers.
ESRI Technical Paper
9
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Many of the cost justifications developed above for an APDM implementation can be
equally applied to an effective, spatially enabled implementation of a relational pipeline
database such as Integrated Spatial Analysis Techniques (ISAT), Pipeline Open Data
Standard (PODS), or Industry Standard for Pipeline Data Management (ISPDM).
However, the APDM and ESRI geodatbase technology offers additional cost benefits
over these relational technology alternatives.
Reduced ‘entry cost’ – For smaller operators, the APDM can be implemented in a
personal, file or workgroup geodatabase, eliminating the need for enteprise RDBMS
software such as Oracle or SQL Server, together with attendant Database Adminstrator
(DBA) and System Adminstrator (SA) personnel costs. To spatially enable a relational
pipeline database, an enterprise RDBMS is effectively required. Thus, for smaller
operators, significant support staff headcount reduction and software capital expenditure
savings can be achieved with an APDM implementation relative to a relational pipeline
database implementation.
Reduced software development / software purchase expenditures – Spatially enabling a
relational pipeline database with ESRI technology calls for the use of extended stored
procedures (utilizing ArcObjects or ArcSDE C API coding in the case of ArcSDE),
database triggers and/or scheduled services to synchronize the database with the GIS.
Also, relational pipeline databases have no built-in capability for long transaction
management, or history management. Such funcitionality is not included out-of-the-box
with any of the relational pipeline models, and therefore must either be developed inhouse 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 databasedriven data management system is required. Several database-driven data management
May 2007
10
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
options are currently available to pipeline operators: 1) a pure relational database
implementation using ISAT, PODS, ISPDM, or a proprietary model, 2) a spatially
enabled implementation of one or the aforementioned relational models using GIS
technology, and 3) a pure ESRI geodatabase implementation utilizing the APDM.
ESRI geodatabase technology is still relatively new compared to traditional RDBMS
technology. SQL access to a versioned geodatabase is somewhat complicated, and SQL
edit capability is somewhat limited. Some feel that geodatabase implementations are
more difficult to integrate with existing relational enterprise databases than an equivalent
relational database implementation. The prime consideration in determining whether to
select the APDM in lieu of a standard or GIS-enabled relational database model is this:
Do the benefits of ESRI geodatabase technology– analytical, cartographic, and editing
functionality– override the need to integrate the database with other enterprise relational
applications and data access technologies? The primary advantage of the geodatabase
over a relational model is summarized by the following observations:
•
•
The RDBMS enforces referential data integrity, but not spatial data integrity.
The geodatabase enforces both referential and spatial data integrity.
The RDBMS cannot easily enforce the link between feature geometry and attribute data.
To use a GIS with relational pipeline data models such as ISAT or PODS, the GIS is
typically ‘grafted’ on to the relational model. When ESRI technology is used to spatially
enable a relational ISAT or PODS database, spatial information is usually stored twice:
once in the relational coordinate tables present in these models, and again in ArcSDE
layers or feature classes derived from the relational coordinate tables. Editing operations
in the RDBMS require application logic to drive updates of relational database attributes,
which in turn are followed by feature geometry updates (or the reverse). Data
synchronization is a constant, error-prone, time-consuming, costly and troublesome issue
for spatially enabled relational pipeline data models: feature geometries in ArcSDE are
typically snapshots derived from the database; each time the database is modified, the
feature geometries are potentially out of date and must be rebuilt.
The geodatabase seamlessly enforces the linkage between feature geometry and attribute
data; in addition, it allows the construction of more complex relationships that simplify
and streamline editing operations. Because of this, an APDM geodatabase
implementation avoids the problems with spatial data updates and synchronization that
are typical of a GIS-enabled relational model. The geodatabase (and the APDM) offers
less expensive data maintenance for interrelated spatial features and attributes as a
function of the underlying data structure. As a result, the reliance on data integrity logic
built into custom applications is minimized. Ultimately, these advantages result in lower
data maintenance costs and greater data reliability.
Utilizing a geodatabase for storage of GIS data provides end user access to all the
powerful ESRI GIS analytical technology. While a spatially enabled relational database
ESRI Technical Paper
11
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
implementation can take advantage of some of ESRI’s advanced GIS capabilities, the
same cannot be said for a pure relational implementation, and neither can take full
advantage of ESRI technology like a geodatabase. Compelling technology included in the
geodatabase includes multi-user, long transaction versioned editing; coincident feature
editing via topology; geoprocessing; raster-based spatial analysis; geo-statistical analysis;
state-of-the-art map display/cartographic production tools; 3D Visualization using
ArcGIS Explorer®; integration with the Web via ArcIMS® and ArcGIS Server®;
disconnected editing via Tablet PC and handheld personal digital assistants (PDAs)
running ArcPad®; and dynamic annotation. All of these factors combine to make an
APDM geodatabase implementation more efficient, more reliable and less costly than a
relational database implementation.
Other ESRI data models could potentially be applied to pipeline; the ESRI Gas
Distribution Model is one potential candidate. The APDM is designed for pipeline
companies whose primary means of locating features is by linear referencing (or
stationing). Ultimately, the ability to locate, edit, analyze, and organize features on or
along a pipeline via stationing is what differentiates the APDM from the standard ESRI
Gas Distribution Model. The APDM is developed for ESRI enterprise software
ArcGIS/ArcSDE technology, which is entirely predicated on the geodatabase. The
APDM returns lower cost, more effective, efficient and reliable data creation and
management, and superior data analysis. All of these elements are important to the highly
regulated and important transmission pipeline industry.
4.0 History of the APDM
The APDM is developed and maintained jointly by the ESRI APDM steering and
technical committees. The technical committee is responsible for developing the
structure, content, and technological aspects of the model. The steering committee is
responsible for the organizational/promotional aspects of the model. Ultimately both
committees fall under the umbrella of the ESRI Petroleum User Group. The core
elements of the APDM embody many of the same concepts found in the ISAT, PODS,
and ISPDM models. Every attempt is made to make the APDM open to data transfer
between each model. The steering and technical committees strive to balance the interests
of each pipeline model group, the pipeline companies, and the pipeline vendor
community. Participation in both committees is divided between operator and vendor
communities, and ISAT/PODS data model members. Below is a brief chronology of the
model's development:
•
•
•
March 2002 – M.J. Harden starts the initial work on the model.
July 2002 – The model is presented at the ESRI User Conference in San Diego,
California. An open invitation to participate in the design of the model is extended
to the pipeline community.
August 2002 – The initial meeting of interested member groups occurs at ESRI,
Redlands, California.
May 2007
12
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
•
•
•
•
•
•
•
•
•
•
•
October 2002 – The steering and technical committees are officially formed at
the ESRI Electric/Gas Utility User Group Conference (EGUG), Coeur d'Alene,
Idaho.
December 2002–June 2003 – Monthly technical and steering committee
meetings occur at various member organizations. Development of the intellectual
property agreement, steering committee charter, technical committee mandate,
operational procedures, and APDM content and structure proceed.
March 2003 – The APDM is released for public comment at the ESRI Petroleum
Users Group (PUG) meeting in Houston, Texas.
July 2003 – Version 1 of the APDM is officially released at the ESRI
International User Conference in San Diego, California.
October 2003 – The model is reviewed and Version 2 is proposed by the APDM
technical committee at the ESRI EGUG Conference in Galveston, Texas.
August 2004 – The model is reviewed and Version 3 is released by the APDM
technical committee at the first APDM Pre-conference workshop at the 24th
annual ESRI International User Conference in San Diego, California.
March 2005 – The model is reviewed and Version 4 is proposed by the APDM
technical committee at the ESRI PUG meeting in Houston, Texas.
July 2005 – The second annual APDM pre-conference workshop held at the 25th
annual ESRI International User Conference in San Diego, California.
June 2006 – The model is reviewed and Version 4 is released for review by the
APDM technical committee via the APDM web site (www.apdm.net).
September 2006 – Work begins on APDM v5.0.
May 2007 – The final draft of APDM v4.0 is released via the APDM web site
(www.apdm.net).
Active members of the Pipeline Interest Group (PIG) elect the members of the APDM
steering and technical committees. Elections occur at the annual PUG meetings (March
of each year). Steering committee terms are one year in length; technical committee terms
are two years in length.
5.0 APDM Steering Committee
A ten (10) person committee is charged with setting the organizational direction of the
APDM within the context of the pipeline industry. The Steering Committee meets once
per month via phone conference on the second Wednesday of the month. Craig Wilder
([email protected]) is the current chairperson of the APDM Steering Committee.
6.0 APDM Technical Committee
A ten (10) person committee charged with developing the technical content of the APDM
model. The technical committee meets three times per year during the ESRI Petroleum
User Group Conference (PUG) in February/March, the annual ESRI User Conference
held in July/August and the GITA Oil & Gas Conference (September). Technical
committee meetings are open to anyone interested in furthering the model. However, only
ESRI Technical Paper
13
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
the technical committee members are allowed to vote on changes to the APDM. Peter
Veenstra ([email protected]) is the current chairperson of the APDM Technical
Committee.
7.0 Difference Between a Standard and a Template
The APDM is intended to be a template, not a standard. There is no governing
organization that has officially approved the APDM as a standard. The features and
relationships included in the model are deemed critical or common to 80 percent of all
pipeline companies' typical implementations of geographic information system
technology. The APDM, similar to most other published models on the ESRI Web site,
represents core features found in almost every pipeline system. The intent of the model is
not to create a database standard, but rather to create a database template from which
custom models can be created and evolved. However, one of the design criteria of the
model is to create and delineate core elements that must be maintained in order to
preserve a standard for data transfer, application development, and conversion efforts
between APDM implementations.
8.0 Design Rationale
The APDM is a geodatabase model developed for managing transmission and gathering
(gas and liquid) pipelines. This section outlines the design rationale considered at every
stage in development of the APDM. These justifications served as guidelines for ensuring
the model meets the needs of the pipeline industry. Each justification describes some of
the considerations and background material measured and weighed to determine the final
model.
This section is divided into the following parts, each of which describes the driving
forces behind how the APDM was developed.
•
•
•
•
•
•
Core Elements
Stationing and Station Equations
The Centerline (Routes, Measures, and Events)
Hierarchy
Coincident Geometry
Events Versus Features
Later sections of this document describe in more detail the content and structure of the
APDM. It is important to realize that no single pipeline data model can do everything for
all organizations. Realizing the variation in how data is modeled between different
pipeline companies, the technical committee developed the APDM according to four
guiding principles:
1. The APDM is designed to provide a set of core elements that remain consistent
for any APDM implementation. The core elements are designed to ease data
May 2007
14
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
transfer between existing pipeline data models and for the development of
portable APDM applications by third party vendors.
2. The APDM provides a mechanism for locating features on or along the pipeline
centerline by both absolute positioning and by linear referencing (commonly
referred to as stationing). It is not the purpose of the APDM to prescribe the
approach to implementation for the model. These features can exist as geometric
features in feature classes, dynamic events in event tables, or a combination of
both.
3. Features (or tables or objects) are included in the APDM if they are required by
80 percent of all pipeline companies and by the United States government
regulatory agencies.1
4. The APDM can be implemented and maintained within a geodatabase without the
need for custom application code.
9.0 Core Elements
The prime object of the technical committee is to promulgate a small, well-defined set of
core objects with required attributes. These core elements provide the mechanism for
linear referencing to locate events as geometric features or dynamic events. The core also
provides a foundation from which other features can be added to the model, or from
which existing features in the model can be customized as required (provided that the
core elements remain intact and immutable). The core elements are required for
maintenance of the centerline and stationing. The core elements are classified into a set of
conceptual features (abstract classes) that provide an aid to determining how additional
model elements can be classified and organized within the APDM.
If the core objects (tables, feature classes) and attributes are immutable, then the
remainder of the geodatabase is optional and totally customizable. The feature classes,
other than the core feature classes, that are distributed with the model provide examples
of the most common features, rather than being an all-inclusive description of every
possible feature found on or along a pipeline system. The purpose of the APDM is to
allow pipeline companies to build geodatabases to suit their business needs. The core
elements of the model provide a standard set of features– the rest is up to the end user.
Users may pick and choose which elements to include, which to remove, and which to
alter to suit their needs. Other than the core elements of the model, it is up to the user to
determine what is or is not included in the model.
1
The APDM technical committee is aware the APDM will be implemented in international settings. Every attempt is made to avoid an American-centric view of the model. It is
the carefully weighed opinion of the committee that transmission pipeline regulations in the United States are some of the most rigorous in the world. Many of the companies
participating in the development of the model have holdings and operations outside of the United States and are consulted during model development to facilitate the requirements
of the international pipeline community.
ESRI Technical Paper
15
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
The amount of data that pipeline companies are able to access has exponentially
increased within the last decade. In the historical paper world it was conceivable to
manage thousands of features. With the advent of faster computers, better integration
between disparate systems, and the proliferation of readily available digital data in a wide
variety of formats, the potential for the management of millions, if not billions, of
features is quite conceivable for many large pipeline companies. By keeping a small core
of required elements, the APDM is very open and flexible to integration with larger
corporate or enterprise data systems. In this manner, the APDM can be implemented as
the front door to the enterprise repository of data. By spatially modeling a detailed, rich
set of features, the GIS can be seen as an extension of the entire enterprise data
warehouse.
9.1 Stationing and Station Equations
Traditionally, the location of pipeline features on a pipeline was determined by station
series and station value. A station series is a linear path representing a portion of the
centerline of the pipeline or the route that the pipeline follows across the surface of the
earth. The cumulative measure of 'stationing values' from the start of the station series to
the terminus of the station series is called station position. An infinite number of events
can be located along a station series representing the location of a feature, or the start and
end of a linear feature.
At each point along the station series (including the start and endpoints) where the
centerline bends either horizontally or vertically, a control point is placed. Control points
are known points of stationing (measured distance along the station series) and have
known coordinate values. Each control point forms the vertex of a station series linear
feature. Each station series is thus composed of two or more known points of stationing.
Stationing monotonically increases or decreases without gaps from the begin point to the
endpoint of a station series. Once stationing is assigned to the centerline, the stationing
values for known points along the centerline usually do not change. When the pipeline is
first built, the stationing measurements are uninterrupted and continuous along the length
of the entire pipeline. When a pipeline is rerouted (i.e. the path of the centerline is
altered), discontinuities are introduced into the stationing. The points of the breaks in
stationing are known as station equations. Once an equation is introduced into the
centerline, the stationing is altered for the portion of the centerline that has been rerouted
with the addition of a new station series.
Any event occurring between two control points has a station value calculated by the
interpolation of station values of the known control points on either side of the event.
Traditional GIS implementations store point, linear, and polygon features by absolute
coordinates for each vertex of the feature. Using stationing (linear referencing or relative
positioning), a dynamic method for determining the location of a feature (or event) is
available. The ESRI geodatabase supports both of these methods. Once the location of a
feature is determined using either absolute or relative positioning, the alternative
positioning values can be determined (provided an underlying centerline of station series
May 2007
16
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
features is available). It is important to realize that the ArcGIS Pipeline Data Model puts
more emphasis on absolute rather than relative positioning. If the underlying control
point and station series network is highly representative of the underlying terrain, with
accurate positioning in sufficient density, then the calculation of relative position is easily
obtained once the station values of known control points are determined and quantified.
However, display performance for large numbers of dynamically positioned features is
usually less than optimal.
Transmission pipeline stationing systems have been historically developed through field
survey methods. Given the coordinates and an arbitrary station value for a known starting
point, the surveyor delineates the centerline of the pipeline using a distance (measured by
chains) and deflection angle from the last collected point of the centerline. The angle and
distance traverse established from point to point creates what is known as the centerline.
The known points created from the angle and distance measurements are the control
points of the pipeline. Only recently, and in small instances, has absolute positioning–
with the advent of the global positioning system (GPS) coordinates used in conjunction
with highly accurate digital rectified orthophotography– become mainstream for creating
the control points that define the centerline.
Stationing is based on traditional field survey and drafting methodology and is the
historical method of conducting business for a pipeline. Stationing is the primary method
for historical record keeping that pipeline companies are required to maintain for
regulatory purposes as required by the Federal Energy Regulatory Commission (FERC),
the Office of Pipeline Safety (OPS) as part of the Department of Transportation (DOT),
and the National Pipeline Mapping System (NPMS). Pipeline companies in North
America are required to locate all facilities on or along the pipeline. Stationing is used to
locate pipeline features on a foot-by-foot basis in the field by stepping off or pacing off
locations of events from known points along the pipeline.
Stationing has historically been used in transmission pipelines for locating features along
the pipeline centerline. With the advent of ubiquitous GPS and GIS technology, a case
can be made for discontinuing the use of stationing as a location mechanism. However,
the following list presents many valid reasons for continuing with stationing as a useful
and effective mechanism for locating features:
•
Historically features have been located along pipeline system by stationing. Large
historical archives of stationed position exist, creating a valuable resource of
location information.
•
The field crews of pipeline operating companies are versant in the use of
stationing for referencing and rely on a repository of heuristic location methods to
locate and map features.
ESRI Technical Paper
17
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
•
Despite the recent mainstream introduction of GIS systems to the pipeline
industry, many operating companies lack sufficient land base style data to locate
features by means other than stationing.
•
It is cumbersome to repeatedly enter 15+ digit coordinate values to locate
features. This is especially true considering that a point coordinate may not be
unique in the case of large pipeline systems that span several map projection
zones.
•
Linear referencing and dynamic segmentation of spatially coincident linear
features can be done rapidly when using features ordered by station values. ESRI
has invested significantly in this core technology.
•
Linear referencing (and the APDM implementation thereof) allows for a very
powerful and flexible representation of multiple stationing systems that can be
used in conjunction with each other to locate features in an ad-hoc fashion.
•
Stationing is the only mathematical mechanism to systematically account for any
given point along the pipeline system from beginning to end. Since stationing is
mathematically based, features can be sorted by station value upstream and
downstream along a centerline for the purposes of reporting and analysis. In this
manner, pipeline operators can ‘walk the entire pipeline foot by foot’.
The more common forms of stationing measurement are described below.
9.1.1 Distance Based
•
Slack Chain (also referred to as slope, vertical, or engineering) – The distance
between two points is the three-dimensional distance along the earth's surface,
rather than the two-dimensional distance between the points, and is used to
determine station value along the pipeline (e.g., the distance of a chain draped
over the ground rather than the surveyed vector distance).
•
Horizontal – The two-dimensional map vector distance between two points, not
taking into account any z changes in the surface between the two points, is used to
determine station value along the pipeline (e.g. two-dimensional vector distance).
•
Continuous – Stationing starts at a set value and continuously and cumulatively
measures either slack or horizontal distance from the start to the end of a
centerline along all station series.
9.1.2 Arbitrary (Pseudo-distance Based)
May 2007
18
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
•
Mile Posting – Posts or other markers are placed in or on the ground at arbitrary
intervals and are used as reference points for locating features.
•
Offset Based – Measurements are taken as offset values from known points along
the centerline (e.g., valve section– the feature is located 100 feet downstream
from the mainline valve).
9.2 The Centerline (Routes, Measures, and Events)
The centerline of a pipeline system is composed of station series features, which in turn
are composed of control points. The station series concept allows each and every station
value (e.g., a point location) along the pipeline centerline route to be uniquely located at a
specific geographic coordinate even when duplicate station values exist on a single
pipeline. Duplicate station values usually occur after a section of an original line is
relocated or rerouted, resulting in the creation of a station equation to compensate for the
additional installed pipe length. It is also possible to have duplicate station values for
different line loops in the pipeline. Duplicate station values may also be created
intentionally at the time of original construction. To help differentiate the locations of
duplicate station values, each station series record has a unique identifier, a begin and end
station value, and belongs to a line loop.
Control points are points along the pipeline centerline with known geographic
coordinates and known station values. When a group of control points is assigned to a
specific station series, the centerline of the pipeline can be graphically represented in its
real-world geographic location based on the selected coordinate system and map
projection. Control points occur at changes in the centerline direction of the pipeline
(i.e., points of inflection [PI]), at centerline ties where a distance and/or angle exists to an
offline point event with known geographic coordinates (i.e., a section corner), or at any
pipeline centerline location with known geographic coordinates, such as GPS survey
points.
Conceptually, station series and control points are directly analogous to ESRI linear
referencing routes and measures. A station series feature is an M- (measure) Aware
polyline feature called a route. The measures of the route are defined at each vertex
including the endpoints. Since control points are used to form the vertices of the station
series feature, the measure value in the vertex is also the station value assigned to the
control point. Events are point or line entities or objects that occur on, along, or beside
the centerline. Each point event on, beside, or along the centerline has an absolute
position and a relative position (or absolute/relative start and end position if a linear
feature). The absolute position of an event is measured by the x,y coordinates of the
feature once the relative position of the event has been determined. The relative position
of an event is measured by identifying a unique route (station series) and a measure value
(station) that represents an interpolated distance from the start of a station series through
the known control points (that act as vertices of the station series) to the point where the
event occurs. If the event falls along the station series in between two control points (each
ESRI Technical Paper
19
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
with a different station value), the position of the event is interpolated along the station
series relative to the station values of the bordering control points and the station value of
the event. Point events are located on a single route feature. Currently, ESRI linear
referencing technology dictates that linear events must also start and end on the same
route.
Station series features are modeled as M-Aware and (optionally) Z- (elevation) Aware
polyline features in the APDM. Control points are modeled as M-Aware and (optionally)
Z-Aware point features in the APDM. Both station series and control points are
considered core elements of the APDM.
9.3 Hierarchy
Pipeline companies often organize or group features according to a hierarchy. Typically
the hierarchy is based on where particular station series features are located. Usually, the
hierarchy groups together the station series features belonging to a single line. Lines are
then grouped into pipeline systems. Pipeline systems are then grouped by pipeline
company. Even a simple hierarchy can be broken down into more complex organizational
structures such as main lines, discharge subsystems, valve sections, and branches. There
is no standard hierarchy structure to which pipeline companies adhere, but almost all
pipeline companies implement some kind of hierarchy for their pipeline systems.
The most ubiquitous unit of hierarchy in pipeline systems is the line loop (e.g. the PODS
Route, or the ISA Line_Loop). The APDM implements basic hierarchy by assigning each
and every station series to a line loop. Line loops associated with station series are
referred to as physical line loops. However, in the APDM a line loop can be more than
just a physical entity. Line loops can also be used to logically organize pipeline segments
into a complex hierarchy (through recursion in the LineLoop table structure). APDM
physical line loops can be used to construct many types of pipeline hierarchy elements:
•
•
•
A single pipeline from the source (the gathering fields or refineries) to the
terminus of the line (connection at town border stations to distribution centers
or refineries).
A mainline lateral branch.
A gathering or flow line.
APDM logical line loops can represent:
•
•
Nested gathering systems.
Transmission pipeline systems grouped by operator, product, diameter, etc.
Often several physical line loops run parallel to each other. A logical line loop may have
gaps along the pipeline as a whole, as pipes are often shared between several lines. In
almost all cases a physical line loop is an aggregation of one or more station series
May 2007
20
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
features without gaps; logical line loops are usually the aggregation of one or more
physical and or logical line loops.
The APDM does not explicitly model logical or network connectivity of station series
features. Each station series feature is uniquely identified in the model. The line loop
construct is used at the simplest level to organize station series features into a flat
hierarchy.
Line loop is modeled as an object class in the APDM and is considered to be one of the
core elements. Other hierarchical elements in the model are line loop hierarchy,
subsystem, and subsystem hierarchy, all of which are used to define the hierarchy of a
pipeline system. For more detailed information, refer to the 10.4.2 Core Object Classes
section, below.
9.4 Coincident Geometry
An important consideration in the design of the APDM is the prevalence of coincident
point and line features in a transmission pipeline. Any feature located by relative position
(stationing) is coincident or offset from the centerline. Any change in the geometry
and/or the underlying station (measures) of the centerline route system has ramifications
on the geometric location of features or events whose positions are dependent on the
applied measures and position of the centerline. Linear features, such as coating and
pressure tests, are child features dependent on the presence of parent linear features such
as pipe segments. The relationship between these features dictates that if the parent is
removed or altered (partially removed, or vertex position changed) then the child must be
similarly altered. The same relationship applies to pipe segment (child) and station series
(parent). A goal of the APDM is to mitigate the effects of editing parent feature geometry
or station (measure) attributes. Relationship classes are used to maintain the station
(measure) relationships between the centerline and dependent child features. ArcGIS
Topology is the recommended solution for handling the geometric relationships between
coincident geometries from different feature classes.
9.5 Events Versus Features
The APDM can be implemented with features stored in feature classes (geometry is
stored with x,y coordinates), event tables (geometry is dynamically generated from
Route-ID and measure values), or a combination of both. Each implementation approach
has costs and benefits. The benefits to using geometry are that performance is excellent,
the features can be displayed quickly through the Internet via ArcIMS, and the features
can be edited directly in ArcMap™. The problem that arises when using geometry is that
feature geometries are not automatically updated when the underlying Route-ID and
measure values (or begin/end Route-ID and measure values) are updated.
The benefit of using events is that whenever the Route-ID and measure values are
updated, then the geometry can be quickly refreshed. If an error occurs when the event
ESRI Technical Paper
21
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
geometry is being created, then an error message can be appended to the row containing
the feature. The problem with using events is that each feature does not have a permanent
geometry and, thus, display performance is poor by comparison. In addition, the features
are not available for display in real time through the Internet. Large volumes (more than
10,000 events) of data cannot be expected to perform in a timely manner given the
current state of the technology.
The ideal situation within the model is to have features that act as events. In this desirable
state of affairs, the geometry of a feature is automatically updated when the Route-ID
and/or measure values are altered. Currently, the only way to obtain this behavior from
the geodatabase is via custom application code. Ultimately the choice of implementation
(event or feature) remains the decision of the end user and depends on the type of GIS
being implemented.
10.0 APDM Conceptual Model
All the features in the APDM can be organized into one of three categories:
•
•
•
Abstract classes
Core classes
Optional classes
The abstract classes define the framework of the APDM; all other classes in the APDM
inherit properties, relationships and behaviors from one of the APDM abstract classes.
The APDM abstract classes are required elements of the model. However, the APDM
abstract classes are not ‘concrete’; they never actually appear physically in an
implemented APDM geodatabase. The APDM abstract classes appear only in the APDM
logical and physical (UML) models.
The core classes are those object, feature and relationship classes, together with
associated domains, that are required to maintain APDM compliance. The core classes
define the APDM centerline features, stationing attributes, and supporting model
elements. The core classes are concrete; unlike the abstract classes, the core classes
physically appear in an implemented APDM geodatabase.
The optional classes are just that. The optional classes are described in a separate
document, ArcGIS Pipeline Data Model Version 4.0 Optional Classes. They are
distributed with the model as implementation examples, but none of them are required
elements of the model. The optional classes are included to provide a starting template
for companies with no existing pipeline data model. Companies that are currently users of
a relational model such as PODS or ISAT, or a proprietary model, may desire to replace
the optional APDM classes and domains with classes and domains that more closely
resemble their existing data stores. As long as the modified classes and domains follow
the rules defined by the APDM abstract classes and metadata, this is entirely permissible,
and indeed, encouraged.
May 2007
22
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
10.1 APDM Abstract Classes/Metadata Overview
The APDM is defined as a template, rather than as a standard. Aside from minimal
constraints, implementers are free to modify the model to suit their business needs. As a
result, the potential for APDM implementations with widely divergent attribution and
data content exists. Despite the reality of content divergence, a major goal of the APDM
is to maintain interoperability across implementations and between products offered by a
variety of APDM application providers. To promote APDM interoperability the APDM
Steering and Technical committees have developed compliance concepts based largely on
defining the semantic behavior of the APDM classes, rather than their explicit data
attribute content.
Off-the-shelf ESRI geodatabase technology exposes considerable functionality for
defining the behavior of spatial layers relative to each other. For example, geometric
networks can be used to define connectivity rules between features residing in different
feature classes. Topology feature classes can be used to define editing behaviors for
spatially coincident features from different feature classes. While powerful, the off-theshelf 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 classand 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
ESRI Technical Paper
23
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
APDM abstract classes are used to coarsely define the semantic behavior of the various
feature and object classes in the APDM. APDM abstract classes are defined by their
‘core’ data attribution, and by the types of relationships that are implemented between the
various APDM abstract class types. The abstract class type of any APDM object or
feature class is determined by the presence of required ‘core’ data attributes and
relationship classes.
10.2.1 What is an abstract class?
APDM abstract classes act as templates. The formal definition of a template is a pattern
usually consisting of a thin plate of some material serving as a guide in mechanical work
for the creation of many objects with similar shapes. In the APDM, a template is a pattern
that defines an object or class containing known and predictable behavior. The pattern (in
the context of the APDM) is defined as a set of attributes, including geometry, and
relationships to other classes. APDM abstract classes do not become actual feature
classes or object classes in the geodatabase. APDM abstract classes perform like a
carpenter’s template which is used to outline many versions of the same shape. In
APDM, the template is used to create many versions of the same class. In the carpentry
example, each cut shape inherits the properties of the template, but retains its own
individual material characteristics and can be modified to create a variation based on the
original template. In a similar manner, a concrete class in the APDM geodatabase inherits
certain base attributes and relationships from an APDM abstract class. The addition of
specific attributes and or relationships result in the creation of an individual, concrete
feature or object class within the geodatabase.
10.2.2 Why are abstract classes used?
Abstract classes serve three purposes within the APDM. First, abstract classes define
specific behavior for a set of objects within an APDM model. Of particular importance is
the behavior of how a feature responds to an edit or modification of the pipeline
centerline. The second purpose is for efficiency in documentation. It is simpler to
describe the content and behavior of an abstract class in a single location and use
inheritance to propagate behavior to concrete class definitions. The third purpose for
including abstract classes is reuse. Reuse, in this context, binds the previous two reasons
together. The description and documentation of standard behavior can be applied to many
different concrete classes within an APDM geodatabase. The definition and
documentation of behavior thus defines the rules by which abstract classes, and those
classes that inherit from them, must behave.
Because the APDM model is a collection of features, objects and their relationships,
defining the behavior of abstract classes dictates the rules that govern the model.
Relationship classes defined for abstract classes ultimately determine how concrete
APDM feature and object classes interact. Class- and feature-level metadata attributes
defined for abstract classes govern how entire concrete APDM feature classes, and/or
individual feature or objects behave when certain edit events occur. The rules defined for
May 2007
24
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
the APDM abstract classes govern for their concrete class inheritors the outcomes of the
following types of feature and object events:
•
Addition of a feature or object to a concrete class.
•
Deletion of a feature or object from a concrete class.
•
Update of any of the core or audit attributes of a feature or object (e.g. EventID,
GroupEventID, stationing, or operational status attribute values).
•
Update of the geometry of a feature.
•
Update of the centerline on which a feature resides (e.g. a control point is moved,
or its station value is altered, or a reroute is performed at the LineLoop level).
•
An activity and/or an external document is associated with a feature or object (i.e.
an audit record is associated with the feature or object).
All feature and object classes contained within the APDM inherit attributes and behavior
from one or more of the APDM abstract classes. The APDM is designed around these
abstract classes. Abstract classes provide a framework for data editors and developers to
capture abstract class behavior in workflows and software applications. The rules for
abstract class behavior are formally defined in this section. To date, however, the
enforcement of abstract class behavior is up to the end user and/or the third party
application developer. Simply employing abstract classes to build an APDM geodatabase
does not prevent an end user from manipulating the contents of a single row or column of
data in contradiction to the abstract class rules.
The APDM Technical Committee expended considerable effort in defining the APDM
abstract classes for version 4.0. The APDM 4.0 abstract classes are somewhat more
numerous and much more rigorously defined than the abstract classes found in earlier
versions of the model. Aside from their primary purpose in defining model behavior, the
carefully tailored abstract classes of the APDM 4.0 make it much simpler and safer for an
implementer to extend or modify the model. An implementer can simply define a new
custom class, have it inherit from the desired abstract class, and know that the custom
class will behave properly within the context of the APDM. Achieving and maintaining
APDM compliance is almost automatic when the APDM abstract classes are properly
utilized.
10.2.3 Duplication of Attributes within APDM abstract classes
The reader will note there is some duplication of attributes within the APDM abstract
classes. The reason for this is that while multiple inheritance is implicit in the APDM
abstract class structure, multiple inheritance is not supported within the ESRI object
model. This means each object class or feature class that is implemented within the
ESRI Technical Paper
25
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
APDM can inherit from one and only one parent object. Attribution that would otherwise
be propagated via multiple inheritance must therefore be propagated explicitly, giving
rise to the observed attribute duplication.
Within the APDM Visio UML diagram (the physical model), the APDM abstract classes
are implemented on a separate Static Structure Diagram. The diagram is laid out as a
cascading leaf diagram showing the lower level classes explicitly inheriting from the
ancestry above them. As is standard with UML, attributes defined by a parent object are
not explicitly shown in a child object. This is done to minimize the amount of work to
update the model when attribute changes are made. Therefore, when reading the APDM
Visio Physical model, one must be sure to look at all ancestors of an object to get a full
list of the attributes defined on a single object.
Concrete feature and object classes defined on the other static structure diagrams within
the model are generalized using a single generalization connector to the appropriate
abstract class. This approach makes all concrete class definitions extremely concise.
Duplication of attributes is largely eliminated since core (common) attributes are defined
within the abstract classes from which the concrete classes inherit.
10.2.4 Inheritance (How to read the APDM Logical Model Poster)
The APDM Logical Model represents an object diagram of the APDM. The object
diagram is used to depict the following: classes, attributes of classes, relationships
between classes, and inheritance from classes. A class is defined as either an Abstract or
Concrete class. An attribute is a property that helps define the class. In this context, a
property is analogous to a database table attribute and is defined by name and data type
properties including primary key, foreign key or domain. Relationships between classes
are directly analogous to database relationships between entities in that they are described
by optionality and cardinality (e.g. must-have, may-have and one-to-many, zero-to-one,
many-to-many). Lastly, inheritance is defined as something, such as a quality or
characteristic received from predecessors (i.e. parents) as if by succession. Inheritance
allows attributes and relationships to pass from parent classes to child classes. This is
analogous to the manner in which mannerisms, instincts and characteristics are passed
from parents to their offspring in the natural world.
As inheritance of attributes and relationships is passed down from parent to child,
attributes and relationships accumulate as the process proceeds down the inheritance tree.
At the lowest point in the inheritance tree, a child has inherited all the attributes and
relationships from all of its ancestors. Inheritance is used in APDM to define class
behavior at the top levels and more complex behavior at the lower levels of the
inheritance tree. The APDM abstract classes in effect describe the core attributes within
the APDM. Inheritance is denoted in the logical model poster by a white filled triangle
and a solid line from a parent class to a child class. The triangle is placed under the parent
class and the solid black line links the child classes to the parent. The diagram below
showing inheritance reads in a similar fashion to the poster where many children are
May 2007
26
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
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.
ESRI Technical Paper
27
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
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 callout 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.
May 2007
28
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
The diagram above illustrates APDM abstract class inheritance from the top of the tree
down to the example concrete class, Elbow.
ESRI Technical Paper
29
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
The APDM abstract classes represent the expected behavior of object and feature classes
in the APDM. Behavior can be expressed as a function of three elements – the attributes
of a class, the relationships of a class, and the inheritance of a class. The next section
presents each APDM Abstract Class by describing the geometry, inheritance, attributes,
and relationships for the class. In describing these properties for each class, the expected
behavior for that class is defined. APDM Compliance is defined as follows:
•
•
•
Every class in the APDM must inherit directly from an APDM Abstract Class
Inherited attributes and relationships must use the standard APDM names,
optionality and cardinality without deviation.
The core APDM classes must be implemented according to the inheritance tree
and they must use the names assigned to them.
APDM Metadata classes and attributes are described in the 10.3 APDM Metadata section
of the whitepaper.
10.2.5 Abstract Class Definitions
The APDM abstract classes are described below, and illustrated in the following diagram
(Note that instructions for reading the inheritance and logical model diagrams is outlined
in Appendix A):
May 2007
30
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
ESRI Technical Paper
31
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
May 2007
32
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
10.2.5.1 APDMObject
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
APDMObject
Not Applicable.
ESRI Simple Object (Ancestor)
ObjectArchive (Child - Abstract)
ActivityHierarchy (Child - Core)
InstrumentParameter (Child - Example)
LineLoopHierarchy (Child - Core)
SubSystemHierarchy (Child - Core)
Attributes: EventID (GUID, String, 38) – A globally unique identifier for the
(name, type, length, precision, scale,
class.
domain, description)
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 globally unique identifier containing a GUID value (String, 38). All feature
classes and object classes within the APDM must have an attribute named EventID. The
EventID provides a mechanism for uniquely identifying each feature or object in the
geodatabase and is independent of the feature or object class to which it belongs. Using
GUIDS for unique identifiers ensures that all features maintain a unique key even if they
are exported from and then imported back into a geodatabase. The ObjectID or OID
attribute is provided to all registered classes within a geodatabase by ESRI. The OID is of
long integer type and can change when features are exported from and then imported
back into a class. Note that the term "event" in EventID does not denote that this attribute
pertains to event tables or events only. “EventID” was chosen to represent a global ID for
any event that occurred on or along a pipeline system, be it an online or offline feature. In
a future version of APDM the term “EventID” may be replaced by a more descriptive
term such as "FeatureID" or "GeoEntityID".
LineLoopHierarchy, ActivityHierarchy and SubSystemHierarchy are all APDM Core and
concrete classes that directly inherit from APDMObject. The three hierarchy classes
comprise the APDM Core Classes. These classes do not require attributes beyond
EventID because their existence and behavior is completely described by that of their
parent classes (LineLoop, Activity and SubSystem, respectively).
10.2.5.2 ObjectArchive
ESRI Technical Paper
33
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
ObjectArchive
Not Applicable.
ESRI Simple Object Æ APDMObject (Ancestors - Abstract)
CenterlineObject (Child - Abstract)
FacilityObject (Child - Abstract)
NonFacilityObject (Child - Abstract)
Attributes: OriginEventID (GUID, String, 38) – The original GUID for a
(name, type, length, precision, scale,
feature. OriginEventID is set to be equal to EventID when a
domain, description)
feature is first created. OriginEventID does not change with
successive records representing different historical states of a
feature. For example, consider the EventID attribute of an online
polyline once it has been split into two new features. When the
parent is split all child segments of the parent feature inherit the
original OriginEventID of the parent (each child segment does
receive a unique EventID).
CreatedBy (String, 45) – User ID of the operator who created the
feature. A value is applied once to this attribute when the object
is first created. CreatedBy does not change with successive
updates or versions of this record representing different historical
states of the object.
CreatedDate (Date) – The timestamp when the initial record for the
object was created in the database. Because the CreatedDate is a
database date, it does not necessarily correspond to the actual
effective date of the feature or object in the real world.
CreatedDate may be either earlier or later than
EffectiveFromDate. In a similar manner as CreatedDate,
CreatedBy does not change with successive updates or versions
of this record representing different historical states of the object.
EffectiveFromDate (Date) – The date a particular record in the
database went into effect in the real world. This date should not
be confused with the CreatedDate. The EffectiveFromDate for
the initial record for a feature should correspond to either the
InServiceDate or the InstallationDate for the feature. The
EffectiveFromDate is modified with each successive record
documenting the historical state of a feature.
EffectiveToDate (Date) – The date at which a particular record in
the database is no longer in effect. EffectiveToDate is modified
with each successive record documenting the historical state of a
feature. EffectiveToDate is null for a database record that is
currently in effect,
LastModified (Date) – The timestamp for the last modification of
the record in the database. LastModified is equal to the
CreatedDate for the initial record of an object. The LastModified
May 2007
34
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
timestamp is modified with each successive record documenting
the historical state of a feature.
ModifiedBy (String, 45) – The User-ID of the operator who last
modified the feature. ModifiedBy = CreatedBy for the initial
record of a feature,. ModifiedBy changes with each successive
record representing different historical states of a feature.
HistoricalState (Long Integer, 9) gnHistoricalState (required APDM
domain) – Indicates whether the record represents the current
state, or an historical state, of the referenced object or feature.
HistoricalState is included in the model for those utilizing
‘inline’ history. In such implementations, multiple historical
versions of a single feature or object may be stored; the
HistoricalState attribute provide a simple means of distinguishing
current vs. historical records.
ProcessFlag (String, 10) - A catch-all field for application
developers used for temporarily storing values, tags, and codes
required for application processing. The field is not meant to
store information on a permanent basis and should be cleared
after each procedure or operation that is performed using this
field.
Remarks (String, 255) – Open field used for comments, remarks, or
notes about the object.
Relationships: None
(cardinality, optionality, attributes,
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:
Feature Class
Geometry:
APDM
Inheritance:
ESRI Technical Paper
CenterlineObject
Not Applicable.
ESRI Simple Object Æ APDMObject Æ ObjectArchive (Ancestor
- Abstract)
AltRefMeasure (Child - Core)
LineLoop (Child - Core)
SubSystem (Child - Core)
35
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Attributes: GroupEventID (GUID, String, 38) – For LineLoop and SubSystem,
GroupEventID is used to aggregate or group all the children of a
root-level LineLoop or SubSystem. The EventID of the rootlevel LineLoop or Subsystem is applied as the GroupEventID of
all child (branch) LineLoop or SubSystem objects to facilitate
query and reporting. The AltRefMeasure object class makes use
of the GroupEventID attribute to group split online polyline
features together.
OperationalStatus (Long Integer, 9) gnOperationalStatus (required
APDM domain) – Domain value indicating the status of a feature
that has some operational lifespan based on FERC/OPS
definitions. Applied to centerline features or facility features with
complex operational life spans. The gnOperationalStatus domain
is considered a core APDM domain that inherits values from the
gnStatus domain and must be implemented exactly as prescribed
by the APDM.
Relationships: None
(name, type, length, precision, scale,
domain, description)
(cardinality, optionality, attributes,
composite)
SubTypes: -The CenterlineObject APDM Abstract Class provides access to the Group and
OriginEventID. These values are typically reserved for online polyline features that span
station series equations and are often broken at series breaks. These attributes may be
used to group hierarchy objects such as LineLoops and SubSystems together. As a best
practice, the use of the OperationalStatus attribute as it pertains to LineLoop and
SubSystem should affect all related child features. When changing the OperationalStatus
value of these objects, such changes should be cascaded to all related StationSeries
features and child features through the relationship tree (e.g. online features, offline
features with online locations etc.). The OperationalStatus domain contains the following
values: -1=Unknown (Verified), 0=Unknown, 1=Conceptual, 2=Proposed, 4=Active,
8=Inactive, 16=Idle, 32=Abandoned and 64=Removed.
10.2.5.4 NonFacilityObject
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
May 2007
NonFacilityObject
Not Applicable.
ESRI Simple Object Æ APDMObject Æ ObjectArchive (Ancestors
- Abstract)
Activity (Child – Core)
Address (Child – Example)
CISReading (Child – Example)
<classname>Audit (Child – Core)
Company (Child – Core)
36
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Contact (Child – Example)
ExternalDocument (Child – Core)
GeoMetaData (Child – Example)
MeterReading (Child – Example)
OwnerOperator (Child – Core)
Product (Child – Core)
StructureOrIDSite (Child – Example)
Attributes: Status (Long Integer, 9) gnStatus (required APDM domain) –
(name, type, length, precision, scale,
Defines the status of an object within the APDM. Status is used
domain, description)
to describe the state of a non-facility object. These objects either
have no operational significance or do not exist as a geographical
or physical entity. The gnStatus domain is considered a core
APDM domain and must be implemented using the specified
values exactly as prescribed by the APDM.
Relationships: None
(cardinality, optionality, attributes,
composite)
SubTypes: -The NonFacilityObject APDM Abstract Class provides a universal status field for nonoperational and non-facility object classes. Status is provided to indicate rudimentary
status values rather than a full set of operational status values. The values for the gnStatus
domain applied to this field are: -1=Unknown (Verified), 0=Unknown, 1=Conceptual,
2=Proposed, 4=Active, and 8=Inactive.
10.2.5.5 FacilityObject
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
FacilityObject
Not Applicable.
ESRI Simple Object Æ APDMObject Æ ObjectArchive (Ancestors
- Abstract)
ValveOperator (Child – Example)
Attributes:
(name, type, length, precision, scale,
domain, description)
ESRI Technical Paper
InServiceDate (Date) - Represents the date a piece of equipment is
actually put in service and is used primarily for accounting
purposes. Note that the InServiceDate date may be later than the
installation date.
InstallationDate (Date) - The date a piece of equipment is installed.
InstallationDate is important for risk analysis.
OperationalStatus (Long Integer, 9) gnOperationalStatus (required
APDM domain) – A domain value indicating the status of a
feature that has some operational lifespan based on FERC/OPS
definitions. Applied to centerline features or facility features with
complex operational life spans. The gnOperationalStatus domain
37
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
is considered a core APDM domain that inherits values from the
gnStatus domain and must be implemented exactly as prescribed
by the APDM.
SiteEventID (GUID, String, 38, FK) – Indicates the site
(compressor station, meter station, custody transfer station,
storage yard etc.) the facility belongs to or is contained within.
By utilizing this attribute online features or FacilityObjects can
be placed or located without the need for geometry. This concept
is outlined in the section ‘Non Geometric Features’.
Relationships: Site<FacilityObject class name> (core): Each FacilityObject class is
(cardinality, optionality, attributes,
M:1 with Site.
composite)
SubTypes: -The FacilityObject APDM abstract class provides in-service, installation and operational
status attributes for objects representing facilities. Compressors, compressor engines, and
valve operators are facilities that are typically modeled as non-geometric objects. The
SiteEventID field can be used to relate the object (e.g. a compressor station) to a
particular site. The OperationalStatus domain contains the following values: 1=Unknown (Verified), 0=Unknown, 1=Conceptual, 2=Proposed, 4=Active, 8=Inactive,
16=Idle, 32=Abandoned and 64=Removed.
10.2.5.6 FeatureArchive
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
FeatureArchive
Not Applicable.
ESRI Simple Object Æ ESRI Simple Feature (Optional)
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
(name, type, length, precision, scale,
feature. A value is applied once to this attribute when the feature
domain, description)
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
May 2007
38
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
of this record that represent different historical states of the
object.
EffectiveFromDate (Date) – The date a particular record in the
database went into effect in the real world. This date should not
be confused with the CreatedDate. The EffectiveFromDate for
the initial record for a feature should correspond to either the
InServiceDate or the InstallationDate for the feature. The
EffectiveFromDate is modified with each successive record that
documents the historical state of a feature.
EffectiveToDate (Date) – The date at which a particular record in
the database is no longer in effect. EffectiveToDate is modified
with each successive record documenting the historical state of a
feature. For a database record that is currently in effect,
EffectiveToDate is null.
EventID (GUID, String, 38) – A globally unique identifier for the
class.
OriginEventID (GUID, String, 38) – The original GUID for a
feature. OriginEventID is set to be equal to EventID when a
feature is first created. OriginEventID does not change with
successive records representing different historical states of a
feature. For example, consider the EventID attribute of an online
polyline once it has been split into two new features. When the
parent is split all child segments of the parent feature inherit the
original OriginEventID of the parent (each child segment does
receive a unique EventID).
LastModified (Date) – The timestamp for the last modification of
the record in the database. LastModified is equal to the
CreatedDate for the initial record of an object. The LastModified
timestamp is modified with each successive record documenting
the historical state of a feature.
ModifiedBy (String, 45) – The User-ID of the operator who last
modified the feature. For the initial record for a feature,
ModifiedBy = CreatedBy. ModifiedBy changes with each
successive record that represents a different historical state of a
feature.
HistoricalState (Long Integer, 9) gnHistoricalState (required APDM
domain) – Indicates whether the record represents the current
state, or an historical state, of the referenced object or feature.
HistoricalState is included in the model for those utilizing
‘inline’ history. In such implementations, multiple historical
versions of a single feature or object may be stored; the
HistoricalState attribute provide a simple means of distinguishing
current vs. historical records.
ProcessFlag (String, 10) - A catch-all field for application
ESRI Technical Paper
39
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
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
(cardinality, optionality, attributes,
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 globally unique identifier containing a GUID
value (String, 38). All feature classes and object classes within the APDM must have an
attribute named EventID. The second purpose of the FeatureArchive APDM Abstract
Class is to store feature class level archiving information including who created the
feature and who last modified the feature or its attributes. This class includes operational
dates such as effective to and from dates and the APDM core fields ProcessFlag and
Remarks. All features belonging to feature classes below this class in the inheritance tree
require this information for operational and historical tracking purposes.
In the above definition, FeatureArchive optionally implements ESRI Simple Feature. The
reason for this is to accommodate those who wish to implement the APDM using events
rather than features. However, both the logical model diagram and the physical model
UML diagram depict FeatureArchive as implementing ESRI Simple Feature; this is the
recommended best practice.
10.2.5.7 CenterlinePolyline
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
CenterlinePolyline
M Aware polyline feature class.
ESRI Simple Object Æ ESRI Simple Feature (Optional) Æ
FeatureArchive (Ancestors - Abstract)
CenterlinePolylineEvent (Child - Abstract)
StationSeries (Child - Core)
Attributes: OperationalStatus (Long Integer, 9) gnOperationalStatus (required
(name, type, length, precision, scale,
APDM domain) – A domain value indicating the status of a
domain, description)
feature that has some operational lifespan based on FERC/OPS
definitions. It is applied to centerline features or facility features
with complex operational lifespans. The gnOperationalStatus
domain is considered a core APDM domain that inherits values
from the gnStatus domain and must be implemented exactly as
May 2007
40
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
prescribed by the APDM.
Relationships: None
(cardinality, optionality, attributes,
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.
The CenterlinePolyline APDM abstract class adds OperationalStatus to the
FeatureArchive attributes for use by the one core class inheriting from it: StationSeries.
As a best practice, the use of the OperationalStatus attribute as it pertains to StationSeries
should affect all related child features. When changing the OperationalStatus value of
station series features, such changes should be cascaded to all child features through the
relationship tree (e.g. online features, offline features with online locations etc.). The
OperationalStatus domain contains the following values: -1=Unknown (Verified),
0=Unknown, 1=Conceptual, 2=Proposed, 4=Active, 8=Inactive, 16=Idle, 32=Abandoned
and 64=Removed. The APDM Core section of this paper explains the structure and
purpose of the StationSeries feature class and how it interacts with other classes within
the model.
10.2.5.8 CenterlinePolylineEvent
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
CenterlinePolylineEvent
May be implemented as an M Aware polyline feature class or as an
object class used to build ESRI event themes.
ESRI Simple Object Æ ESRI Simple Feature (Optional) Æ
FeatureArchive Æ CenterlinePolyline (Ancestors - Abstract)
SubSystemRange (Child - Core)
Attributes: StationSeriesEventID (GUID, String, 38, FK) – Foreign key to the
(name, type, length, precision, scale,
primary reference mode (PRM) station series feature that
domain, description)
addresses the location of the online feature.
BeginStation (Double, 15, 2) - A station value (measure) along a
station series used to position and locate the start of the linear
feature.
EndStation (Double, 15, 2) – A station value (measure) along a
station series used to position and locate the end of the linear
feature.
CLEditResponse (Long Integer, 9) clEditResponse (required
APDM Domain) – Indicates how the geometry and/or stationing
attributes of an online feature respond to a centerline edit such as
a reroute. This attribute is further described in the section
‘Feature Level Metadata’.
CLValidityTolerance (Double 15,2) – Indicates how far the
centerline can move away from an online event feature before
ESRI Technical Paper
41
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
the event becomes ‘invalid’. Expressed the distance units of the
Transmission feature dataset. This attribute is further described
in the section ‘Feature Level Metadata’.
GroupEventID (GUID, String, 38) – Used to aggregate or
generalize two or more centerline features together as a single
unit for the purposes of querying, reporting and calculating
distances or lengths. Primarily used for features that are broken
apart on interrupted style primary reference modes.
Relationships: StationSeries<CenterlinePolylineEvent name> (core):
(cardinality, optionality, attributes,
CenterlinePolylineEvent is M:1 with StationSeries.
composite)
SubTypes: -The CenterlinePolylineEvent APDM abstract class adds online polyline event attributes
(StationSeriesEventID, BeginStation, EndStation and GroupEventID) and centerline edit
metadata attributes (CLValidityEditResponse and CLValidityTolerance) to
CenterlinePolyline for the one event class that inherits from it: SubSystemRange. The
CenterlinePolylineEvent abstract class is distinguished from the OnlinePolylineFacility
abstract class by the absence of the InstallationDate and InServiceDate attributes.
GroupEventID and the inherited OriginEventID attributes have relevance for
SubSystemRange features as they may span station equations in interrupted style
reference modes. The APDM Core section of this paper explains the structure and
purpose of the SubSystemRange feature class and how it interacts with other classes
within the model.
10.2.5.9 CenterlinePoint
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
CenterlinePoint
Implemented as an M Aware point feature class.
ESRI Simple Object Æ ESRI Simple Feature (Optional) Æ
FeatureArchive (Ancestors - Abstract)
ControlPoint – (Child - Core)
Attributes: CLControl (Long Integer, 9) gnYesNo (required APDM domain) –
(name, type, length, precision, scale,
A Yes/No describing whether the control point participates in the
domained, notes)
construction of the centerline StationSeries feature. Some control
points may represent offline points of inflection rather than a
vertex of the station series.
CLStationEditResponse (Long Integer, 9) clStationEditResponse
(required APDM domain) - Describes how the station values for
the control point may be altered. This attribute is further
described in the section ‘Feature Level Metadata’.
CLXYEditResponse (Long Integer, 9) clXYEditResponse (required
APDM domain) - Indicates how the x,y portion of the geometry
of a control point feature responds to a centerline edit such as a
May 2007
42
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
reroute. This attribute is further described in the section ‘Feature
Level Metadata’.
CLZEditResponse (Long Integer, 9) clZEditResponse (required
APDM domain) - Indicates how the Z portion of the geometry of
a control point feature responds to a centerline edit such as a
reroute. This attribute is further described in the section ‘Feature
Level Metadata’.
GroupEventID (GUID, String, 38) – For ControlPoint,
GroupEventID used to aggregate or group control points found at
a single physical location for the purposes of querying, reporting
and calculations. The EventID of the PRM control point is used
as the GroupEventID for all control points at that location.
OperationalStatus (Long Integer, 9) gnOperationalStatus (required
APDM domain) – Status of the feature (e.g. active, abandoned,
proposed).
StationSeriesEventID (GUID, String, 38, FK) - The foreign key of
the Station Series feature to which the control point belongs.
SymbolRotation (Double, 15, 2), gnAngle (required APDM
domain) - A rotation angle from 0–360o for a point symbol (uses
gnAngle domain). This allows operators to preserve rotation
information for point symbols imported from external systems
such as Computer Aided Drafting (CAD) applications. Allows all
point symbols within the APDM to be rotated as needed;
manually, or in relation to other features. This is used primarily
for display in mapping applications such as alignment sheets.
Relationships: StationSeries<CenterlinePoint class name> (core): <CenterlinePoint
(cardinality, optionality, composite,
class name> is M:1 with StationSeries.
inheritance)
SubTypes: Reference Modes – each CenterlinePoint feature must have
subtypes equal to those in the CenterlinePolyline (StationSeries)
feature class. Each subtype value represents a single reference
mode.
The CenterlinePoint APDM abstract class encapsulates and describes the behavior of
points that participate in the construction of the centerline. Currently, only the
ControlPoint class serves this purpose in the APDM. The attributes of this class describe
the behavior and relationships of control points within the centerline and to the
StationSeries feature class. Each control point can have an operational status reflecting
the status of the parent station series. Control points can be placed in proposed or
conceptual states indicating route planning or new pipeline construction activities. More
information regarding the role of control points in the APDM is described in the ‘APDM
Core’ section.
10.2.5.10 OfflineFeature
ESRI Technical Paper
43
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
OfflineFeature
Implemented as an Non-M-Aware Polyline or Non-M-Aware
Polygon feature class
ESRI Simple Object Æ ESRI Simple Feature (Optional) Æ
FeatureArchive (Ancestors - Abstract)
AlignmentSheet – (Child - Example)
HighConsequenceArea – (Child - Example)
LineCrossing – (Child - Example)
RemovedLine – (Child - Example)
StructureOutline – (Child - Example)
IDSiteArea – (Child - Example)
Attributes: Status (Long Integer, 9) gnStatus (required APDM domain) –
(name, type, length, precision, scale,
Defines the status of an object within the APDM. Status is used
domained, notes)
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
(cardinality, optionality, composite,
locations stored in a class inheriting from the OnlinePoint or the
inheritance)
OnlinePolylinesForOfflineClass APDM Abstract Classes.
SubTypes: -The OfflineFeature APDM abstract class stores polyline and polygon features that are
primarily located by x,y coordinate position and have no impact on the location of the
centerline or the stationing values contained therein. Offline features comprise any
feature that is ancillary to the operations and description of the pipeline system and the
underlying geography. Most land base or supporting features possessing polyline or
polygon geometry are stored in feature classes inheriting directly from this abstract class.
OfflineFeatures such as Alignment Sheets and Line Crossings may be related to features
in classes inheriting from OnlinePolylineForOfflineFeature or
OnlinePointForOfflineFeature. Features in these classes are located on the centerline and
represent the online location or stationed position of an OfflineFeature. These
relationships are captured in the geodatabase as relationship classes and as rows in the
OnlineLocationClass APDM Metadata table.
10.2.5.11 OfflinePoint
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
May 2007
OfflinePoint
Implemented as an Non-M-Aware Point feature class
ESRI Simple Object Æ ESRI Simple Feature (Optional) Æ
FeatureArchive Æ OfflineFeature (Ancestors - Abstract)
DocumentPoint – (Child - Example)
44
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
FieldNote – (Child - Example)
RemovedPoint – (Child - Example)
SitePoint – (Child - Example)
NearestPointToLine – (Child - Example)
Attributes: SymbolRotation (Double, 15, 2), gnAngle (required APDM
(name, type, length, precision, scale,
domain) - A rotation angle from 0–360o for a point symbol (uses
domained, notes)
gnAngle domain). This allows operators to preserve rotation
information for point symbols imported from external systems
such as CADD. Allows all point symbols within the APDM to be
rotated as needed; manually, or in relation to other features. This
is used primarily for display in mapping applications such as
alignment sheets.
Relationships: None
(cardinality, optionality, composite,
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.12 OfflineFacility
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
OfflineFacility
Implemented as an Non-M Aware Polygon feature class
ESRI Simple Object Æ ESRI Simple Feature (Optional) Æ
FeatureArchive (Ancestors - Abstract)
Site – (Child - Core)
Attributes: InServiceDate (Date) - Represents the date a piece of equipment is
(name, type, length, precision, scale,
actually put in service and is used primarily for accounting
domained, notes)
purposes. The InServiceDate date may be later than the
installation date.
InstallationDate (Date) - The date a piece of equipment is installed.
Note that InstallationDate is important for risk analysis.
OperationalStatus (Long Integer, 9) gnOperationalStatus (required
APDM domain) – A domain value indicating the status of a
ESRI Technical Paper
45
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
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: Each and every OfflineFacility may have zero or more online
(cardinality, optionality, composite,
locations stored in a class inheriting from OnlinePoint or
inheritance)
OnlinePolylinesForOfflineClass APDM Abstract Classes.
SubTypes: -The OfflineFacility APDM abstract class provides the facility logic for all offline
facilities features by adding the InServiceDate, InstallationDate and OperationalStatus
attributes. Similar to OfflineFeatures, OfflineFacilities are used for storing features that
are primarily located by x,y coordinate position and have no impact on the location of the
centerline or the stationing values contained therein. OfflineFacility features may be
related to features in classes inheriting from OnlinePolylineForOfflineFeature or
OnlinePointForOfflineFeature but this is unlikely. The only class that inherits directly
from OfflineFacility is Site. Sites represent the boundaries of stations, storage areas, or
large buildings that possibly contain other features, and facilities. Sites are put into
service and have installation dates representing the time that they were built.
10.2.5.13 OfflineNonPointFacility
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
OfflineNonPointFacility
Implemented as a Non-M Aware Polygon or Non-M Aware
polyline feature class
ESRI Simple Object Æ ESRI Simple Feature (Optional) Æ
FeatureArchive Æ OfflineFacility (Ancestors - Abstract)
CPCable – (Child - Example)
PIGStructure – (Child – Example)
Attributes: SiteEventID (GUID, String, 38, FK) – Indicates the site (e.g.
(name, type, length, precision, scale,
compressor station, meter station, custody transfer station,
domained, notes)
storage yard, etc.) the facility belongs to or is contained within.
By utilizing this attribute online or offline facilities features can
be placed or located without the need for geometry. This concept
is outlined in the section ‘Non Geometric Features’.
Relationships: Site<OffilneNonPointFacility class name> (core):
(cardinality, optionality, composite,
<OfflineNonPointFacility class name> is M:1 with Site.
inheritance)
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.
May 2007
46
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
PigStructure). The OfflineNonPointFacility abstract class inherits the in-service date,
installation date and operational status attributes of the OfflineFacility APDM Abstract
class and thus is treated as a facility. The OfflineNonPointFacility class enables a
relationship to the Site class through the SiteEventID attribute. This relationship allows
OfflineNonPointFacility features to be located within a Site. Once stored in a Site, the
geometry for the features becomes optional. The Site becomes the container for these
features and the relationship between the Site and the features provides the ability to
generate a manifest of all features contained within the Site.
10.2.5.14 OfflinePointFacility
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
OfflinePointFacility
Implemented as an Non-M Aware Point feature class
ESRI Simple Object Æ ESRI Simple Feature (Optional) Æ
FeatureArchive Æ OfflineFacility (Ancestors - Abstract)
CPAnode – (Child - Example)
CPBond – (Child – Example)
CPGroundBed – (Child – Example)
CPRectifier – (Child – Example)
CPTestStation – (Child – Example)
Marker – (Child – Example)
Attributes: SiteEventID (GUID, String, 38, FK) – Indicates the site (e.g.
(name, type, length, precision, scale,
compressor station, meter station, custody transfer station,
domained, notes)
storage yard, etc.) the facility belongs to or is contained within.
By utilizing this attribute online or offline facilities features can
be placed or located without the need for geometry. This concept
is outlined in the section ‘Non Geometric Features’.
SymbolRotation (Double, 15, 2), gnAngle (required APDM
domain) - A rotation angle from 0–360o for a point symbol (uses
gnAngle domain). This allows operators to preserve rotation
information for point symbols imported from external systems
such as CADD. Allows all point symbols within the APDM to be
rotated as needed; manually, or in relation to other features. This
is used primarily for display in mapping applications such as
alignment sheets.
Relationships: Site<OfflinePointFacility class name> (core): <OfflinePointFacility
(cardinality, optionality, composite,
class name> is M:1 with Site.
inheritance)
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
ESRI Technical Paper
47
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
OfflinePointFacility abstract class inherits the in service date, installation date and
operational status attributes of the OfflineFacility abstract class and thus is treated as a
facility. Like OfflineNonPointFacility, the OfflinePointFacility class enables a
relationship to the Site class through the SiteEventID attribute. This relationship allows
OfflinePointFacility features to be located within a Site. Once stored in a Site, the
geometry for the features becomes optional. The Site becomes the container for these
features and the relationship between the Site and the features provides the ability to
generate a manifest of all features contained within the Site.
10.2.5.15 OnlineFeature
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
Attributes:
OnlineFeature
Implemented as an M-Aware Polyline feature or an M Aware Point
feature class or an Object Class representing an event table.
ESRI Simple Object Æ ESRI Simple Feature (Optional) Æ
FeatureArchive (Ancestors – Abstract)
CLEditResponse (Long Integer, 9) clEditResponse (required
(name, type, length, precision, scale,
APDM Domain) – Indicates how the geometry and/or stationing
domained, notes)
attributes of an online feature respond to a centerline edit such as
a reroute. This attribute is further described in the section
‘Feature Level Metadata’.
CLValidityTolerance (Double 15,2) – Indicates how far the
centerline can move away from an online event feature before
the event becomes ‘invalid’. Expressed the distance units of the
Transmission feature dataset. This attribute is further described
in the section ‘Feature Level Metadata’.
StationSeriesEventID (GUID, String, 38, FK) – Foreign key to the
primary reference mode (PRM) station series that addresses the
location of the online feature.
Relationships: StationSeries<OnlineFeature class name> (core): <OnlineFeature
(cardinality, optionality, composite,
class name> is M:1 with StationSeries.
inheritance)
<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
May 2007
48
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
geometrically constrained are linear features that share not only the edge of the centerline
but also every intervening vertex between the start and endpoint of the linear feature
which is shared with the station series feature.
All online features must have a StationSeriesEventID attribute that identifies a unique
route feature (i.e. station series) on which the feature is located. The
StationSeriesEventID attribute is a foreign key to the StationSeries feature class. The
related parent station series feature must belong to the PRM (or default subtype) of the
StationSeries feature class. The CLEditResponse and CLValidityTolerance attributes
describe what happens to the online feature when the underlying station series feature is
edited at the LineLoop level. These attributes define how and if the feature is re-built on
the centerline during a reroute.
The abstract classes that inherit from OnlineFeature describe the stationing attributes
required for online point and polyline features.
10.2.5.16 OnlinePolyline
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
OnlinePolyline
Implemented as an M-Aware Polyline feature or an Object Class
representing an Event table.
ESRI Simple Object Æ ESRI Simple Feature (Optional) Æ
FeatureArchive Æ OnlineFeature (Ancestors – Abstract)
DOTClass – (Child - Example)
HCARange – (Child - Example)
HCASegment – (Child - Example)
CouldAffectSegment – (Child – Example)
InspectionRange – (Child - Example)
OperatingPressure – (Child - Example)
PressureTest – (Child - Example)
RightOfWay – (Child - Example)
RiskAnalysis – (Child - Example)
Attributes: BeginStation (Double, 15, 2) - A station value (measure) along a
(name, type, length, precision, scale,
station series used to position and locate the start of the linear
domained, notes)
feature.
EndStation (Double, 15, 2) – A station value (measure) along a
station series used to position and locate the end of the linear
feature.
GroupEventID (GUID, String, 38) – Used to aggregate or
generalize two or more online polyline features together as a
single unit for the purposes of querying, reporting and
calculating distances or lengths. Primarily used for online
polyline features that are broken apart on interrupted style
primary reference modes.
ESRI Technical Paper
49
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Status (Long Integer, 9) gnStatus (required APDM domain) –
Defines the status of an object within the APDM. Status is used
to describe the state of a non-facility or centerline object (i.e. an
object that has no operational significance or does not exist as a
geographical or physical entity). The gnStatus domain is
considered a core APDM domain and must be implemented
using the specified values exactly as prescribed by the APDM.
Relationships: Each and every OnlinePolyline may have zero or more
(cardinality, optionality, composite,
OnlinePolyline or OnlinePoint features (M-1)
inheritance)
SubTypes: -The OnlinePolyline APDM abstract class encapsulates the stationing and status behavior
of non-facility online polyline features. The term non-facility means representative
phenomena opposed to actual phenomena. Representative phenomena are organizational
or categorical features as defined by an operator. An InspectionRange is an arbitrarily
assigned reach along the pipeline defined by a start and stop position. The feature itself
does not exist in reality other than as a designation. Alternately, online facility objects do
exist in reality and can be visually examined and manipulated in the real world. To this
end, the Status of OnlinePolyline features is tracked as opposed to the OperationalStatus
that is used for facility features. Online linear features are stored in an M Aware
(optionally Z-Aware) polyline feature class or as an Event table containing events that are
geometrically constrained and coincident with the centerline. Online linear features are
located by linear referencing using a StationSeriesEventID that is inherited from
OnlineFeature and two station value fields.
OnlinePoint and OnlinePolyline features may be derived from other online point or
polyline features. In this case, the OnlinePolyline represents an additional location or
alternate geometric representation of the other online feature. Two good examples of this
are the representation of a valve as both a point and polyline feature. Valves often have a
length attribute which may be required for calculation of Maximum Allowable Operating
Pressure (MAOP). In this example the Valve inherits from the OnlinePointFacility class
but has a related set of features stored in a feature class that inherits from the
OnlinePolyline abstract class. The attributes describing the valve are stored in the Valve
point feature class but the visual and graphic representation of the length of the valve is
stored in a separate ValveLength feature class. The ValveLength feature class inherits
from OnlinePolyline and is related (M-1) to the Valve feature class. Similarly, a Leak
feature inheriting from the OnlinePoint Abstract Class may be related to a
LeakAreaOfEffect feature class that inherits from the OnlinePolyline abstract class.
Relationships between online feature classes and offline feature classes representing
alternate or additional locations for those classes are defined in the APDM Metadata table
OnlineLocationClass.
10.2.5.17 OnlinePolylineForOfflineFeature
May 2007
50
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
OnlinePolylineForOfflineFeature
Implemented as an M-Aware Polyline feature or an Object Class
representing an Event table.
ESRI Simple Object Æ ESRI Simple Feature (Optional) Æ
FeatureArchive Æ OnlineFeature Æ OnlinePolyline (Ancestors –
Abstract)
LineCrossingEasement (Child – Example)
Attributes: BeginOffsetAngle (Double, 15, 2) - The angle of the vector from
(name, type, length, precision, scale,
the end point of an online polyline on the centerline to an offline
domained, notes)
feature. The angle is measured from the upstream vector of the
centerline. BeginOffsetAngle is only used if the online feature is
acting as an online location for an offline point or offline linear
feature.
BeginOffsetDistance (Double, 15, 2) - The distance of the end point
of an online polyline to the offline feature. BeginOffsetDistance
is only used if the polyline feature is acting as an online location
for an offline point or linear feature.
EndOffsetAngle (Double, 15, 2) - The angle of the vector from the
end point of an online polyline on the centerline to an offline
feature. The angle is measured from the upstream vector of the
centerline. EndOffsetAngle is only used if the online feature is
acting as an online location for an offline point or offline linear
feature.
EndOffsetDistance (Double, 15, 2) - The distance of the end point
of an online polyline to the offline feature. EndOffsetDistance is
only used if the polyline feature is acting as an online location
for an offline point or linear feature.
<OfflineFeature>EventID (GUID, String, 38, FK) – Indicates the
EventID value of the related offline feature class for which the
OnlinePolyline is representing an online location. The
<OfflineFeature> represents the name of the offline feature class.
Relationships: Each and every OnlinePolylineForOfflineFeature must be the
(cardinality, optionality, composite,
online location for one and only one offline feature (M-1).
inheritance)
SubTypes: -The OnlinePolylineForOfflineFeature (OPFOF) APDM abstract class encapsulates the
attributes and relationships that define the online polyline location for an offline feature.
The OPFOF abstract class inherits from OnlinePolyline and therefore has the default
begin and end station positions to store the start and stop positions of the online location
along the centerline. Online linear features can act as online locations for both offline
polyline and offline polygon features. For the former, the online polyline location feature
might represent the easement to either side of where the offline linear feature intersects
the centerline; for the latter, the online polyline location feature represents the overlap of
the polygon on the centerline or the range of intersection of the centerline by the polygon.
ESRI Technical Paper
51
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
The OPFOF class contains begin and end offset angle and distance information as well.
Often an online location can be generated from an offline feature that does not intersect
the centerline, or is not located within a specific distance from the centerline and
therefore requires an offset bearing and distance from the centerline to define the begin
and end positions of the offline feature.
10.2.5.18 OnlinePoint
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
OnlinePoint
Implemented as an M-Aware Point feature or an Object Class
representing an Event table.
ESRI Simple Object Æ ESRI Simple Feature (Optional) Æ
FeatureArchive Æ OnlineFeature (Ancestors – Abstract)
Anomaly – (Child - Example)
AnomalyCluster – (Child - Example)
ElevationPoint – (Child - Example)
Leak – (Child - Example)
Attributes: Station (Double, 15, 2) – A station value (i.e. measure) along a
(name, type, length, precision, scale,
station series used to position and locate the point feature.
domained, notes)
Status (Long Integer, 9) gnStatus (required APDM domain) –
Defines the status of an object within the APDM. Status is used
to describe the state of a non-facility or centerline object (i.e. an
object that has no operational significance or does not exist as a
geographical or physical entity). The gnStatus domain is
considered a core APDM domain and must be implemented
using the specified values exactly as prescribed by the APDM.
SymbolRotation (Double, 15, 2), gnAngle (required APDM
domain) - A rotation angle from 0–360o for a point symbol (uses
gnAngle domain). This allows operators to preserve rotation
information for point symbols imported from external systems
such as CADD. Allows all point symbols within the APDM to be
rotated as needed; manually, or in relation to other features. This
is used primarily for display in mapping applications such as
alignment sheets.
Relationships: Each and every OnlinePoint may be represented by zero or more
(cardinality, optionality, composite,
OnlinePolyline or OnlinePoint alternative geometries (M-1)
inheritance)
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
May 2007
52
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
designation. Alternately, online facility objects do exist in reality and can be visually
examined and manipulated in the real world. To this end, the Status of OnlinePoint
features is tracked as opposed to the OperationalStatus that is used for facility features.
Online point features are stored in an M-Aware (optionally Z-Aware) point feature class
that is geometrically coincident with the centerline. Online point features are located by
linear referencing using a StationSeriesEventID (inherited from OnlineFeature) and a
Station value. Online point features can be used to model concrete features that occur
along the centerline or as online locations for offline point or offline polyline features.
OnlinePoint features can represent the online location for other online location features.
An example of this is given in the descriptive notes for the OnlinePolyline APDM
Abstract Class.
10.2.5.19 OnlinePointForOfflineFeature
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
OnlinePointForOfflineFeature
Implemented as an M-Aware Point feature or an Object Class
representing an Event table.
ESRI Simple Object Æ ESRI Simple Feature (Optional) Æ
FeatureArchive Æ OnlineFeature Æ OnlinePoint (Ancestors –
Abstract)
CPLocation (Child – Example)
FieldNoteLocation (Child – Example)
LineCrossingLocation (Child – Example)
MarkerLocation (Child – Example)
StructureLocation (Child – Example)
Attributes: <OfflineFeature>EventID (GUID, String, 38, FK) – Indicates the
(name, type, length, precision, scale,
EventID value of the related Offline feature class for which the
domained, notes)
OnlinePoint is representing a online location. The
<OfflineFeature> represents the name of the Offline feature
class.
OffsetAngle (Double, 15, 2) – The angle of the vector from the
online point location on the centerline to the offline feature. The
angle is measured from the upstream vector of the centerline.
This is only used if the online feature is acting as an online
location for an offline point or offline linear feature.
OffsetDistance (Double, 15, 2) – The distance from the online point
to the offline feature This is only used if the point feature is
acting as an online location for an OfflinePoint or linear feature.
StationLocated (Long Integer, 9) gnYesNo – Indicates whether the
online location representation of the offline feature is based on a
reported station value (as opposed to, for instance, being based
on a closest distance calculation). When StationLocated is ‘Yes’,
the station value of the online location feature must be retained
(regardless of centerline edits, etc.).
ESRI Technical Paper
53
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Relationships: Each and every OnlinePointForOfflineFeature must be the online
location for one and only one Offline feature (M-1).
SubTypes: --
(cardinality, optionality, composite,
inheritance)
The OnlinePointForOfflineFeature (OPtFOF) APDM abstract class encapsulates the
attributes and relationships that define the online point location for an offline feature. The
OPtFOF abstract class inherits from OnlinePoint and therefore has the station position
defined by the online location of the point along the centerline. Online point features can
act as online locations for offline polyline, point and polygon features. The online point
location feature might represent the intersection of the offline polyline and the centerline
or the closest point on the centerline to an offline point, polyline, and/or polygon. The
OPtFOF class contains offset angle and distance information as well. Often an online
location can be generated from an offline feature that does not intersect the centerline, or
is not located within a specific distance from the centerline. This scenario requires an
offset bearing and distance from the centerline to define the position of the offline
feature. The offset angle is the angle of the line drawn from the point on the centerline to
the offline feature. The offset angle is measured from the centerline, looking toward the
increasing station values.
10.2.5.20 OnlineFacility
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
Attributes:
(name, type, length, precision, scale,
domained, notes)
May 2007
OnlineFacility
Implemented as an M-Aware Polyline feature class, an M-Aware
Point feature class or an Object class representing an Event table.
ESRI Simple Object Æ ESRI Simple Feature (Optional) Æ
FeatureArchive Æ OnlineFeature (Ancestors - Abstract)
InServiceDate (Date) - Represents the date a piece of equipment is
actually put in service and is used primarily for accounting
purposes. The date in the InServiceDate field may be later than
the installation date.
InstallationDate (Date) - The date a piece of equipment is installed.
Note that InstallationDate is important for risk analysis.
OperationalStatus (Long Integer, 9) gnOperationalStatus (required
APDM domain) – A domain value indicating the status of a
feature that has some operational lifespan based on FERC/OPS
definitions. OperationalStatus is applied to centerline features or
facility features with complex operational life spans. The
gnOperationalStatus domain is considered a core APDM domain
that inherits values from the gnStatus domain and must be
implemented exactly as prescribed by the APDM.
SiteEventID (GUID, String, 38, FK) – Indicates the site (i.e.
compressor station, meter station, custody transfer station,
storage yard, etc.) that the facility belongs to or is contained
54
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
within. By utilizing this attribute online or offline facilities
features can be placed or located without the need for geometry.
This concept is outlined in the section ‘Non Geometric Features’.
Relationships: Site<OnlineFacility class name>: <OnlineFacility class name> is
(cardinality, optionality, composite,
M:1 with Site.
inheritance)
SubTypes: -The OnlineFacility APDM abstract class encapsulates the attributes and relationships that
define an online feature representing a facility. Facility objects are those representing real
features in the world such as pipes, coatings, taps, tees and valves. Facilities are primarily
defined by the InServiceDate, InstallationDate and OperationalStatus attributes which
determine the operational and lifespan properties of the feature. The foreign key attribute
SiteEventID provides the capability for facilities to be stored or contained as objects with
or without geometry within a Site feature. The OnlineFacility abstract class also
incorporates inherited online behavior such as a relationship with the StationSeries
feature class.
10.2.5.21 OnlinePolylineFacility
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
OnlinePolylineFacility
Implemented as an M-Aware Polyline feature or an Object Class
representing an Event table.
ESRI Simple Object Æ ESRI Simple Feature (Optional) Æ
FeatureArchive Æ OnlineFeature Æ OnlineFacility (Ancestors –
Abstract)
Casing – (Child - Example)
Coating – (Child - Example)
PipeSegment – (Child - Example)
Sleeve – (Child - Example)
Attributes: BeginStation (Double, 15, 2) - A station value (i.e. measure) along
(name, type, length, precision, scale,
a station series used to position and locate the start of the linear
domained, notes)
feature.
EndStation (Double, 15, 2) – A station value (i.e. measure) along a
station series used to position and locate the end of the linear
feature.
GroupEventID (GUID, String, 38) – Used to aggregate or
generalize two or more online polyline features together as a
single unit for the purposes of querying, reporting and
calculating distances or lengths. Primarily used for online
polyline features that are broken apart on interrupted style
primary reference modes.
Relationships: None.
(cardinality, optionality, composite,
inheritance)
SubTypes: --
ESRI Technical Paper
55
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
The OnlinePolylineFacility APDM abstract class differentiates the stationing
requirements for a polyline from those required by an OnlinePointFacility.
OnlinePolylineFacility features act as OnlinePolylines with inherited OnlineFacility
properties such as InServiceDate, InstallationDate, OperationalStatus and SiteEventID.
10.2.5.22 OnlinePointFacility
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
OnlinePointFacility
Implemented as an M-Aware Point feature or an Object Class
representing an Event table.
ESRI Simple Object Æ ESRI Simple Feature (Optional) Æ
FeatureArchive Æ OnlineFeature Æ OnlineFacility (Ancestors –
Abstract)
Appurtenance – (Child - Example)
Instrument – (Child - Example)
PipeJoinMethod – (Child - Example)
Tap – (Child - Example)
Valve – (Child - Example)
Vessel – (Child, Example)
Attributes: Station (Double, 15, 2) – A station value (i.e. measure) along a
(name, type, length, precision, scale,
station series used to position and locate the point feature on the
domained, notes)
centerline.
SymbolRotation (Double, 15, 2), gnAngle (required APDM
domain) - A rotation angle from 0–360o for a point symbol (uses
gnAngle domain). This allows operators to preserve rotation
information for point symbols imported from external systems
such as CAD. Allows all point symbols within the APDM to be
rotated as needed; manually, or in relation to other features. This
is used primarily for display in mapping applications such as
alignment sheets.
Relationships: None
(cardinality, optionality, composite,
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.23 Fitting
May 2007
56
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
Fitting
Implemented as an M-Aware Point feature or an Object class
representing an Event table.
ESRI Simple Object Æ ESRI Simple Feature (Optional) Æ
FeatureArchive Æ OnlineFeature Æ OnlineFacility Æ
OnlinePointFacility (Ancestors – Abstract)
Closure – (Child - Example)
Elbow – (Child - Example)
Meter – (Child - Example)
Reducer – (Child - Example)
Tee – (Child - Example)
Attributes: DateManufactured (Date) – The date the fitting or facility was
(name, type, length, precision, scale,
manufactured.
domained, notes)
Grade (Long Integer, 9) fcGrade - The grade at which the fitting
material is rated (e.g. SMYS 40 KSI)
InletConnectionType (Long Integer, 9) fcConnectionType - The
inlet connection type (e.g. weld, thread).
InletDiameter (Long Integer, 9) fcDiameter - The diameter of the
inlet opening.
InletWallThickness (Long Integer, 9) fcWallThickness - The wall
thickness around the inlet opening.
Manufacturer (Long Integer, 9) fcManufacturer - The manufacturer
of the fitting.
Material (Long Integer, 9) fcMaterial - The material the material
from which the fitting is made (e.g. PVC, steel).
PressureRating (Long Integer, 9) fcPressureRating - The pressure
rating of the fitting.
Specification (Long Integer, 9) fcSpecification - The machine
specification of the fitting (e.g. ANSI, API 5).
Relationships: None
(cardinality, optionality, composite,
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.
ESRI Technical Paper
57
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
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 classlevel metadata storage include: 1) extensions to XML-based ESRI class metadata (as
exposed in ArcCatalog), 2) object classes implemented within the geodatabase itself, and
3) simple relational tables stored in the database hosting the APDM. The APDM
technical committee chose to implement class-level metadata as geodatabase object
classes because they are easily maintained with out-of-the-box ESRI tools. In addition, at
ArcGIS 9.2, geodatabase object classes can be queried and updated directly via SQL.
Because the APDM class-level metadata object classes store information intrinsic to the
behavior of the database, they should not be registered as versioned. Indeed, class-level
metadata should not be altered after the geodatabase is initially populated.
10.3.1 Class-level Metadata
Three metadata tables (object classes) are implemented in the APDM schema:
ReferenceMode, APDMClass and OnlineLocationClass. These tables are required classes
in the APDM. ReferenceMode stores metadata pertaining to the reference modes
common to the ControlPoint, StationSeries and AltRefMeasure classes. (Reference
modes represent different methods of recording station values and how these values are
applied at the LineLoop level.) APDMClass stores which APDM abstract class is
associated with every object and feature class in the geodatabase. While it is possible to
determine which abstract class an APDM object or feature class belongs to by examining
attribute and relationship content, the APDMClass table stores this information
permanently for ready access. OnlineLocationClass stores the relationships of ‘online
location’ classes to their parent ‘offline’ classes. Again, while it is possible to traverse
these relationships on-the-fly, OnlineLocationClass stores this information permanently
for ready access.
10.3.1.1 ReferenceMode
Class Name:
Feature Class
Geometry:
Feature Dataset:
APDM Class
Type:
Attributes:
May 2007
ReferenceMode
Object Class
--CalculateARM (Long Integer, 9) – gnYesNo (Default 1=Yes) –
58
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
(name, type, length, precision, scale,
domained, notes)
Indicates whether AltRefMeasure values are populated for the
reference mode for features stored in a class inheriting from the
‘OnlineFeature’ APDM abstract class.
RefModeSubTypeValue (Long Integer, 9) – The value of the
ControlPoint/StationSeries SubType representing the reference
mode.
RefModeSubTypeDescription (string, 45) – The description or
name of the reference mode equal to the description of the
subtype value for the ControlPoint/StationSeries feature classes.
RefModeUnits (Long Integer, 9) – gnRefModeUnits (Default
0=esriUnknownUnits) – describes the units that the stationing
values for a reference mode represent.
RefModeBasis (Long Integer, 9) – gnRefModeBasis (Default
0=Unknown) – Describes the basis from which station values are
specified or derived for a given reference mode.
RefModeType (Long Integer, 9) – gnRefModeType (Default
1=Uninterrupted and Adjustable) – Describes the behavior of the
centerline stationing when a reroute is performed on a LineLoop.
Also defines if station equations can exist for a given reference
mode.
Relationships: ReferenceModeControlPoint (core): ReferenceMode is 1:M with
(cardinality, optionality, composite,
ControlPoint.
inheritance)
ReferenceModeStationSeries (core): ReferenceMode is 1:M with
StationSeries.
ReferenceModeAltRefMeasure (core): ReferenceMode is 1:M with
AltRefMeasure.
SubTypes: --
The ReferenceMode table stores the metadata defining each reference mode implemented
in an APDM geodatabase. Reference mode subtypes are found in ControlPoint,
StationSeries and AltRefMeasure. Reference modes are applied to the entire geodatabase.
Each StationSeries feature must belong to one and only one LineLoop object and must
implement one of the defined reference modes. Each ControlPoint feature must belong to
one and only one StationSeries feature and must implement one of the defined reference
modes. Each StationSeries feature must be composed of two or more related ControlPoint
features to establish the stationing for the reference mode defining the StationSeries
feature.
The default subtype value for ControlPoint, StationSeries and AltRefMeasure must all be
the same; this reference mode is designated as the ‘Primary Reference Mode’ (PRM).
Other implemented reference modes are referred to as ‘Alternate Reference Modes’
(ARM’s). Any ARM ControlPoint feature must have a corresponding PRM ControlPoint
feature. All online event features in the geodatabase must be stored using the PRM and
related to appropriate PRM StationSeries features.
ESRI Technical Paper
59
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Reference mode distance units are stored in the RefModeUnits field of ReferenceMode.
They are stored explicitly because the reference mode distance units do not necessarily
conform to the units of the spatial reference for the Transmission feature dataset. For
instance, the spatial reference units of the Transmission feature dataset might be decimal
degrees whereas the distance units of one of the references modes might be meters. The
contents of the gnRefModeUnits domain correspond to the values found in the
ArcObjects esriSRUnitType enumeration. This facilitates easy programmatic
manipulation of data based on the information stored in RefModeUnits.
RefModeBasis stores a coded value defining the physical basis upon which station values
(measures) are accumulated for a particular reference mode. Station values are most
commonly collected in the field during construction by physically measuring the length
of the pipeline (3D Slack Chain basis). However, using ArcToolbox geoprocessing tools
it is possible to calculate station values using a variety of methods. The most common
method in the industry for calculating stationing is to compute it as 2D horizontal
distance in a specified projection system, i.e. ‘horizontal stationing’ (2D Projected basis).
Station values may also be calculated by draping the pipeline over a Digital Elevation
Model (DEM) (3D Projected basis), or by calculating distances on the geoid (3D Geoid
basis).
Some reference modes may start with a defined physical basis, but because of their
behavior during reroute operations, become fundamentally ‘arbitrary’ in terms of
physical basis (Arbitrary basis). An example of a reference mode with an arbitrary basis
is Milepost. Milepost markers are placed at fixed locations; each time a pipeline reroute
is performed the physical distance between affected mileposts changes. The Milepost
measurement system is therefore ‘arbitrary’. Examples of all of the currently defined
ReferenceModeBasis codes are illustrated below:
May 2007
60
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
ESRI Technical Paper
61
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
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 twopoint 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.
May 2007
62
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Examples of reference modes that are Uninterrupted and Adjustable include PODS
Continuous Measure and ISAT NET stationing, as depicted below:
ESRI Technical Paper
63
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
An example of an Uninterrupted and Not Adjustable reference mode is Milepost, as
shown below:
May 2007
64
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Valve Section (valve + offset) is an example of an Interrupted and Adjustable reference
mode, as illustrated below:
ESRI Technical Paper
65
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
The ubiquitous Engineering Stationing reference mode is an example of an Interrupted
and Not Adjustable reference mode, as shown below:
May 2007
66
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
10.3.1.2 APDMClass
Class Name:
Feature Class
Geometry:
Feature Dataset:
APDM Class
Type:
Attributes:
APDMClass
Object Class
---
ClassEventID (GUID, String 38) – A unique identifier for the class.
ClassName (String, 28) – The name of the class as derived from the
ESRI.ArcGIS.Geodatabase.IDataset.Name property for the
ObjectClass or FeatureClass.
APDMClassType (Long Integer, 9) – gnAPDMClassType –
Denotes the APDM Abstract class that is the direct ancestor of
the object/feature class.
RequiresGeometry (Long Integer, 9) – gnRequiresGeometry –
Indicates whether the class is stored using geometry, or as an
object for use as a route event.
Relationships: APDMClassOriginClass (core): APDMClass is 1:M with
(cardinality, optionality, composite,
OnlineLocationClass
inheritance)
APDMClassOnlineClass (core): APDMClass is 1:M with
OnlineLocationClass
APDMClassAltRefMeasure (core): APDMClass is 1:M with
AltRefMeasure
APDMClassCPLocation: APDMClass is 1:M with CPLocation
APDMClassRemovedPoint: APDMClass is 1:M with
RemovedPoint
APDMClassRemovedLine: ADPMClass is 1:M with RemovedLine
SubTypes: --
(name, type, length, precision, scale,
domained, notes)
APDMClass stores metadata describing the abstract class type of each object and feature
class in the APDM schema. The primary purpose of the table is to provide a permanent
repository for this information so that users and application developers are spared the task
of parsing the attribute and relationship content of the APDM classes to determine their
abstract class type. The gnRequiresGeometry domain is core and includes the following
values: -1=Unknown (Verified), 0=Unknown, 1=Must Have, 2=Must Not Have,
3=Optional.
The APDMClassOriginClass and APDMClassOnlineClass relationships do not
completely embody the restrictions on the relationships of APDM offline classes to
online location classes. In practice, while an APDM offline class can have multiple
online location classes associated with it, an online location class can only be associated
with one parent APDM offline class,
ESRI Technical Paper
67
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
The following class types are codes that are delineated for the APDMClassType field:
•
•
•
•
•
•
•
•
•
•
•
APDMObject
CenterlineObject
NonFacilityObject
CenterlinePolyline
CenterlinePolylineEvent
CenterlinePoint
OfflineFeature
OfflinePoint
OfflineFacility
OfflinePointFacility
OfflineNonPointFacility
•
•
•
•
•
•
•
•
•
•
OnlineFeature
OnlinePolyline
OnlinePolylineForOfflineFeature
OnlinePoint
OnlinePointForOfflineFeature
OnlineFacility
OnlinePolylineFacility
OnlinePointFacility
Fitting
Audit
10.3.1.3 OnlineLocationClass
Class Name:
Feature Class
Geometry:
Feature Dataset:
APDM Class
Type:
Other Notes:
Attributes:
OnlineLocationClass
Object Class
---
-OriginClassEventID (GUID) – A unique identifier for the ‘offline’
(name, type, length, precision, scale,
parent class.
domained, notes)
OnlineClassEventID (GUID) – A unique identifier for the ‘online
location’ child class.
OnlineLocationMechanism (Long Integer, 9) gnOnlineLocationMechanism (Default 0=Unknown) – The
mechanism used to derive the ‘online location’ feature(s) for an
‘offline’ feature.
Relationships: APDMClassOriginClass (core): OnlineLocationClass is M:1 with
(cardinality, optionality, composite,
APDMClass
inheritance)
APDMClassOnlineClass (core): OnlineLocationClass is M:1 with
APDMClass
SubTypes: -OnlineLocationClass stores the ClassEventID for the offline and online classes involved
in an ‘offline’ and ‘online location’ relationship. As noted above, the
APDMClassOriginClass and APDMClassOnlineClass relationships do not completely
embody the restrictions on the relationships of APDM offline classes to online location
classes. First, only offline classes should appear in OriginClassEventID. Second, while an
May 2007
68
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
APDM offline class can have multiple online location classes associated with it, an online
location class can only be associated with one parent APDM offline class, The offline
class must inherit from the OfflineFeature or OfflineFacility APDM abstract classes, or
their descendants. The online class must inherit from either the
OnlinePolylineForOfflineFeature or OnlinePointForOfflineFeature APDM abstract
classes. The relationship of online location feature classes to offline feature classes is
depicted below:
ESRI Technical Paper
69
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
The OnlineLocationMechanism attribute contains coded values indicating how the
location of the ‘online location’ feature is derived from the ‘offline’ feature. Choices
include:
May 2007
70
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
•
ClosestPoint – the closet point on a centerline from an offline point or polygon.
•
DistanceAzimuth – the online point, angle and distance used to locate an offline
feature and vice versa.
•
BufferIntersection – the intersection of the centerline with a buffer derived from
an offline point, polygon or polyline.
•
PolygonIntersection – the intersection of an offline polygon and the centerline.
•
PointIntersection – the intersection of an offline polyline and the centerline.
•
PolylineEasement – the easement calculated from either side of the intersection
point of an offline polyline and the centerline.
•
PointEasement – the easement calculated on either side of an online point
feature.
•
PolylineEndpoint – an online point location calculated to cover the endpoint(s)
of an online polyline feature.
•
PolylineCenterpoint – an online point location calculated at the midpoint (as
determined by station value) of an online polyline feature.
•
AggregatePoint – an online point location calculated at the midpoint (as
determined by the average or mean station value) of a collection of online point
features.
•
AggregatePolyline – an online polyline feature calculated as an aggregation of a
collection of online polyline features.
The behavior of each of the above OnlineLocationMechanism codes is depicted in the
following diagrams:
ESRI Technical Paper
71
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
May 2007
72
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
ESRI Technical Paper
73
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
May 2007
74
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
ESRI Technical Paper
75
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
May 2007
76
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
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.
ESRI Technical Paper
77
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
10.3.2.1 Online Event Feature-Level Metadata Attributes
Two feature-level metadata attributes define the behavior of online event features during
centerline edits: CLEditResponse and CLValidityTolerance. CLEditResponse describes
how the location of a stationed feature responds to a centerline edit. CLValidityTolerance
describes how far the centerline can move away from an event located by X/Y before the
event location becomes ‘invalid’ relative to the centerline. These two attributes are
defined for the OnlineFeature APDM abstract class and are inherited by its descendents
(OnlinePolyline, OnlinePoint, OnlinePolylineForOfflineFeature,
OnlinePointForOfflineFeature, OnlinePolylineFacility, OnlinePointFacility, and Fitting).
CLEditResponse contains coded values that determine how the position of an online
feature is calculated in response to a centerline edit that changes the shape of the
centerline or alters the station values of ControlPoint features in the vicinity of the
affected feature. The following CLEditResponse codes and resulting behaviors are
defined:
•
Relative – The location of an event is determined solely by Station value(s). If the
centerline moves, the event moves with it. If Station values on the nearest
surrounding ControlPoint features are altered, the position of the event slides up
or down the centerline accordingly. This is the default behavior for any event
where the only source data for positioning is stationing.
•
Proportional – The location of an event must fall on the centerline, but its
position is determined by its proportional distances from the nearest surrounding
ControlPoint features. If the centerline moves, the event moves with it. The
event’s proportional distances from the nearest surrounding ControlPoint features
remain constant. If the Station value(s) of the nearest surrounding ControlPoint
features change, the Station value(s) of the event changes accordingly, but its
proportional distances from the nearest surrounding ControlPoint features remain
constant. (The event’s proportional distances from the nearest surrounding
ControlPoint features always remain constant.) Example – data captured from
originally non-stationed systems, or from systems where stationing was unclear or
missing on source documents. ControlPoint station values may be adjusted over a
long period of time; events should not necessarily slide around when this occurs.
But events should move with the centerline if the centerline is moved.
•
Absolute – The location of an event is determined solely by its X/Y position. If
the centerline moves, the event location remains unchanged, even if that means
the event no longer falls on the centerline (see CLValidityTolerance). Station
value is always determined by interpolation from surrounding ControlPoint
features. Station value(s) for the event changes both when the centerline moves
and when Station values for surrounding ControlPoint features are adjusted.
Example – data positioned by GPS. In the case that the feature no longer falls on
the centerline then the feature could be ‘retired’ or ‘deleted’.
May 2007
78
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
The behavior of the ‘Relative’ and ‘Proportional’ CLEditResponse values with respect to
online features are illustrated in the following diagram:
ESRI Technical Paper
79
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
CLValidityTolerance applies only to online events with spatially fixed locations
(CLEditResponse = ‘Absolute’). Centerline edits may cause such events to no longer be
spatially coincident with the centerline. CLValidityTolerance defines the distance
tolerance between an event and the centerline beyond which the event’s location becomes
spatially ‘invalid’ by virtue of being positioned too far away from the centerline. Distance
units for CLValidityTolerance are the same as RefModeUnits of the Primary Reference
Mode.
With respect to the ‘Absolute’ value for CLEditResponse, one example of a use for it is
for ElevationPoint features derived from a Digital Elevation Model (DEM). The X/Y
locations of such points are known exactly and should not move with the centerline when
the centerline is edited. If the centerline is moved significantly then the DEM-derived
ElevationPoint features should become ‘invalid’, as depicted in the following illustration:
May 2007
80
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
ESRI Technical Paper
81
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
10.3.2.2 ControlPoint Feature-Level Metadata Attributes
Four feature-level metadata attributes define the behavior of ControlPoint features during
centerline edits: CLXYEditResponse, CLStationEditResponse, CLZEditResponse, and
CLControl. These attributes are defined in the CenterlinePoint APDM Abstract class.
The ControlPoint metadata attributes come into play during centerline edit operations that
change the locations or station values of ControlPoint features. ControlPoint metadata
attributes play no role in pipeline reroute operations (where a section of the centerline is
‘cut’ out or replaced. Reroute behavior is governed by class-level reference mode
metadata.) The behavior of online features during centerline edit operations is governed
according to their CLEditResponse codes and CLValidityTolerance values.
A ControlPoint feature is defined by its X position, Y position, Z (elevation) position,
and station value. Each of these properties represents a ‘degree of freedom’. If a
ControlPoint’s X, Y, Z and station values are freely altered, the ControlPoint enjoys four
basic degrees of freedom. The ControlPoint metadata attributes (excepting CLControl)
serve to define limits on the degrees of freedom available to a particular ControlPoint
feature.
CLXYEditResponse stores coded values that define how a ControlPoint feature is
allowed to move in the X/Y plane. Because the X/Y position of a ControlPoint feature
has relationships to the X/Y positions of the surrounding ControlPoint features,
delineating controls on the X/Y position of a ControlPoint is considerably more complex
than simply defining whether the ControlPoint is allowed to move in X or Y. The domain
for CLXYEditResponse has six values:
1. Assigned – The X/Y position of the ControlPoint may be freely adjusted.
2. Fixed Distance – For Fixed Distance, a ControlPoint can be moved, but the
distances to the surrounding ControlPoints must held constant. Deflection angle at
the ControlPoint in question can vary, though. FixedDistance can be applied to a
single ControlPoint or a group of two or more adjacent ControlPoints.
3. Fixed Deflection – With Fixed Deflection, a ControlPoint can be moved, but the
deflection angle at the ControlPoint relative to surrounding ControlPoints must
remain constant. Fixed deflection allows the preceding and following control
points to be translated in or out (in terms of distance from the FixedDeflection
ControlPoint). FixedDeflection can be applied to a single ControlPoint or a group
of two or more adjacent ControlPoints.
4. Fixed Inline – The ControlPoint can be moved, but it must always be inline with
surrounding ControlPoints. This addresses the concern about a Geographic
Positioning System (GPS) ControlPoint surrounded by Points of Inflection (P.I.s).
In this situation deflection must remain 0 for the point since it is a GPS
May 2007
82
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
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 asbuilt 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:
ESRI Technical Paper
83
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
May 2007
84
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
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:
ESRI Technical Paper
85
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
CLZEditResponse stores coded values that define how the elevation (Z) value of a
ControlPoint may be altered. ControlPoint feature elevation values may be partially
dependent on the elevations values of surrounding ControlPoints, as well as on
topography, thus complicating the definition of degrees of freedom for ControlPoint
elevation values. Because elevation values are optional in the APDM, one valid option is
to not assign elevation values, period. The domain for CLZEditResponse has five values:
May 2007
86
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
•
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.
ESRI Technical Paper
87
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
CLZEditResponse behavior is depicted below:
May 2007
88
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
CLControl stores a Yes/No value defining whether the ControlPoint participates in the
construction of the centerline StationSeries feature. The principal reason for
implementing CLControl is to handle the transition from traditional surveying methods to
modern differential GPS control in defining the centerline. Traditionally, the centerline is
represented as a traverse defined by a series of Points of Inflection (P.I.’s). P.I.’s are
actually survey artifacts with respect to the true location of the centerline; the centerline
does not actually pass through P.I.’s. Rather, the pipe bends that occur at the locations of
P.I.’s define an arc whose radius is inside the P.I. GPS points derived from field survey or
a geo-pig inline inspection can be used to approximate the arc to a greater degree of
precision than the P.I. does. As time goes by, one can expect to replace P.I. ControlPoint
features with differential GPS ControlPoint features. By setting CLControl to ‘No’ one
can maintain a P.I. ControlPoint for historical value, but not allow it to participate in the
construction of StationSeries features. CLControl behavior is illustrated below:
10.4 APDM Core Classes and Relationships
The APDM is designed to allow end users to modify the content of the model to meet
GIS, organizational, and business requirements. The model has core elements that must
remain consistent for each implementation of the APDM. These core elements are
required to maintain the semantic framework and behavior of the model, particularly with
respect to the centerline and the methodology for applying and using linear referencing
along the centerline.
ESRI Technical Paper
89
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
The feature/object classes and relationship classes described below are considered to be
the core elements of the APDM. For a particular APDM implementation to be considered
compliant, the APDM core classes must be implemented with the same names, attributes
and relationships as described here. (Naturally, the relationships associated with a
particular core class are required only if the object/feature class on the other side of the
relationship is implemented.)
In some cases, a core class implements a certain type of relationship class with one or
more classes of a particular type (i.e. the target class inherits from a given APDM
abstract class). As such, the associated relationship classes may be thought of as
belonging to a particular relationship type that in effect inherits from a species of abstract
relationship class. While the target classes of these relationship types may be optional, if
such a class is implemented, then a relationship of the associated relationship type must
also be implemented. In these situations, the relationship classes themselves are core to
the model and must be implemented in the way specified. For example, the core class
StationSeries implements a one-to-many relationship with all online feature classes. None
of the online feature classes are core to the model, but any time an online feature class is
implemented, the requisite relationship class with StationSeries must also be
implemented. Required relationship classes and relationship class types are clearly
identified by the designations: (core) and (core relationship type), respectively.
The core classes may be extended with additional attribute content or relationships as
desired, but their core attributes and relationship classes as described here must not be
removed. Beyond the core elements there are no required or mandated elements in the
model. End users are free to remove, add, or modify any of the suggested feature classes
and attributes except the core elements to build a model that meets their business needs.
The following APDM feature, object and attributed many-to-many relationship classes
are considered core elements of the model:
•
•
Object classes:
o Activity
o ActivityHierarchy
o AltRefMeasure
o <class name>Audit
o Company
o ExternalDocument
o LineLoop
o LineLoopHierarchy
o OwnerOperator
o Product
o SubSystem
o SubSystemHierarchy
Feature classes:
May 2007
90
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
o
o
o
o
ControlPoint
Site
StationSeries
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:
ESRI Technical Paper
91
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
May 2007
92
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
ESRI Technical Paper
93
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
10.4.1 EventID
All feature classes and object classes must have an attribute named EventID. This
attribute is defined as a Globally Unique Identifier (GUID), stored in the APDM as a
string field (string, 38). The purpose of the EventID attribute is to provide a mechanism
for uniquely identifying each feature or object in the geodatabase independent of the
feature or object class to which it belongs. EventID is specified in the Microsoft registry
GUID format ({xxxxxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx}) to make each object in any
class globally unique from all other features. Using GUIDs for unique identifiers ensures
that all features maintain a unique identifier even if they are exported from and imported
back into a geodatabase. Note that using a long integer or the Object ID does not
necessarily ensure global uniqueness or the preservation of a unique ID value assigned to
each feature on export and import. (Typically, long integer IDs are incremented from
zero in each database implementation, so primary key collision can easily occur during
database merges and imports.) Also note that the term "event" in EventID does not
denote that this attribute pertains to event tables or events only. EventID was chosen to
represent a global ID for any event that occurred on or along a pipeline system, be it an
online or offline feature. EventID may be thought of as synonymous with such terms as
"Feature ID" or "GeoEntityID".
10.4.2 Core Object Classes
10.4.2.1 Activity
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
Attributes:
(name, type, length,
precision, scale,
domained, notes)
Relationships:
(cardinality, optionality,
composite, inheritance)
May 2007
Activity
Implemented as an Object Class
ESRI Object Æ APDM Object Æ Object Archive Æ
NonFacilityObject (Ancestors – Abstract)
ActivityDate (date) – The date on which the activity occurred.
ActivityDescription (String, 120) – A description or categorization
of the activity.
ActivityName (String, 90) – A title or description of the activity.
ActivityType (Long Integer, 9) – gnActivityType – The type of
activity.
ActivityChildActivity (core): Activity is 1:M with
ActivityHierarchy
ActivityParentActivity (core): Activity is 1:M with
ActivityHierarchy
InspectionRangeActivity: InspectionRange is M:N with Activity
ActivityExternalDocument (core): Activity is M:N with
ExternalDocument
Activity<Object/feature class name>Audit (core relationship type):
Activity is 1:M with <Object/feature class name>Audit
94
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
SubTypes:
--
The Activity object class is used to track regular pipeline activities and the events that are
affected by those activities. Specifically, the rows in the Activity object class store
information pertaining to activities conducted on the pipeline that affect one or more
events or features on or along the pipeline. Common activities include work orders,
inspections, excavations, and tests.
The Activity object class has a one-to-many relationship with each <object/feature class
name>Audit object class. This relationship type is core to the model. Any object or
feature class that needs to be associated with Activity should implement an
<object/feature class name>Audit object class and the attendant Activity<object/feature
class name>Audit relationship class. These relationships model the fact that one activity
can be related to one or more events (of different types) that were affected by or
participated in the activity.
Activity has a many-to-many relationship with ExternalDocument, whereas many
documents might provide source materials to the activity. In turn, a single document
might be related to many activities. Activity has a one-to-many relationship with
InspectionRange indicating that a given inspection-related activity can occur over many
linear areas of the pipeline system.
The two one-to-many relationships of the Activity object class to the ActivityHierarchy
object class allows activities to be organized within an arbitrarily recursive hierarchy
(that is, the activity hierarchy can have as many levels as desired). For more information
on how this relationship structure works, see 10.4.2.2 ActivityHierarchy.
10.4.2.2 ActivityHierarchy
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
Attributes:
(name, type, length,
precision, scale,
domained, notes)
Relationships:
(cardinality, optionality,
ESRI Technical Paper
ActivityHierarchy
Implemented as an Object Class
ESRI Object Æ APDM Object (Ancestors – Abstract)
ParentActivityEventID (String, 38) – A foreign key to Activity
storing the EventID of an activity that represents a “parent”
hierarchy level to the activity identified by
ChildActivityEventID.
ChildActivityEventID (String, 38) – A foreign key to Activity
storing the EventID of an Activity that represents a “child”
hierarchy level to the activity identified by
ParentActivityEventID.
ActivityChildActivity (core): Activity is 1:M with
ActivityHierarchy
95
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
composite, inheritance)
SubTypes:
ActivityParentActivity (core): Activity is 1:M with
ActivityHierarchy
--
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
A
A
C
C
D
ChildActivityEventID
C
D
X
Y
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.
May 2007
96
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
10.4.2.3 AltRefMeasure
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
Attributes:
(name, type, length,
precision, scale,
domained, notes)
Relationships:
(cardinality, optionality,
composite, inheritance)
SubTypes:
ESRI Technical Paper
AltRefMeasure
Implemented as an Object Class
ESRI Object Æ APDM Object Æ Object Archive Æ
CenterlineObject (Ancestors – Abstract)
BeginStationSeriesEventID (String, 38) – The foreign key to the
Station Series feature associated with the begin station value
BeginStation (Double, 15, 2) – The station value for the beginning
of an Online Polyline feature, or the station value of an Online
Point feature.
EndStationSeriesEventID (String, 38) – The foreign key to the
Station Series feature associated with the end station value.
EndStation (Double, 15, 2) – The station value for the end of an
Online Polyline feature. For Online Point features, the value for
this attribute is the same as that for BeginStation.
TotalLength (Double, 15, 2) – The length (in measurement system
units) of an Online Polyline feature. For split Online Polyline
features, the aggregate length.
ClassEventID (String 38) – A unique identifier to the APDMClass
object class storing the feature class associated with the
AltRefMeasure record.
SubtypeCD (Long Integer, 9) – The subtype field. Each subtype
denotes a different type of stationing measurement.
ReferenceModeAltRefMeasure (core): ReferenceMode is 1:M with
AltRefMeasure
APDMClassAltRefMeasure (core): APDMClass is 1:M with
AltRefMeasure
BeginStationSeriesAltRefMeas (core): StationSeries is 1:M with
AltRefMeasure
EndStationSeriesAltRefMeas (core): StationSeries is 1:M with
AltRefMeasure
<Feature class name>AltRefMeasure (core relationship type):
<Feature class name> is M:N with AltRefMeasure
1 = Continuous
2 = Engineering
3 = Horizontal
4 = Milepost
5 = Slack Chain
6 = Valve Section
7 = Unspecified
97
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
The AltRefMeasure object class is designed to store stationing information for all
measurement systems for online feature classes. The Station attribute in Online Point
feature classes, and the BeginStation and EndStation attributes in Online Polyline feature
classes, store stationing values for the primary measurement system only. AltRefMeasure
provides a means for storing stationing values for alternative measurement systems, as
well as for the primary measurement system.
AltRefMeasure is related to each Online Point and Online Polyline feature class via a
many-to-many relationship class in the form <Feature class name>AltRefMeasure. For
each online feature, AltRefMeasure stores one record per APDM reference mode. In the
general case, each record in a feature class has many records in AltRefMeasure.
When the Primary Reference Mode is interruptible, Online Polyline features must be split
into multiple features if they cross one or more station equations (two or more Station
Series features). The GroupEventID attribute can be used to aggregate the split features.
AltRefMeasure is used to store the begin and the end station values for the aggregate
feature. In this case, one row in AltRefMeasure is related to many features in the
<Feature class name>AltRefMeasure relationship.
StationSeries implements one-to-many relationships with AltRefMeasure via the
BeginStationSeriesAltRefMeas and EndStationSeriesAltRefMeas relationship classes.
APDMClass implements a one-to-many relationship to AltRefMeasure via the
APDMClassAltRefMeasure relationship; this foreign key relationship allows the user to
easily query records in AltRefMeasure by feature class.
AltRefMeasure is subtyped in the same fashion as ControlPoint and StationSeries; each
subtype denotes a different reference mode. ReferenceModeAltRefMeasure ties
AltRefMeasure to the ReferenceMode object class through the SubtypeCD attribute;
ReferenceMode stores behavioral metadata for the reference mode.
10.4.2.4 <class name>Audit
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
Attributes:
(name, type, length,
precision, scale,
domained, notes)
May 2007
<class name>Audit
Implemented as an Object Class.
ESRI Object Æ APDM Object Æ Object Archive Æ
NonFacilityObject (Ancestors – Abstract)
ActivityDate (Date) – The date on which an activity for this
particular feature/object occurred. This date does not necessarily
correspond to the activity date stored in the related Activity
record.
ActivityEventID (String, 38) – A foreign key to Activity storing the
EventID of the activity with which this <class name>Audit
record is associated.
98
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Relationships:
(cardinality, optionality,
composite, inheritance)
SubTypes:
<class name>EventID – A foreign key to the <class name>
object/feature class storing the EventID of the object/feature with
which this <class name>Audit record is associated.
Activity<class name>Audit (core relationship type): Activity is 1:M
with <class name>Audit
<class name>Audit (core relationship type): <class name> is 1:M
with <class name>Audit
<class name>AuditDocument (core relationship type): <class
name>Audit is M:N with ExternalDocument
--
The Audit object classes represent a singular type of entity within the APDM. The Audit
object classes are physically implemented within the model and are required (core)
whenever a class requires a relationship with Activity or ExternalDocument. However,
<class name>Audit is documented as a ‘template’ class from which multiple concrete
classes may be implemented. In this sense, <class name>Audit behaves like an APDM
abstract class. The classification of <class name>Audit as either ‘core’ or ‘abstract’ is
largely arbitrary. <class name>Audit is documented with the core classes primarily
because the Audit classes are physically implemented in the model, unlike the other
APDM abstract classes.
The Audit object classes record historical events or comments about a feature within a
<parent>class. The <x> nomenclature is used to denote the name of a class that is
participating in a 1-M relationship with the Audit class. For example, the feature class
PipeSegment may have a PipeSegmentAudit object class where the EventID (primary
key) value of the PipeSegment is recorded in the PipeSegmentEventID attribute of the
PipeSegmentAudit table. Using this relationship many historical events can be recorded
for a given PipeSegment feature. The relationship between the audit object class and the
parent class is required and an audit record cannot exist without the parent class.
A 1-M relationship class must exist between the activity class and the audit class;
however the value of the ActivityEventID attribute is not required to be populated for
each record in the audit class. The purpose of this mechanism is to relate many features to
a single activity via the feature’s audit class. For example, a pipe inspection exposes a
pipe segment and two valve features. Each of the three features has an audit record
created to signify the inspection and each audit record has the EventID value of the
activity. If the user browses the activity in the ArcMap attribute editor, it would become
apparent that related records exist in the ValveAudit and PipeSegmentAudit tables for the
current feature. These related audit records would then relate to the parent features in the
valve and pipe segment tables respectively. In this manner, an activity can ‘link’ or tie
together many features from disparate feature and object classes. The audit class
relationship can be created for almost every class within the APDM. This construct
supplies the mechanism for advanced reporting and historical archiving functionality with
the APDM.
ESRI Technical Paper
99
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Technically, the <class name>Audit object class provides the mechanism that relates
features to activities. The <class name>Audit object class mediates what is actually a
many-to-many relationship between the <class name> object/feature class and Activity.
That is, a given feature may be associated with many activities, but a given activity may
also be related to many features. The <class name>Audit object class type is defined this
way because it also facilitates a many-to-many relationship with ExternalDocument. The
<class name>AuditDocument relationship ties a related document to both a feature and
an activity. This type of specific relationship cannot be supported simply by
implementing separate many-to-many relationships from the <class name> object/feature
class to Activity and from the <class name> object/feature class to ExternalDocument.
A <class name>Audit object class must be created for any feature class or object class
within the APDM geodatabase that needs to be associated with activities or external
documents.
10.4.2.5 Company
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
Attributes:
(name, type, length,
precision, scale,
domained, notes)
Relationships:
(cardinality, optionality,
composite, inheritance)
SubTypes:
Company
Implemented as an Object Class.
ESRI Object Æ APDM Object Æ Object Archive Æ
NonFacilityObject (Ancestors – Abstract)
CompanyLabel (String, 45) – Additional label, acronym, or
designation used for the company.
CompanyName (String, 45) – Company name.
CompanyType (Long Integer, 9) – gnCompanyType – Describes
the services the company provides (pipeline, contractors, etc.)
CompanyOwnerOperator (core): Company is 1:M with
OwnerOperator
LineCrossingCompany: LineCrossing is M:N with Company
CompanyContact: Company is M:N with Contact
CompanyAddress: Company is M:N with Address
CompanyMeterReading: Company is 1:M with MeterReading
CompanyCISReading: Company is 1:M with CIS Reading
--
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).
May 2007
100
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
The Company object class implements a many-to-many relationship with the
LineCrossing feature class, reflecting potential multiple ownership of the crossing line.
The Company object class has a many-to-many relationship with the LineLoop object
class reflecting the roles that multiple companies may play in the ownership and
operation of the actual line loops comprising a pipeline system.
10.4.2.6 ExternalDocument
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
Attributes:
(name, type, length,
precision, scale,
domained, notes)
Relationships:
(cardinality, optionality,
composite, inheritance)
SubTypes:
ExternalDocument
Implemented as an Object Class.
ESRI Object Æ APDM Object Æ Object Archive Æ
NonFacilityObject (Ancestors – Abstract)
DocumentDescription (String, 120) – A textual description of the
document.
DocumentType (Long Integer, 9) – gnExternalDocumentType –
Describes type of external document (e.g., CAD drawing,
document, map)
FilePath (String, 255) – UNC or mapped drive path to directory
containing file.
FileName (String, 255) – Name of file including extension.
HyperLink (String, 255) – Optional URL hyperlink to the
document.
ExternalDocumentGeoMetaData: ExternalDocument is 1:M with
GeoMetaData
<class name>AuditDocument (core relationship type): <class
name>Audit is M:N with ExternalDocument
ActivityExternalDocument (core): Activity is M:N with
ExternalDocument
DocumentPointExternalDoc: DocumentPoint is M:N with
ExternalDocument
--
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.
ESRI Technical Paper
101
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
The many-to-many <class name>AuditDocument relationship type allows multiple
documents to be related to multiple features. The ExternalDocument object class has a
one-to-many relationship with the GeoMetaData object class, modeling the fact that an
external document can contain metadata pertaining to the origin/provenance of positional
information recorded in a GeoMetaData object class record. The ExternalDocument
object class has a many-to-many relationship with the DocumentPoint feature class – one
DocumentPoint feature can be associated with multiple external documents; a single
external document may be referenced by multiple DocumentPoint features. Conceivably,
one DocumentPoint feature could reference one or more documents that might in turn
reference additional DocumentPoint features or other locations. (See the DocumentPoint
feature class description.) ExternalDocument has a many-to-many relationship with
Activity such that a single document can provide information about many activities, and a
single activity can be associated with many documents. This relationship allows
documents to be related directly to an Activity record without requiring any intermediary
association with a feature via the <class name>AuditDocument relationship type.
10.4.2.7 LineLoop
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
Attributes:
(name, type, length,
precision, scale,
domained, notes)
Relationships:
(cardinality, optionality,
composite, inheritance)
SubTypes:
LineLoop
Implemented as an Object class.
ESRI Object Æ APDM Object Æ Object Archive Æ
CenterlineObject (Ancestors – Abstract)
LineName (String, 45) – Name of the pipeline.
LineType (Integer, 3) – clLineServiceType – Classification of the
line type, e.g. ‘Gathering’, ‘Transmission’.
LineLoopStationSeries (core): LineLoop is 1:M with StationSeries
LineLoopChildLineLoop (core): LineLoop is 1:M with
LineLoopHierarchy
LineLoopParentLineLoop (core): LineLoop is 1:M with
LineLoopHierarchy
LineLoopOwnerOperator (core): LineLoop is M:N with
OwnerOperator
LineLoopProduct (core): LineLoop is M:N with Product
LineLoopAudit (core): LineLoop is 1:M with LineLoopAudit
--
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
May 2007
102
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
concert with the LineLoopHierarchy object class to organize pipelines into a pipeline
system hierarchy. In the APDM, the pipeline hierarchy may have an arbitrary, unlimited
number of levels. (See 10.4.2.8 LineLoopHierarchy for information on pipeline system
hierarchies.)
The definition of a physical line loop is inherently arbitrary, but most operators
understand a line loop to be a continuous, non-branching run of pipe. The APDM follows
this convention. To be designated as a physical line loop in the APDM, a physical
segment of pipe must be continuous and non-branching. The behavior of APDM
reference modes are defined at the level of the physical line loop (for more information,
see ReferenceMode).
In a transmission system, the most granular physical line loop is simply a continuous run
of pipe between facilities (e.g. pumping or compressor stations). Continuous segments of
pipe that branch off from the main transmission line loops (e.g. laterals, take offs,
interconnects, etc.) are also designated as physical line loops. In a gathering system, well
lines, gathering lines and trunk lines are typically designated as individual physical line
loops.
Most pipeline companies logically group a collection of connected physical line loops
(usually with common diameter and other attributes) under a single line name or line
number as a pipeline. In the APDM such a grouping corresponds to a logical line loop. In
a transmission system, a pipeline implemented as a logical line loop may stretch for tens,
hundreds, or even thousands of miles. In a gathering system, logical line loops are usually
implemented based on subsets of the gathering system network. For instance, all the well
lines feeding into a given trunk line could be grouped under a single logical line loop
record.
ESRI Technical Paper
103
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
May 2007
104
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
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
1
2
3
4
5
6
7
8
9
10
LineName
ACME System
ACME 12”
ACME 10”
10” Lateral
ACME Gathering System
6” Trunk Line
4” Gathering Line
Well #1
Well #2
Well #3
LineType
Transmission
Transmission
Transmission
Transmission
Gathering
Gathering
Gathering
Gathering
Gathering
Gathering
Note there is no distinction between physical and logical line loop records in the
LineLoop table (Although it is possible to add an additional attribute to the LineLoop
Object Class to denote this distinction between different LineLoops).
The LineLoop object class has a one-to-many relationship with the StationSeries feature
class. Each physical LineLoop object may be comprised of one or more connected
StationSeries features; logical line loop records should not be related to StationSeries
features. The relationship between LineLoop and OwnerOperator is many-to-many and
models the percentage ownership/operatorship of each LineLoop in the pipeline system.
LineLoop institutes two one-to-many relationships with LineLoopHierarchy, which
ESRI Technical Paper
105
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
models a hierarchy between parent and children LineLoops. A single line loop may be
the parent to one or more child line loops (see 10.4.2.8 LineLoopHierarchy). LineLoop
has a many-to-many relationship with Product. A liquids pipeline may carry many
products in batches; a single product may be carried by many lines.
10.4.2.8 LineLoopHierarchy
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
Attributes:
(name, type, length,
precision, scale,
domained, notes)
Relationships:
(cardinality, optionality,
composite, inheritance)
SubTypes:
LineLoopHierarchy
Implemented as an Object class.
ESRI Object Æ APDM Object (Ancestors – Abstract)
ParentLineLoopEventID (String, 38) - Foreign key to a parent
LineLoop object.
ChildLineLoopEventID (String, 38) - Foreign key to a child
LineLoop object.
LineLoopChildLineLoop (core): LineLoop is 1:M with
LineLoopHierarchy
LineLoopParentLineLoop (core): LineLoop is 1:M with
LineLoopHierarchy
--
Note that the construction of LineLoop, Activity and SubSystem hierarchies in the model
are all identical; the relationship of LineLoop to LineLoopHierarchy is mirrored by the
relationship of Activity to ActivityHierarchy and SubSystem to SubSystemHierarchy.
The LineLoopHierarchy object class models relationships between parent and child
LineLoops and is used to establish a hierarchy of LineLoops. The LineLoop hierarchy
groups LineLoops as sets of LineLoops belonging to higher sets of LineLoops. All
LineLoops can be grouped under a single or small set of LineLoops, which in effect
represents a pipeline or gathering system. Recursion in the line loop hierarchy is
unlimited; a given APDM implementation may establish as many line loop hierarchy
levels as desired.
The line loop hierarchy is facilitated by the two relationship classes that tie
LineLoopHierarchy to LineLoop: LineLoopParentLineLoop and
LineLoopChildLineLoop. Each record in LineLoopHierarchy stores a parent and child
line loop record in the line loop hierarchy.
As an illustration, consider a line loop hierarchy derived from the transmission and
gathering system examples presented above (see 10.4.2.7 LineLoop). In the transmission
system, let the ‘ACME System’ be the parent of the ‘ACME 12”’ and ‘ACME 10”’
pipelines. Let the ‘ACME 10”’ pipeline in turn be a parent of the ‘10” Lateral’ line. In the
gathering system, let the ‘ACME Gathering System’ be the parent of the ‘6” Trunk Line’,
May 2007
106
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
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
1
1
3
5
6
6
7
7
ChildLineLoopEventID
2
3
4
6
7
8
9
10
In the above example all root level entities have children. Note that by convention, root
level line loops that have no children do not appear in the LineLoopHierarchy table. This
facilitates the following model behavior: if the line loop hierarchy consists of only one
level (flat), LineLoopHierarchy need not be populated.
The relationships between LineLoop and LineLoopHierarchy facilitate the concept of a
single line loop having more than one parent (i.e. a single line loop appears more than
once in the ChildLineLoopEventID column of LineLoopHierarchy). This allows a single
line loop to appear multiple times in a tree view constructed from the line loop hierarchy.
This scenario is useful for representing interconnect lines between two different
pipelines. In this case, both connecting pipelines may be considered parents of the
interconnect line.
ESRI Technical Paper
107
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
10.4.2.9 OwnerOperator
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
Attributes:
(name, type, length,
precision, scale,
domained, notes)
Relationships:
(cardinality, optionality,
composite, inheritance)
SubTypes:
OwnerOperator
Implemented as an Object class.
ESRI Object Æ APDM Object Æ Object Archive Æ
NonFacilityObject (Ancestors – Abstract)
CompanyEventID (String, 38) – Foreign key to the Company object
class.
OwnerPercentage (Long Integer, 9) – (Default = 0) –
clOwnershipPercent – Percentage (0–100%) of ownership.
OwnerType (Long Integer, 9) – (Default = 0) – clOwnershipType –
Type of participation, e.g. ‘Ownership’, ‘Operator’.
LineLoopOwnerOperator (core): LineLoop is M:N with
OwnerOperator
CompanyOwnerOperator (core): Company is 1:M with
OwnerOperator
--
The OwnerOperator object class is used to define the percentage ownership and/or
operatorship for a LineLoop. The OwnerOperator object class has a many-to-many
relationship with LineLoop. One owner can have the same type of participation and
percentage in multiple line loops; a single line may have many participants (‘owners’).
The OwnerOperator object class has a many-to-one relationship with the Company object
class reflecting that one company can have multiple ownership/operatorship percentages
(varying by line loop) in a pipeline system.
10.4.2.10 Product
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
Attributes:
(name, type, length,
precision, scale,
domained, notes)
Relationships:
Product
Implemented as an Object class.
ESRI Object Æ APDM Object Æ Object Archive Æ
NonFacilityObject (Ancestors – Abstract)
Product (Integer, 3) – clProduct – Product type, e.g. ‘Oil’, ‘Natural
Gas’
LineLoopProduct (core): LineLoop is M:N with Product
(cardinality, optionality,
composite, inheritance)
SubTypes:
--
The Product object class is used to store information about the types of products carried
in the pipeline. Product participates in a many-to-many relationship with LineLoop.
May 2007
108
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
A single product (such as natural gas can be carried by many lines and conversely a
single line can carry many products at the same time but distributed in batches (eg.
Highly Volative Liquids or Crude Oil).
10.4.2.11 SubSystem
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
Attributes:
(name, type, length,
precision, scale,
domained, notes)
Relationships:
(cardinality, optionality,
composite, inheritance)
SubTypes:
LineLoopHierarchy
Implemented as an Object class.
ESRI Object Æ APDM Object Æ Object Archive Æ
CenterlineObject (Ancestors – Abstract)
SubSystemName (String, 45) – The name or label that identifies the
subsystem.
SubSystemChildSubSystem (core): SubSystem is 1:M with
SubSystemHierarchy
SubSystemParentLineLoop (core): SubSystem is 1:M with
SubSystemHierarchy
SubSystemRange (core): SubSystem is 1:M with SubSystemRange
SubSystemSite (core): SubSystem is M:N with Site
SubSystemAudit (core): SubSystem is 1:M with SubSystemAudit
SubSystemContact: SubSystem is M:N with Contact
--
The SubSystem object class is used to categorize, organize, and group pipeline segments
into logical groupings that may cut across line loops and station series. A subsystem can
be defined to represent virtually any grouping of pipe segments for business purposes. A
common use of SubSystem is to define organizational boundaries (e.g., divisions,
districts, and operating areas). Another common use is to record administrative
boundaries such as taxing districts. The SubSystem object class is used in concert with
the SubSystemHierarchy object class to organize subsystems into a hierarchy. A
subsystem hierarchy may have an arbitrary, unlimited number of levels. Different types
of subsystem hierarchies can exist side by side within the SubSystem and
SubSystemHierarchy object classes. (See 10.4.2.12 SubSystemHierarchy for information
on defining subsystem hierarchies.)
As is the case with line loops, SubSystem records can be classified as representing either
physical or logical subsystems. A physical subsystem corresponds directly to a collection
of physical pipeline segments (as defined by one or more 10.4.3.4 SubSystemRange
features). These pipe segments may cross line loop and station series boundaries. Unlike
a physical line loop, a physical subsystem need not be continuous, and may branch. A
logical subsystem is a grouping of physical subsystems and/or lower level logical
ESRI Technical Paper
109
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
subsystems. As is the case with LineLoop, there is no distinction between physical and
logical subsystem records in the SubSystem table.
May 2007
110
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
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
1
2
3
4
5
6
7
8
9
10
ESRI Technical Paper
SubSystemName
Operating Divisions
Western Division
Eastern Division
District 1
District 2
District 3
District 4
Tax Authorities
Washington County
Jefferson County
111
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
SubSystem implements two one-to-many relationships with SubSystemHierarchy,
modeling a hierarchy of parent and child subsystems. A single subsystem may be the
parent to many child subsystems. SubSystem participates in a one-to-many relationship
with SubSystemRange; a physical subsystem is comprised of one or more
SubSystemRange features. SubSystem participates in a many-to-many relationship with
Site. A SubSystem may encompass multiple sites; a site may be associated with multiple
subsystems. SubSystem implements a one-to-many relationship with SubSystemAudit;
this relationship ties SubSystem to both Activity and ExternalDocument. Through
SubSystemAudit records a subsystem may be associated with multiple activities and/or
documents, and vice versa. SubSystem implements a many-to-many relationship with
Contact. Multiple contacts may be defined for a subsystem; a single contact may serve
multiple subsystems.
Optionally, an implementation may institute relationships between one or more polygon
feature classes and the SubSystem object class. Polygons in such related feature classes
represent the spatial extents of corresponding subsystems.
10.4.2.12 SubSystemHierarchy
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
Attributes:
(name, type, length,
precision, scale,
domained, notes)
Relationships:
(cardinality, optionality,
composite, inheritance)
SubTypes:
SubSystemHierarchy
Implemented as an Object class.
ESRI Object Æ APDM Object (Ancestors – Abstract)
ParentSubSystemEventID (String, 38) - Foreign key to a parent
SubSystem object.
ChildSubSystemEventID (String, 38) - Foreign key to a child
SubSystem object.
SubSystemChildSubSystem (core): SubSystem is 1:M with
SubSystemHierarchy
SubSystemParentLineLoop (core): SubSystem is 1:M with
SubSystemHierarchy
--
Note that the construction of SubSystem, Activity and LineLoop hierarchies in the model
are all identical; the relationship of SubSystem to SubSystemHierarchy is mirrored by the
relationship of Activity to ActivityHierarchy and LineLoop to LineLoopHierarchy.
The SubSystemHierarchy object class models the hierarchy between different subsystem
features in the model. It is common to have organizational groupings or areas contain sub
areas that, in turn, could contain other sub areas. The SubSystemHierarchy object class
has two one-to-many relationships with the SubSystem object class modeling parent to
child relationships between subsystem objects.
May 2007
112
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
The SubSystemHierarchy object class models relationships between parent and child
subsystems and is used to establish a hierarchy of subsystems. The subsystem hierarchy
groups subsystems as sets of subsystems belonging to higher level subsystems. All
subsystems can be grouped under a single or small set of subsystems. Multiple,
independent subsystem hierarchies can be established to model different types of
business-related pipeline groupings, e.g. operating districts, emergency response areas,
tax authorities, etc. Recursion in the subsystem hierarchies is unlimited; a given APDM
implementation may establish as many subsystem hierarchy levels as desired.
The subsystem hierarchy is facilitated by the two relationship classes that tie
SubSystemHierarchy to SubSystem: 1) SubSystemParentSubSystem and 2)
SubSystemChildSubSystem. Each record in SubSystemHierarchy stores a parent and
child subsystem record in the subsystem hierarchy.
As an illustration, consider a subsystem hierarchy derived from the operational and tax
district examples presented above (see 10.4.2.11 SubSystem). In the operational
subsystem, let ‘Operating Divisions’ be the parent of the ‘Western Division’ and ‘Eastern
Division’ subsystems. Let the ‘Western Division’ subsystem in turn be the parent of the
‘District 1’ and ‘District 2’ subsystems. Let the ‘Eastern Division’ subsystem be the
parent of the ‘District 3’ and ‘District 4’ subsystems. In the tax district subsystem, let the
‘Tax Authorities’ subsystem be the parent of the ‘Washington County’ and ‘Jefferson
County’ subsystems. A tree view of the hypothetical subsystem hierarchy has the
following appearance (the integer subsystem IDs are included in parentheses for clarity):
•
•
•
Operating Divisions
o (2) Western Division
ƒ (4) District 1
ƒ (5) District 2
(3) Eastern Division
ƒ (6) District 3
ƒ (7) District 4
(8) Tax Authorities
o (9) Washington County
o (10) Jefferson County
Note that the example subsystem hierarchy actually consists of two independent
subsystem hierarchies, one for operating units and one for tax authorities.
The SubSystemHierarchy table for the hypothetical subsystem hierarchy is populated
with the following records (GUIDs are replaced with the above integer designations for
clarity):
ESRI Technical Paper
113
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
ParentSubSystemEventID
1
1
2
2
3
3
8
8
ChildSubSystemEventID
2
3
4
5
6
7
9
10
In the above example all root level entities have children. Note that by convention, root
level subsystems that have no children do not appear in the SubSystemHierarchy table.
This facilitates the following model behavior: if the subsystem hierarchy consists of only
one level (flat), SubSystemHierarchy need not be populated.
10.4.3 Core Feature Classes
10.4.3.1 ControlPoint
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
Attributes:
(name, type, length,
precision, scale,
domained, notes)
Relationships:
(cardinality, optionality,
composite, inheritance)
May 2007
ControlPoint
Implemented as an M-Aware (and optionally Z-Aware) Point
Feature class.
ESRI Feature Æ FeatureArchive Æ CenterlinePoint (Ancestors –
Abstract)
ControlPointAngle (Double, 15, 2) – The magnitude of direction
angle marking the change in vector direction (deflection) of the
centerline from one control point to the next (e.g., 45° left
deflection).
ControlPointType (Integer, 3) – clControlPointType – The type of
control point (e.g., point of inflection, monument, line crossing.
PIDirection (Integer, 3) – clControlPointDirection – The direction
of the centerline deflection at the control point relative to the
vector of the last centerline segment of which the control point is
the endpoint (e.g., ‘R’ for right, ‘L’ for left, ‘None’).
StationValue (Double, 15, 2) – The known station value (measure)
along a station series at the control point location.
SubTypeCD (Integer, 3) – The subtype, or reference mode
(measurement system) of the control point.
StationSeriesControlPoint (core): StationSeries is 1:M with
ControlPoint
ReferenceModeControlPoint (core): ReferenceMode is 1:M with
ControlPoint
ControlPointAudit (core): ControlPoint is 1:M with
ControlPointAudit
114
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
SubTypes:
ControlPointGeoMetaData: StationSeries is M:N with
GeoMetaData
1 = Continuous
2 = Engineering
3 = Horizontal
4 = Mile Post
5 = Slack Chain
6 = Valve Section
7 = Unspecified
The ControlPoint feature class lies at the heart of the APDM. The ControlPoint feature
class stores points of known x,y position and known station value (measure) along the
pipeline centerline. Control point features define the pipeline centerline. The ControlPoint
feature class has a many-to-one relationship with the StationSeries feature class. Within a
given reference mode (subtype), each station series feature is composed of two or more
control point features of the same reference mode. Each control point corresponds to a
vertex (including the endpoints) of an associated station series feature. The station (or
measure) value stored with the control point feature defines the M value of the vertex at
the same location in the associated station series feature.
The subtypes of the ControlPoint feature class represent the different types of linear
referencing measurement systems (reference modes) that are used for stationing along the
pipeline centerline. By convention, each control point location must be occupied by at
least one control point feature for each reference mode present in the model. (In the case
of station series endpoints on connected station series, a control point location is occupied
by two control points of the same reference mode.) The reason for this convention is that
different reference modes may not share a common physical basis for the system of
measurement (see ReferenceMode). During some centerline edit operations (for instance,
reroutes), spatial integrity between the different reference modes can only be maintained
if the measure value is known in all reference modes at each control point location.
The APDM requires that one subtype be defined as the primary reference mode (default
measurement system) for the pipeline centerline. Other control point subtypes, or
measurement systems, present in the model are considered secondary measurement
systems. All secondary measurement systems must be geometrically coincident and
geometrically constrained to the primary measurement system control points and station
series features. Representations for all control point (and station series) features must be
present in all reference modes. The default measurement system (or subtype) becomes
the stationing method applied to all online features; online features are stored only in the
primary reference mode.
The ControlPoint feature class has a many-to-many relationship with GeoMetaData. This
relationship models the provenance of the location information for the control point
feature. GeoMetaData stores original coordinate information and metadata describing
ESRI Technical Paper
115
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
how the control point feature was initially obtained in the field. A control point may have
more than one GeoMetaData record (i.e. it was surveyed by more than one method); a
single GeoMetaData record applies to all the control points at a control point location
(one or two for each reference mode). ControlPoint implements a one-to-many
relationship with ControlPointAudit; this relationship ties ControlPoint to both Activity
and ExternalDocument. Through ControlPointAudit records a control point may be
associated with multiple activities and/or documents, and vice versa.
10.4.3.2 Site
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
Attributes:
(name, type, length,
precision, scale,
domained, notes)
Relationships:
(cardinality, optionality,
composite, inheritance)
SubTypes:
Site
Implemented as a Polygon Feature class.
ESRI Feature Æ FeatureArchive Æ OfflineFacility (Ancestors –
Abstract)
SiteName (String, 45) – The name of the site.
SiteType (Long Integer, 9) – opSiteType – (Default = 0) –The type
of site contained within the boundary (e.g., meter station,
compressor station)
SiteAudit (core): Site is 1:M with SiteAudit
Site<Online or Offline Facility classname> (core relationship type):
Site is 1:0..M with < Online or Offline Facility classname>
SubSystemSite (core): SubSystem is M:N with Site
SiteContact: Site is M:N with Contact
--
The Site feature class is designed to store the polygonal boundaries of the various stations
and other properties housing facilities owned by a pipeline company. Site features might
be used to define the boundaries of properties, easements, temporary work areas, and
large pipeline complexes such as meter stations, compressor stations, refineries, custody
transfer stations, and valve stations. Site features may also be used to demarcate the limit
of stationed pipes and non-stationed pipes.
Site implements an optional one-to-many relationship with all online and offline facility
feature classes. This core relationship type allows facility features to be associated with a
site as desired. It may not always be possible to associate online facilities features with a
station series feature, or provide such features with a shape. This may occur when
facilities equipment at a site is known only through a site equipment manifest. In this
situation, the pieces of equipment may still be stored in the APDM and can be tracked by
their relationship to a site. Site implements a one-to-many relationship with SiteAudit;
this relationship ties Site to both Activity and ExternalDocument. Through SiteAudit
records, a site may be associated with multiple activities and/or documents and vice
versa.
May 2007
116
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
10.4.3.3 StationSeries
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
Attributes:
(name, type, length,
precision, scale,
domained, notes)
Relationships:
(cardinality, optionality,
composite, inheritance)
ESRI Technical Paper
StationSeries
Implemented as an M-Aware (and optionally Z-Aware) Polyline
Feature class.
ESRI Feature Æ FeatureArchive Æ CenterlinePoint (Ancestors –
Abstract)
SeriesName (String, 45) – An operational label or name applied to
the station series feature for query and labeling purposes.
SeriesOrder (Long Integer, 9) – An arbitrary number used to order
station series features for querying and connectivity purposes.
BeginStation (Double, 15, 2) – The station value assigned to the
start of the station series feature.
EndStation (Double, 15, 2) – The station value assigned to the end
of the station series feature.
FromSeriesEventID (String, 38) – A foreign key pointing to the
EventID of the StationSeries feature connected to the ‘starting’
end of the current StationSeries feature.
FromConnectionStationValue (Double, 15, 2) – The station value
on the station series at which the ‘From’ station series connects.
ToSeriesEventID (String, 38) – A foreign key pointing to the
EventID of the StationSeries feature connected to the ‘ending’
end of the current StationSeries feature.
ToConnectionStationValue (Double, 15, 2) – The station value on
the station series at which the ‘To’ station series connects.
LineLoopEventID (String, 38) – The foreign key to a record in the
LineLoop class. Each StationSeries feature must be associated
with a LineLoop object. As a best practice, a set of StationSeries
features associated with a particular LineLoop should be
physically connected to each other.
SubTypeCD (Long Integer, 9) – The subtype of the station series
defining the system of linear referencing or stationing.
StationSeriesControlPoint (core): StationSeries is 1:M with
ControlPoint
LineLoopStationSeries (core): LineLoop is 1:M with StationSeries
StationSeries<Online Feature class name>: StationSeries is 1:M
with <Online Feature class name>
BeginStationSeriesAltRefMeas (core): StationSeries is 1:M with
AltRefMeasure
EndStationSeriesAltRefMeas (core): StationSeries is 1:M with
AltRefMeasure
ReferenceModeStationSeries (core): ReferenceMode is 1:M with
StationSeries
StationSeriesAudit (core): StationSeries is 1:M with
117
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
SubTypes:
StationSeriesAudit
1 = Continuous
2 = Engineering
3 = Horizontal
4 = Mile Post
5 = Slack Chain
6 = Valve Section
7 = Unspecified
The StationSeries feature class stores the routes that comprise the pipeline centerline. All
online features in the APDM are referenced against primary reference mode station series
features. Each station series feature is an ESRI Route with an assigned begin and end
measure (or station) value. Each vertex in the station series feature has a measure (or
station) value assigned to it. Point and linear events are located along the station series
route by assigning the Route-ID (StationSeriesEventID) and a measure value as attributes
of the feature (linear events require both begin and end measure values). Linear events
must start and end on the same station series (route).
The FromSeriesEventID, FromConnectionStationValue, ToSeriesEventID, and
ToConnectionStationValue attributes model station series connectivity in the pipeline
system. Usually, the From- and ToConnectionStationValue entries reference the first and
last (Begin- and EndStation) station values in the station series feature. In some
implementations, however, this may not be the case. Consider the case where pig
launchers and receivers are modeled as online features. In this situation, the From- and
ToConnectionStationValue entries may not occur at station series ends. Because the
APDM does not allow line loops to branch, whenever From- and
ToConnectionStationValue entries do not occur at the ends of the station series feature,
the connecting station series feature(s) must be placed on separate line loops.
The APDM implements a one-to-many relationship between the StationSeries feature
class and each referenced online feature class; this relationship type is core to the model.
Each online feature is referenced to a station series feature; the location and measure
(station) values of online features are defined and constrained by their underlying related
station series feature. The StationSeries feature class also has a one-to-many relationship
with the ControlPoint feature class. This relationship embodies the concept that a station
series is comprised of two or more control points, with each related control point
corresponding to a vertex in the station series feature. StationSeries implements a manyto-one relationship with LineLoop; each physical line loop is comprised of one or more
connected station series features (for uninterrupted reference modes, each physical line
loop is comprised of a single station series feature). StationSeries implements two one-tomany relationships with AltRefMeasure; each BeginStation and EndStation value in
AltRefMeasure is tied to the associated station series feature. StationSeries implements a
one-to-many relationship with StationSeriesAudit; this relationship ties StationSeries to
May 2007
118
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
both Activity and ExternalDocument. Through StationSeriesAudit records, a station
series may be associated with multiple activities and/or documents and vice versa.
The StationSeries feature class has the same subtypes as the ControlPoint feature class:
continuous, engineering, horizontal, milepost, slack chain, valve section, and unspecified.
The APDM requires that one subtype be chosen as the primary stationing or referencing
method (the default subtype).
Engineering stationing is the reference mode most commonly recognized by pipeline
operators. Engineering stationing is usually implemented with the ‘Interrupted and Not
Adjustable’ reference mode type and the ‘3D Slack Chain’ reference mode basis. In
Engineering Stationing, station series features are bounded by ‘station equations’
representing the discontinuity in stationing from one Engineering station series to the
next. (Note that station equations are not explicitly modeled in the APDM.) Continuous
stationing is usually implemented with the ‘Uninterrupted and Adjustable’ reference
mode type and the ‘3D Slack Chain’ reference mode basis. Using this definition,
Continuous stationing is simply Engineering stationing with station equation
discontinuities removed. Conceptually, Continuous station corresponds to Measure in
PODS, or NET stationing in ISAT. In the geodatabase, Continuous stationing allows for
the creation of linear event features that are not artificially split at station equations
(unlike Engineering linear event features, which are split at station equations). Most
APDM implementations use either Continuous or Engineering as the primary reference
mode. The Unspecified reference mode allows some flexibility for importing control
points that have no assigned or calculated stationing, which may be the case for
preliminary pipeline routing, new construction, or proposed pipeline reroutes.
Unspecified may not serve as the primary reference mode.
By accommodating many different methods of stationing, the APDM remains very
flexible and open to the varying needs of many pipeline companies importing data from
other pipeline models. The position of events and features on or along the centerline can
be easily determined by matching the position of these features along station series
storing different station values. Core ESRI geodatabase tools allow for simple
comparison and calibration of different reference systems' station values. The primary
stationing method is the ultimate arbitrator of an event's position on or along the pipeline
centerline.
10.4.3.4 SubSystemRange
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
Attributes:
ESRI Technical Paper
SubSystemRange
Implemented as an M-Aware (and optionally Z-Aware) Polyline
Feature class.
ESRI Feature Æ FeatureArchive Æ CenterlinePolylineEvent
(Ancestors – Abstract)
SubSystemEventID (String, 38) - Foreign key to a SubSystem
119
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
(name, type, length,
precision, scale,
domained, notes)
Relationships:
(cardinality, optionality,
composite, inheritance)
SubTypes:
object.
SubSystemRange (core): SubSystem is 1:M with SubSystemRange
StationSeriesSubSystemRange (core): StationSeries is 1:M with
SubSystemRange
SubSystemRangeAltRefMeasure (core): SubSystemRange is M:N
with AltRefMeasure
--
SubSystemRange stores the actual physical extent of a subsystem as one or more online
polyline event features. Building on the example used in 10.4.2.11 SubSystem, each
station series segment in a subsystem corresponds to a SubSystemRange feature:
The SubSystemRange features from the two examples
are recorded in the SubSystemRange feature table as
follows (GUIDs are replaced with the integer IDs from
the diagrams for clarity). SubSystemRange implements
a many-to-one relationship with SubSystem; each
subsystem is comprised of one or more
SubSystemRange feature. SubSystemRange implements
a many-to-one relationship with StationSeries; the
location and station values for each SubSystemRange
feature are constrained by the associated station series.
SubSystemRange implements a many-to-many
relationship with AltRefMeasure. Each
SubSystemRange feature has one AltRefMeasure
record for each reference mode; several
SubSystemRange features representing one
SubSystemRange event that has been artificially split
due to the use of an interrupted primary reference mode
will have one AltRefMeasure record.
May 2007
EventID
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
SubSystemEventID (Name)
4 (District 1)
4 (District 1)
5 (District 2)
5 (District 2)
6 (District 3)
6 (District 3)
6 (District 3)
7 (District 4)
7 (District 4)
7 (District 4)
9 (Washington County)
9 (Washington County)
9 (Washington County)
9 (Washington County)
9 (Washington County)
10 (Jefferson County)
10 (Jefferson County)
10 (Jefferson County)
120
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
10.5 APDM Core Domains
All domains in the APDM model use a long integer numeric value for the code. Each
code corresponds to a textual description of the coded value. There are two codes and
descriptions that are common to most domains, -1 and 0. The –1 code value is described
as ‘Unknown (Verified)’ meaning the attribute value is unknown and this fact has been
verified against source material, other existing data sources, and/or field survey. The 0
code is described as ‘Unknown’ and is the standard default value for most domains in the
model. A value of 0 within a coded value domain indicates that the user does not know
the contents of the attribute and this has not been verified by research or investigation.
Some long integer domains incorporate a logical structure to the numeric values in the
domain. Increasing domain values are used to indicate less restrictive behavior. The
following domains incorporate this logic:
•
•
•
•
•
gnOperationalStatus
gnStatus
clStationEditResponse
clXYEditResponse
clZEditResponse
There are a number of reasons numeric values are used for domain codes. One reason is
that behavior domains have been defined such that as the code value increases from 1, the
level of behavior restriction decreases. This rule applies to numbers greater than 0.
Code
-1
0
ESRI Technical Paper
Brief Description
Unknown (Verified)
Unknown Å Default
121
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
10.5.1 Required Domains
The following is a listing of the domains that are considered core to the APDM. These
domains are used to populate attributes in the APDM abstract classes, which are used to
explicitly define behavior in the APDM. Core domains must be implemented exactly as
defined using the values and descriptions described below to maintain APDM
compliance. Core domains may be expanded with additional values, but the user should
be aware that this may cause interoperability issues.
10.5.1.1 gnOperationalStatus
Indicates the status of a feature that has some operational lifespan based on FERC/OPS
definitions. OperationalStatus is applied to centerline and facility features with complex
operational life spans. The gnOperationalStatus domain is a coded value domain
containing the following long integer values:
=1 = Unknown (Verified)
0 = Unknown Å Default
1 = Conceptual
2 = Proposed
4 = Active
8 = Inactive
16 = Idle
32 = Abandoned
64 = Removed
10.5.1.2 gnStatus
Status is used to describe the state of a non-facility or centerline object (i.e. an object that
has no operational significance or does not typically exist as a geographical or physical
entity). The gnStatus domain is a coded value domain containing the following long
integer values:
-1 = Unknown (Verified)
0 = Unknown Å Default
1 = Conceptual
2 = Proposed
4 = Active
8 = Inactive
May 2007
122
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
10.5.1.3 clStationEditResponse
Describes how the station values for the control point may be altered. The
clStationEditResponse domain is a coded value domain containing the following long
integer values:
-1 = Unknown (Verified)
0 = Unknown Å Default
1 = Assigned
2 = Offset Downstream
3 = Offset Upstream
4 = Interpolated
5 = Fixed
10.5.1.4 clXYEditResponse
Indicates how the x,y portion of the geometry of a control point feature responds to a
centerline edit such as a reroute. The clXYEditResponse domain is a coded value domain
containing the following long integer values:
-1 = Unknown (Verified)
0 = Unknown Å Default
1 = Assigned
2 = Fixed Distance
3 = Fixed Deflection
4 = Fixed Inline
5 = Fixed Geometry
6 = Fixed
10.5.1.5 clZEditResponse
Indicates how the Z portion of the geometry of a control point feature responds to a
centerline edit such as a reroute. The clZEditResponse domain is a coded value domain
containing the following long integer values:
-1 = Unknown (Verified)
0 = Unknown Å Default
1 = Not Applicable
2 = Assigned
3 = Derived
4 = Interpolated
5 = Fixed
ESRI Technical Paper
123
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
10.5.1.6 gnOnlineLocationMechanism
Describes the various spatial operations used to generate online location features of
offline or online features. The gnOnlineLocationMechanism domain is a coded value
domain containing the following long integer values:
-1 = Unknown (Verified)
0 = Unknown Å Default
1 = ClosestPoint
2 = DistanceAzimuth
3 = BufferIntersection
4 = PolygonIntersection
5 = PointIntersection
6 =- PolylineEasement
7 =- PointEasement
8 = PolylineEndpoint
9 = PolylineCenterpoint
10 = AggregatePoint
11 = AggregatePolyline
10.5.1.7 gnHistoricalState
Describes the current representation of an online feature as a means of differentiating
from previous historical feature representations. The gnHistoricalState domain is a coded
value domain containing the following long integer values:
-1 = Unknown (Verified)
0 = Unknown Å Default
1 = Current
2 = Historical
10.5.1.8 gnAngle
A rotation angle from 0–360o for a point symbol. This allows operators to preserve
rotation information for point symbols imported from external systems such as CAD.
Allows all point symbols within the APDM to be rotated as needed; manually, or in
relation to other features. This is used primarily for display in mapping applications such
as alignment sheets. The gnAngle domain is a range value domain containing the
following double values:
MinValue = 0.00 Å Default
MaxValue = 360.00
May 2007
124
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
10.5.1.9 clEditResponse
Indicates how the geometry and/or stationing attributes of an online feature responds to a
centerline edit such as a reroute. The clEditResponse domain is a coded value domain
containing the following long integer values:
-1 = Unknown (Verified)
0 = Unknown Å Default
1 = Relative
2 = Proportional
3 = Absolute
10.5.1.10 gnAPDMClassType
Lists the different types of APDM abstract classes. Used to define the immediate parent
abstract class from which an object or feature class inherits behavior. The
gnAPDMClassType domain is a coded value domain containing the following long
integer values:
-1 = Unknown (Verified)
0 = Unknown Å Default
1 = APDMObject
2 = CenterlineObject
3 = FacilityObject
4 = NonFacilityObject
5 = CenterlinePolyline
6 = CenterlinePolylineEvent
7 = CenterlinePoint
8 = OfflineFeature
9 = OfflinePoint
10 = OfflineFacility
11 = OfflinePointFacility
12 = OfflineNonPointFacility
13 = OnlineFeature
14 = OnlinePolyline
15 = OnlinePolylineForOfflineFeature
16 = OnlinePoint
17 = OnlinePointForOfflineFeature
18 = OnlineFacility
19 = OnlinePolylineFacility
20 = OnlinePointFacility
21 = Fitting
22 = Audit
ESRI Technical Paper
125
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
10.5.1.11 gnRefModeBasis
Describes the basis for determining the origin of distance measurements for a particular
stationing method. The gnRefModeBasis domain is a coded value domain containing the
following long integer values:
-1 = Unknown (Verified)
0 = Unknown Å Default
1 = Arbitrary
2 = 3D Projected
3 = 3D Slack Chain
4 = 3D Geoid
5 = 2D Projected
10.5.1.12 gnRefModeType
Describes the basis for determining how the stationing values within a LineLoop react in
the event of an upstream centerline reroute. The gnRefModeType domain is a coded
value domain containing the following long integer values:
-1 = Unknown (Verified)
0 = Unknown Å Default
1 = Uninterrupted and Adjustable
2 = Uninterrupted and Not Adjustable
3 = Interrupted and Adjustable
4 = Interrupted and Not Adjustable
10.5.1.13 gnRefModeUnits
Describes the possible units used for stationing values for a particular reference mode.
This gnRefModeUnits domain is a coded value domain containing the following long
integer values:
-1 = Unknown (Verified)
0 = Unknown Å Default
9001 = esriSRUnit_Meter
9002 = esriSRUnit_Foot
9003 = esriSRUnit_SurveyFoot
9030 = esriSRUnit_NauticalMile
9033 = esriSRUnit_SurveyChain
9034 = esriSRUnit_SurveyLink
9035 = esriSRUnit_SurveyMile
9036 = esriSRUnit_Kilometer
May 2007
126
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
10.5.1.14 gnYesNo
A domain used to depict a yes or no value while accounting for the possibility of
unknown values. This gnYesNo domain is a coded value domain containing the
following long integer values:
-1 = Unknown (Verified)
0 = Unknown Å Default
1 = Yes
2 = No
10.5.1.15 gnRequiresGeometry
A domain used to indicate if the rows in a feature class can allow the SHAPE column to
contain a null value. This gnRequiresGeometry domain is a coded value domain
containing the following long integer values:
-1 = Unknown (Verified)
0 = Unknown Å Default
1 = Must Have
2 = Must Not Have
3 = Optional
The following domains are applied to attributes of the APDM Fitting abstract class. To
conserve space within the whitepaper document and because many of the actual domain
values can vary between implementations, the contents of these domains are not listed
here. However these domains are considered core parts of the APDM and must be
implemented using the default values for ‘Unknown (Verified)’ and ‘Unknown’.
•
•
•
•
•
•
•
•
fcFittingGrade
fcConnectionType
fcDiameter
fcWallThickness
fcFittingManufacturer
fcMaterial
fcPressureRating
fcSpecification
10.5.2 APDM Compliance
The APDM is designed as a template that can be expanded or modified to meet the
specific requirements of any given pipeline organization. Although the APDM is
designed with customization in mind, it is important to recognize that there are elements
(classes, attributes and relationships between classes) within the object model that are
considered core and must be implemented as specified. In addition, modifications to the
APDM must be made within the context of the APDM abstract class definitions (i.e. any
ESRI Technical Paper
127
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
custom class added to the model in a particular implementation must inherit from one of
the APDM abstract classes).
Correct implementation of the APDM core elements and abstract classes is the
benchmark for APDM compliance. The goal of APDM compliance is to define a
common data model framework that facilitates consensus and interaction between various
pipeline interests, and yet allows wide latitude for data model modification, innovation
and experimentation. Achieving such a broad goal requires a nontraditional approach to
compliance. Traditional RDBMS data model compliance is achieved through absolute
conformance to the tabular structure of a predefined database construct. APDM
compliance is primarily concerned with the behavioral aspects of the data construct.
APDM compliance minimizes strict structural conformance to a relatively small base set
of fundamental features referred to as the Core APDM.
APDM compliance is understood to be the following:
•
All object and feature classes within the model must implement (and therefore
inherit) from one of the APDM abstract classes.
•
Some APDM abstract classes define associated relationship types; all object and
feature classes inheriting from such an abstract class must also implement the
inherited relationship types.
•
Core APDM Feature and Object Classes (their attributes and the relationships
between them and other classes) must be retained and implemented precisely as
specified.
•
Class names of Core APDM Feature and Object Classes must be implemented
precisely as specified.
•
Attributes inherited from APDM Abstract Classes must be implemented precisely
as specified.
•
Standard APDM domains (including the default –1 = Unknown (Verified) and 0 =
Unknown (Default Value) must be implemented precisely as specified.
•
Relationships (including relationship names, origin and destination classes,
optionality and cardinality) must be implemented precisely as specified.
Core APDM features and objects and their attribute names must be retained precisely for
APDM compliance. The inclusion of additional attribution or domain values into the
Core APDM is acceptable (and expected; defined attribution for the core classes is
minimal).
May 2007
128
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Behavioral rules are established in the Core APDM and abstract classes. These rules are
extended to the larger model template via the concept of inheritance. Behavioral
compliance is based upon the adherence to abstract class definitions including abstract
class attribution and relationship class behavior. The abstract classes define rules for what
constitutes online and offline point, line, and polygon features as well as the online
locations for offline features. The APDM abstract classes define compliance within the
semantic context of a behavioral construct. This construct provides the necessary
organizational framework to permit virtually limitless flexibility and expansion of the
model to suit the individual needs of operators, while maintaining the required
commonalities to facilitate software interoperability within the user community.
APDM compliance is intended to promote interoperability through the enforcement of
standardized object behavior. APDM compliance is not intended to be a measuring stick
used to enforce standard data model content. Rather, APDM compliance is intended to
aid in the definition and understanding of object behaviors that occur during loading,
editing and archiving operations. This is particularly true for editing operations that are
peculiar to the pipeline industry including, for example, pipeline reroutes and centerline
modifications. APDM compliance allows a flexible implementation of feature and object
classes to meet the specific business requirements of any pipeline operator.
10.5.3 Non Geometric Features
APDM 4.0 supports the concept of 'non-geometric' facility features. This behavior can
apply to any feature class that inherits from the ‘OfflineNonPointFacility’,
‘OfflinePointFacility’ or ‘OnlineFacility’ APDM Abstract Classes. This mechanism
removes the need to represent geometric features and non-geometric objects as separate
classes sharing identical attributes, subtypes and domains. A feature class implementing
the ‘non-geometric’ behavior has a foreign key attribute relating the feature class to the
‘Site’ APDM Core feature class. By relating a feature to a Site, the feature may exist
without geometry but is now ‘contained’ within the Site and can be located via the
hierarchy (e.g. sites are related to SubSystems and SubSystems are related to
SubSystemRanges, which in turn are related to StationSeries and LineLoops and so on).
A manifest or listing of features ‘contained’ within a Site is obtained by searching the
relationship classes from Site to any class implementing a ‘facility’ parent abstract class.
This mechanism has additional implications for feature classes inheriting from the
‘OnlineFacility’ APDM Abstract Class. Online features must have geometry that is
derived from an underlying PRM station series; however, using the ‘SiteEventID’
mechanism allows online features to be stored without requiring an underlying station
series. A combination of values from SiteEventID, StationSeriesEventID, and Begin/End
Station Value determines whether geometry is created for the feature. The chart below
explains the various combinations of how these attributes can be used to define and store
features contained within a Site.
ESRI Technical Paper
129
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
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.
OfflinePointFacility
Has value
--Is not created
OfflineNonPointFacility
The feature is located in or associated with a Site, but its exact location is unknown. The feature does not have any
shape geometry.
Associating facilities features with Sites and allowing storage of features without
geometry, provides numerous possibilities for managing facilities within the APDM.
Using the chart above, various scenarios for modeling facilities within a Site are
available. For example, many companies do not fully model the ‘plumbing’ within a Site;
often the centerline (StationSeries features) stops at the border of a site and does not
traverse the site. However, many active features may be known to exist within the site
(e.g. via a facility equipment manifest). These features can be represented in the APDM
as features with null shapes that reference the Site. Alternatively, sometimes companies
map the station series and facilities within a site using a ‘false’ un-connected station
series. The station series and the site are then used to locate the “in-site” features, but
those features are not located via stationing on the ‘false’ station series. The features are
represented in the APDM with null shapes, but are referenced to both the site and the
‘false’ station series. As a result, some companies accurately map the station series within
a site, but still do not know the locations of all site facilities on the site station series.
May 2007
130
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Again, these features are represented in the APDM with null shapes, but are referenced to
both the site and the site station series.
The following two explicit examples depict how Sites can be used to track facilities:
•
Uninstalled stockpiles of pipe are stored within a site. These pipe stock piles
employ the same attributes as in-service pipes, including MillTestPressure and
HeatNumbers. They can be tracked for inventory purposes by storing them as
PipeSegment features without shapes, but with a reference to the site.
•
A company may be responsible for operating meter stations (together with other
associated features such as instruments, valves etc.) located off the main line
(from 100ft to 1-2 miles). Tracking the information (inspection and reading
activities, history, audit trail etc.) about these offline meter stations (sites) is
required. Again, facilities and equipment in these offline meter stations may be
managed by storing them as null-shape features in the APDM incorporating a
reference to the site.
In both of these examples, no station series or line loop traverses the site locations. In
APDM 3.0, it is impossible to store such features without creating new non-stationed
object classes corresponding to the stationed online feature classes. In APDM 4.0, adding
the SiteEventID to facilities classes inheriting from the ‘OnlineFacility’ APDM Abstract
Class creates several data management and display options:
•
If an online facilities feature has a StationSeriesEventID, station value(s) and
SiteEventID value, then the feature shows up in ArcMap as a geometric feature
within or associated with the site.
•
If an online facilities feature has a StationSeriesEventID and SiteEventID value,
but no station value, it has no geometry and thus does not display directly in
ArcMap. However, the feature is still a child of the station series and is displayed
in the feature attribute table, or by traversing the station series’ or site’s
relationship classes using the Identify tool.
•
If an online facilities feature has a SiteEventID only (and no geometry), it is thus
associated with the site as a non-geometric feature. It is not slaved directly to the
pipeline centerline (and hierarchy) by virtue of not having a
StationSeriesEventID, but is nonetheless associated with the site. The feature does
not display directly in ArcMap, but is displayed in the feature attribute table, or by
traversing the site’s relationship classes using the Identify tool.
•
If an online facilities feature has a SiteEventID and a geometry, but no
StationSeriesEventID, it is thus associated with the site as a geometric feature. It
is not slaved directly to the pipeline centerline (and hierarchy) by virtue of not
ESRI Technical Paper
131
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
having a StationSeriesEventID, but is associated with the site. The feature
displays directly in ArcMap.
With respect to bullet 4 above, note that ‘online’ facility features can be digitized within a
site boundary (such as a compressor station) without any relationship to a station series.
If the feature has a geometry and a SiteEventID value, but no StationSeriesEventID or
station value, it in effect acts as a ‘NonStationed’ facilities feature. This construct is valid
in APDM 4.0. For this reason the ‘NonStationedPipe’ feature class has been deprecated
from APDM 3.0. One other benefit to tracking facility features in this manner is that it
allows for flexible integration with external asset management systems. Examples of the
various situations where non-geometric features are viable are displayed in the following
diagrams:
May 2007
132
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
ESRI Technical Paper
133
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
10.5.4 Topology
The APDM is designed to incorporate topology rather than the geometric network to
ensure data quality and to maintain relationships between features of different feature
classes. A complete discussion of topology and the geometric network is provided under
Implementation Issues. Topology requires that all feature classes that participate with the
topology be present in the same feature dataset. The centerline feature classes– Control
Points and Station Series– are the core of the topology. Therefore, all referenced feature
classes must participate in the topology as well. The APDM stores all feature classes in
the model in the Transmission feature dataset.
10.5.5 Centerline
This section outlines some of the rules or assumptions about the APDM centerline
features.
•
Control points represent the vertices of station series linear features.
•
A station series must be composed of a minimum of two control points (one at the
beginning and one at the end of the station series).
May 2007
134
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
•
Control points and the vertices of station series features share the same measure
values (if the control point and the station series features share the same subtype
value).
•
As vertices of a station series, control points represent distinct and known values
of stationing along a station series. All other stationing values in between control
points are interpolated.
•
Both station series and control points must have the same subtypes.
•
No control point can be related to a station series of a different subtype.
•
The default subtype for control points and station series must be the same.
•
Each default subtype station series must have a control point at every vertex with
a valid station value.
•
Station series are M-Aware simple (non-multipart) polyline features.
•
Station series can be joined at station series endpoints (equation) and along station
series edges (branch).
•
More than one control point can exist at one location (x,y coordinate) in space.
•
More than one control point can exist at one location in space, each having the
same subtype, but each with a different StationSeriesEventID (station equations).
•
Stationing must increase or decrease in value from one end of a station series to
the other without breaks or gaps.
•
Stationing values between two control points on a station series may not be equal
to the calculated 2 or 3 dimensional distance between the two points. However, it
is assumed that the station values can be interpolated as a proportional function of
the distance between the two points.
•
All referenced events (features) have their geometry derived from the geometry of
the station series feature on which they are located.
•
Each control point must belong to one and only one station series of the same
reference mode.
ESRI Technical Paper
135
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
•
Since each reference mode may have a different physical basis for determining
and calculating station values, coincident station series within a LineLoop must
have coincident control points to avoid interpolation errors. Control points must
be propagated to/from all reference modes to each other to reliably locate events
using PRM and ARM station values.
10.5.6 Structure
The APDM contains one feature dataset named Transmission. The technical committee is
convinced, at this point in ESRI's software life cycle, that topology is the most effective
method for managing data integrity and consistency. If topology is implemented for the
APDM, then all feature classes that participate in the topology must be stored in the same
feature dataset. At present, all core and optional feature classes are located in the
Transmission feature dataset.
11.0 Implementation Issues
The following section describes some issues that need to be addressed by an organization
planning to implement the APDM as a geodatabase. The technical committee strives to
provide a data model that can be implemented out of the box using the tools found in
ArcToolbox™, ArcCatalog™, and ArcMap. However, some implementation decisions
require the use of custom code to achieve desired behavior of objects and classes within
the model. Every effort is made to mitigate the need for custom code. The APDM does
encapsulate behavior through the abstract and metadata feature classes, but standard
ESRI geodatabase technology is not currently capable of fully enforcing this behavior
out-of-the-box. The APDM does not include custom feature classes or class extensions to
implement advanced pipeline behaviors. The choices of how the APDM is to be
implemented determine if and when custom code is required to create desired object
behavior.
The optimal platform for the APDM 4 is ArcGIS 9.1 and 9.2. All design and
implementation considerations are based on the technology available at these releases of
ArcGIS.
11.1 The APDM and ‘Inline’ History
The ability to audit the historical state of the pipeline is a regulatory requirement. The
APDM provides mechanisms for storing the history of individual APDM features in the
geodatabase. Collectively these mechanisms are referred to as ‘inline’ history. With the
advent of ArcGIS 9.2, enterprise ArcSDE provides the ability to manage feature history
via Archiving functionality. ArcGIS 9.2 archiving functionality supersedes much of the
APDM’s inline history functionality, but those who are not utilizing enterprise ArcSDE
or archiving may still find APDM inline history useful.
APDM inline history is implemented via a variety of ‘audit’ attributes and data
management practices. These attributes and associated data management practices allow
May 2007
136
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
the storage of multiple historical states for a given feature, together with the current state
of the feature, in the same feature class. (If desired, historical versions of features can be
segregated into separate features classes, as well. See below for a discussion of inline
history physical implementation options.) The audit attributes that are used to implement
inline history are:
•
EventID (String, 38) – The globally unique identifier (GUID) for a feature at
a particular historical state. EventID changes with each successive record
representing a different historical state of a feature.
•
OriginEventID (String, 38) – The original GUID for a feature.
OriginEventID is set to be equal to EventID when a feature is first created.
OriginEventID does not change with successive records representing different
historical states of a feature.
•
CreatedBy (String, 50) – User-ID of the operator who created the feature.
CreatedBy does not change with successive records representing different
historical states of a feature.
•
CreatedDate (Date) – The timestamp the initial record for a feature or object
was created in the database. Because CreatedDate is a database date, it does
not necessarily correspond to the actual effective date of the feature or object
in the real world. CreatedDate may be either earlier or later than
EffectiveFromDate. CreatedDate does not change with successive records
representing different historical states of a feature.
•
EffectiveFromDate (Date) – The date a particular record in the database
went into effect in the real world. EffectiveFromDate should not be confused
with CreatedDate or LastModified. For facility classes, EffectiveFromDate for
the initial record for a feature should correspond to either the InServiceDate or
the InstallationDate for the feature. EffectiveFromDate is modified with each
successive record documenting the historical state of a feature.
•
EffectiveToDate (Date) – The date at which a particular record in the
database is no longer in effect. EffectiveToDate is modified with each
successive record documenting the historical state of a feature. For a database
record that is currently in effect, EffectiveToDate is null.
•
LastModified (Date) – The timestamp for the update of the record in the
database. For the initial record for a feature, LastModified = CreatedDate. The
LastModified timestamp is modified with each successive record documenting
the historical state of a feature.
ESRI Technical Paper
137
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
•
ModifiedBy (String, 50) – User-ID of the operator who last modified the
feature. For the initial record for a feature, ModifiedBy = CreatedBy.
ModifiedBy changes with each successive record representing different
historical states of a feature.
•
HistoricalState (Integer, gnHistoricalState) – A logical flag used to indicate
whether the record represents the current, or a historical state of the
feature/object the record represents. Possible values for HistoricalState are:
Unknown (Verified) – -1, Unknown – 0, Current – 1, Historical – 2. “Current”
is the default value. HistoricalState is included to simplify queries used to
return either current or historical records.
11.1.1 Inline History Implementation
The implementation of inline history is governed by two simple rules:
1. No feature or record is ever deleted from the geodatabase.
2. Each time a significant change in state of a feature occurs, a new record is
generated to reflect the change in state.
Changes in state include the following types of events:
•
•
Spatial edits
o A feature is moved
o An online polyline feature is split as the result of a reroute operation
o An online polyline feature is split or truncated as the result of a new,
overlapping feature of the same type being inserted
Attribute edits
o Status changes
o Data changes
o Data corrections
A ‘significant change in state’ is left for the user to define. Some users of the APDM are
concerned primarily with spatial edits and regard only those as significant changes of
state. Others record every attribute edit as a change of state.
EventID, OriginEventID, CreatedDate, LastModified, EffectiveFromDate,
EffectiveToDate and HistoricalState are required to facilitate audit (history) tracking in
the APDM. These fields store and distinguish multiple records for a single feature that
represent the changing state of the feature over time. For all successive historical records
for a feature, CreatedDate (and CreatedBy) remain constant. LastModified (and
ModifiedBy), EffectiveFromDate and EffectiveToDate change with each successive
record for a feature.
May 2007
138
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
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
1
1
LastModified
2/1/06 2:32 PM
ModifiedBy
User1
CreatedDate
2/1/06 2:32 PM
CreatedBy
User1
HistoricalState
Current
EffectiveFromDate
8/1/2005
InstallationDate
8/1/2005
EffectiveToDate
<NULL>
InServiceDate
1/1/2006
PresentPosition
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
1
2
1
1
LastModified
ModifiedBy
2/1/06 2:32 PM User1
2/9/06 4:15 PM User2
CreatedDate
2/1/06 2:32 PM
2/1/06 2:32 PM
CreatedBy
User1
User1
HistoricalState
Historical
Current
EffectiveFromDate
8/1/2005
2/5/2009
InstallationDate
8/1/2005
8/1/2005
EffectiveToDate
2/5/2009
<NULL>
InServiceDate
1/1/2006
1/1/2006
PresentPosition
Open
Closed
Note that when the second record for the valve is created, the EffectiveToDate value for
the original record is modified and set equal to the EffectiveFromDate value for the new
record. HistoricalState for the original record is set to “Historical”; HistoricalState for the
second record is set to “Current”. These steps are critical in maintaining a pristine audit
trail.
The simplest implementation of APDM inline history is to store all records for the
historical states of a feature in the same feature class as the record representing the
current state of the feature (hence the term ‘inline’ history). A variety of queries facilitate
the extraction of pertinent information from the APDM geodatabase:
•
To retrieve only the current records from a feature class:
o SELECT * FROM <class> WHERE HistoricalState = 1
•
To retrieve only the historical records from a feature class:
o SELECT * FROM <class> WHERE HistoricalState = 2
ESRI Technical Paper
139
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
•
To retrieve all historical states from a feature class, sorted by
EffectiveFromDate:
o SELECT EffectiveFromDate FROM <class> ORDER BY
EffectiveFromDate
•
To retrieve only the previous state of feature with OriginEventID = ‘X’:
o SELECT * FROM <class> WHERE OriginEventID = ‘X’ AND
EffectiveToDate = (SELECT EffectiveFromDate FROM <class> WHERE
OriginEventID = ‘X’ AND HistoricalState = 1)
One possible modification to the default 'inline' history implementation is to segregate
historical records into a series of ‘archive’ feature classes (into a separate Transmission
feature dataset and feature classes, or even into a separate geodatabase). This may be
desired to maximize query performance on 'current' features, or simply to avoid the
necessity of implementing definition queries in ArcMap to access only current records for
features. This type of implementation is referred to as 'offline' history storage. If
implementing 'offline' history storage, one should make sure to duplicate the entire
'online' schema for the 'offline' historical features.
There are two basic implementations of offline history storage. In both implementations,
the main geodatabase stores only current records, and the offline archive stores historical
records. In the first variation, the offline archive is actually a complete implementation of
inline history, storing both current and historical records in the offline archive. In this
variation, current records are duplicated, being stored in both the main geodatabase and
the offline archive. In the second variation of offline history storage, only historical
records are stored in the offline archive.
Offline history storage has one potential advantage over inline history storage. With
inline history storage, multiple historical versions of a single feature may be present in
the geodatabase. When a topology feature class is used to manage coincident geometries
in the APDM, bear in mind that the topology feature class cannot distinguish between
current and historical records. Historical records may accidentally be modified when
using the out-of-the-box topology edit tools. The use of offline history storage can help
ameliorate this situation.
At ArcSDE 9.2 and higher, Archiving functionality is available to maintain audit history
on features. This functionality makes 'inline' and 'offline' history implementations largely
superfluous. However, the APDM audit fields are still useful as defined. The reason for
this is that Archiving tracks the times at which modified records are posted to
SDE.Default and at which original or deleted records are rolled into the archive tables.
The archiving time stamp is not the exact equivalent of any of the APDM audit date
fields.
May 2007
140
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
If taking advantage of ArcSDE 9.2 Archiving, one will not be able to make use of
EffectiveToDate and HistoricalState. The reason for this is that modified and deleted
records are automatically rolled from SDE.Default to the archive tables during the
geodatabase ‘post’ operation. There is no opportunity to update either EffectiveToDate or
HistoricalState on the original record in SDE.Default.
Similarly, Archiving functionality users will find OriginEventID largely superfluous.
While one may choose to continue using this attribute, ArcSDE Archiving functionality
automatically maintains the relationship between successive records for a feature.
Therefore, one additional advantage of ArcSDE Archiving functionality is that EventID
for a feature can remain constant.
11.2 Using the APDM in a Versioned Geodatabase Environment
Because of its heavy reliance on ESRI linear referencing technology, the APDM is a
‘relationship-rich’ data model. For instance, StationSeries implements a 1:M relationship
with every online feature class in the model. In practical terms, this means that a single
station series feature could conceivably be related to hundreds of thousands of online
features.
The relationships between station series and online features have profound implications
for centerline editing in a versioned geodatabase environment. Great care should be taken
to ensure that centerline (StationSeries) edits are not performed in sibling geodatabase
versions, or in any version that is a parent to outstanding child versions. The reason for
this is that reconcile and post operations on dependent sibling or child versions could
potentially result in extremely large numbers of spurious data conflicts. Bear in mind that
when editing a station series feature with large numbers of related online features,
ArcSDE has no knowledge of which portion of the station series feature was edited; all
ArcSDE knows is that the station series feature was edited. If a child or sibling version is
outstanding during such an edit, every online feature related to the station series will be
flagged as a potential data conflict when the child or sibling version is reconciled with the
parent version.
In practice, centerline edits should be performed on geodatabase versions that inherit
directly from SDE.Default. A separate geodatabase version should be created for each
centerline editing activity on a particular line segment (line loop or station series).While
this ‘centerline edit version’ is in existence, no edits (centerline or otherwise) should be
performed on the same line segment in any other outstanding geodatabase version. This
type of logic can be implemented either through business practices, or through
application software, but it is important to note that ArcMap does not implement this type
of functionality out-of-the-box.
ESRI Technical Paper
141
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
11.3 Features as Events, Events as Features
Point and linear events occur along routes at specified measures along the routes. Event
layers/tables are considered "dynamic feature classes." The position of each event in an
event table can be recalculated dynamically when the Route-ID and/or Measure value for
the event are updated in the underlying event table. The advantage of this approach is that
the geometry of features is updated when the underlying linear referencing information is
changed. The disadvantage of the event model is that performance can become untenable
for events layers with tens of thousands of features. Not all the analytical functionality of
ArcGIS can be applied to event layers.
Another approach to implementing the APDM is to use feature classes rather than event
tables to store the geometry. Using feature classes allows access to all the analytical
functionality of ArcGIS. However, there is no dynamic response that rebuilds the
geometry of the features when the linear referencing information is altered. Custom code
is required to implement "features as events" behavior.
11.4 Topology and the Geometric Network
Transmission pipelines have many coincident features whose position is derived from the
centerline– in effect, features are essentially dynamic events. These features are
geometrically coincident with the underlying centerline. This is the geometric basis for
transmission pipeline– everything is located via stationing. Topology provides a
mechanism to identify dependent features that must also be updated when edits to
features and/or the centerline occur.
Topology is a set of rules that define where features should be in space in relation to each
other. The rules define the permissible geometric relationships between features. The
underlying reason for using topology in the transmission pipeline environment is that
some features (pipes, costing, pressure tests) are dependent on the location (or lack
thereof) of other features (station series, etc.). Not only are features dependent on the
centerline for positioning, but features are also dependent on other features for existence
(coating and pressure tests require that pipe segments be present). When the source
feature is removed, the dependent features must also be removed.
Topology, at the current time, provides the best tools for managing pipeline spatial data
integrity. The rules of topology define how pipeline features' geometries relate to each
other. Ranks can be set for each feature class participating in the topology to determine
which features are salient and which can be altered to maintain integrity. Topology errors
can be examined and repaired with a wide variety of out-of-the-box ArcMap topology
editing tools. Shared geometry editing ensures that coincident features participating in a
topology move together as edits are performed. "Dirty areas" appear for points, lines, and
polygons whenever edits occur that may affect topology integrity. Topology exists as a
structure within the geodatabase, and, for all intents and purposes, acts as another feature
layer in ArcCatalog and ArcMap.
May 2007
142
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Some general guidelines and rules to keep in mind when implementing a topology are
listed below.
•
Annotation, dimension, and geometric network features are complex features and
cannot participate in a topology.
•
Multiple topologies can exist in a single feature dataset.
•
One feature class can participate in only one topology.
•
A topology and a geometric network can coexist in the same feature dataset, but
they cannot share a participating feature class.
•
Topology performance is based on the number of feature segments (two points
and a line). Linear features consist of one or more feature segments.
•
The number of rules has relatively little effect on performance, but
inappropriately or overly defined rules hurt performance since each error that is
generated for a topology is an error that is written into the geodatabase.
•
Using subtypes increases performance since fewer cursors are generated during
processing.
•
There is no recommended upper limit to the number of feature classes that may
participate in a topology.
The geometric network is an excellent tool for analysis purposes and for editing features.
The network does not account for stationing nor does it account well for coincident linear
features. A geometric network only allows one linear feature to participate in the network
at one location in space. Since stationing is such an integral part of pipeline operations,
the benefits of the geometric network do not outweigh those of topology from a data
editing and maintenance standpoint. However, the geometric network is a versatile tool
for analysis. A recommendation is that organizations requiring a geometric network for
analysis generate the geometric network as a stand-alone dataset stored in a separate
feature dataset. Because a topology feature class can be defined in such a way as to
enforce network connectivity, creating a geometric network from features in the
Transmission feature dataset is a simple matter.
11.5 Developing Applications
The delineation of the core elements of the APDM provides a standard framework for
application developers and software vendors to develop portable applications that work
on most, if not every, properly implemented APDM. It is suggested that application
ESRI Technical Paper
143
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
developers write applications that respond to the core attributes and feature classes in the
model according to the specifications recorded in this document. Applications should be
responsive to the variations in other feature classes and attributes. The APDM is designed
to provide a core set of objects that remain constant from model to model. The remaining
objects in the APDM are suggestions only, based on common implementation of many
pipeline companies' standard features. Applications written for the APDM should
respond dynamically to objects that are defined within the APDM beyond the core
elements.
11.6 The APDM and Other Pipeline Data Models
The APDM is similar in many ways to its pipeline data model predecessors: ISAT,
PODS, and ISPDM. Conceptually, the APDM may be construed as a superset of these
earlier models. The ISAT, PODS and ISPDM models are designed for industry-standard
relational database management systems. While there are conceptual similarities to these
earlier models, the user must always bear in mind that the APDM is uniquely designed to
fully exploit ESRI geodatabase technology. The feature classes in the APDM were
designed independently from the tables contained in the ISPDM, ISAT, and PODS
models, but many of the salient attributes found in the feature classes of the APDM have
counterparts in the attributes of the tables in the PODS, ISAT, and ISPDM models. The
geodatabase, and thus the APDM, incorporates a relational database engine to store an
object-relational model that extends standard RDBMS technology. Although the content
and underlying technology of the PODS, ISAT, and ISPDM models and the APDM are
similar, the access methods used to manipulate the structure and content of these models
are very different.
An enterprise geodatabase is an object-relational database management system. The
standard technologies used to access data in a RDBMS such as Structured Query
Language (SQL), Open Database Connectivity [ODBC] or Microsoft ActiveX Data
Objects [ADO] are not designed to access data stored in a geodatabase. The primary
method for customizing and accessing the data stored in the APDM is through the core
ESRI ArcGIS technology (such as ArcMap) and its underlying component model,
ArcObjects™. This is not to say that all SQL-related functions will not perform against a
geodatabase, rather the applicability of SQL is limited. Data definition queries (DDL)
cannot safely be executed on schema that is versioned. Data manipulation queries (DML)
for the purposes of retrieval and updating are possible (through ADO, multi-version
views and the ESRI OLEBD data provider); however, the results may be unsatisfactory
due to perceived limitations of multiple domains assigned to the same fields based on
subtype value, and the non-resolution of domain values during query run-time. Users
attempting insert, update and delete operations using standard database access techniques
need to be aware of the potential impacts to the underlying geodatabase. Executing these
kinds of statements without due diligence can irretrievably corrupt the data stored within
a geodatabase (especially when the geodatabase is in a versioned state).
May 2007
144
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
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 multiuser 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 filebased geodatabase (at ArcGIS 9.2).
11.7 Conversion To/From PODS and ISAT
The recommended conversion of PODS and ISAT data to the APDM is as follows:
•
Convert PODS/ISAT control points to APDM control points.
•
Convert PODS/ISAT station series to APDM station series.
•
Convert PODS routes as APDM "continuous" station series.
•
Convert each feature/event table to an APDM event table/feature class, making
note to delineate the begin/end station series EventID attribute, begin/end station
attribute, the begin/end offset angle, and distance and side attributes for on/offline
features.
•
Import non-referenced features with geometry as required.
11.8 Getting Data into the Model
The simplest approach to creating data in the APDM is to:
•
Import control points from a source containing x,y coordinates, station value, and
an ID field that can be used to group the control points.
•
Digitize station series features from the control points using the station value to
order the control points sequentially. Calibrate the measure values of the station
series features using the station values of the control point features.
•
Import the ID field used to group the control points into the station series feature
to establish the relationship between control points and station series.
•
Update the begin/end station values of each station series feature from the
measured value contained in the from/to points of the station series feature.
ESRI Technical Paper
145
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
•
Import event tables containing features. Event tables must have a field that
contains a Route-ID value found in the EventID of a station series feature. Point
event tables must have an attribute named BeginStation containing valid station
values along a station series route feature. Linear event tables must have two
attributes (BeginStation, EndStation).
•
Use the event tables to generate event themes.
•
Convert the event themes to feature classes in the model.
12.0 Model Future
The intellectual property of the ArcGIS Pipeline Data Model is owned by ESRI. The
content and structure of the model is determined by the APDM steering and technical
committees. The positions on the APDM steering and technical committees are elected
by members of the ESRI Pipeline Interest Group (PIG). Contact Bill Meehan at
[email protected], or any APDM steering or technical committee member for more
information on serving on the APDM technical or steering committees.
The APDM technical committee meets twice a year, at the following venues, to discuss
proposed improvements and alterations to the model.
•
ESRI Petroleum User Group Meeting (February/March)
•
APDM User Group Meeting at the ESRI User Conference (June/July/August)
If you have any suggestions for changes or requests for information please contact:
•
Craig Wilder (El Paso Corporation [email protected] (Steering Committee
Chairperson)
•
Peter Veenstra (Eagle Information Mapping) [email protected] (Technical
Committee Chairperson)
•
Robert Brook (ESRI Pipeline Industry Manager) [email protected]
May 2007
146
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Appendix A - Standards and Conventions
The following standards and conventions for naming object, feature and relationship
classes are used in the APDM. These standards are applied to the whitepaper, the logical
model diagram and the physical model.
Naming Conventions
Class Names
Some RDBMS’s have restrictions on table name lengths. In particular, Oracle restricts
table names to no more that 30 characters. All object and feature classes, and M:N
relationship classes are implemented as physical tables in the RDBMS, so paying
attention to name length for such objects is important. In addition, ArcSDE 9.2 archiving
functionality appends an ‘_H’ to the names of the tables storing archived objects.
Therefore, Object, M:N Relationship, and Feature class names for concrete classes are
restricted to 28 characters in length. Assigned names are complete words (if possible) that
describe the contents of the class. Names that comprise two elements (such as
StationSeries) are documented using ‘CamelCase’ or ‘CamelBack’ notation (the first
letter of each word is capitalized). Class names do not utilize the under bar (_) character
to separate elements within the name.
Similarly, the naming convention for Relationship Classes is to concatenate the names of
the objects being related to each other via the class. The name starts with the origin class
and then appends the name of the destination class as follows:
<OriginClass><DestinationClass>
The <OriginClass> represents the Object Name of the Origin Class of the Relationship
Class and <DestinationClass> represents the Object Name of the Destination Class of the
Relationship Class. If any default relationship class name exceeds 30 characters, it is
reduced to 30 characters. To accomplish this, two methods of truncating the name are
used:
•
Method 1 - Parse and remove elements within the name of the Origin Object
Class such that the resulting name is 30 characters long. Removal of letters is
performed using commonly accepted truncations, e.g. the word ‘Location’ is
shortened to Loc.
•
Method 2 - Truncate the concatenated name to 30 characters.
Consider a relationship between the Object Classes LineCrossingLocation and
AltRefMeasure. The default concatenated name is LineCrossingLocationAltRefMeasure,
which is 33 characters long. Using Method 2, the Relationship Class name is
LineCrossingLocationAltRefMeas. Using Method 1, the Relationship Class name is
ESRI Technical Paper
147
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
LineCrossingLocatAltRefMeasure (30 characters) or LineCrossingLocAltRefMeasure
(28 characters).
Foreign Keys
Foreign keys (a relationship attribute maintained in the destination class for a simple 1:M
relationship class) are named using the Origin Class name and the word ‘EventID’ as
follows:
<ForeignClass>EventID
The <ForeignClass> represents the name of the Origin Feature/Object Class participating
in the relationship with the class containing the foreign key attribute.
Use of Feature Datasets
A geodatabase provides a way of storing thematically similar features together in what is
called a Feature Dataset. A Feature Dataset is analogous to a folder created in a disk
drive. Folders and Feature Datasets are used to store data that are similar to each other in
an aspect that denotes a logical or semantic grouping. Feature Datasets are primarily used
to store a collection of Feature Classes in the geodatabase that have something in
common. Another use for a Feature Dataset is the creation of a Topology and/or a
Geometric Network. One of the requirements for building a Topology within ArcGIS is
that all Feature Classes participating in the Topology must be contained in the same
Feature Dataset. The same principle applies for all Features Classes participating in a
Geometric Network. The APDM requires that all Feature Classes that implement or
inherit from ‘OnlineFeature’, ‘CenterlinePoint’, or ‘CenterlinePolyline’ must be grouped
in a single Feature Dataset named “Transmission”.
Two other aspects of the Feature Dataset are worth mentioning. First, the Feature Dataset
enforces a standard spatial reference (including precision and X, Y, Z and M extents) for
all Feature Classes that are stored within the Feature Dataset. Secondly, storing Feature
Classes in Feature Datasets provides easier administration of the database objects, such as
versions and permissions. Using Oracle as an example, if the underlying relational
database management system (RDBMS) environment is configured properly, tablespace
backup of specific feature datasets can be performed.
Feature Classes that inherit from OfflineFeature or OfflineFacility can have a different
spatial reference than that defined for the centerline (StationSeries and ControlPoint) in
the ‘Transmission’ Feature Dataset. (In this case, such feature classes must be stored in a
separate feature dataset.) Object classes (tables) are stored and displayed at the root level
of the geodatabase.
For a more complete explanation of Feature Datasets, please refer to the ESRI document
“Understanding ArcSDE”.
May 2007
148
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Maximum String Size
The maximum allowable string field length varies depending on the underlying RDBMS
being used for ArcSDE. The current UML model diagram of the APDM physical model
simply uses a string field type (esriFieldTypeString) to describe fields larger than 255
characters. If the default APDM UML is used to build a geodatabase, then any field
implementing a string larger than 255 characters or defined as a type not supported by the
target underlying geodatabase needs to be reconciled.
This has implications for any string attribute field in the APDM, and in particular the
fields defined in the RemovedPoint and RemovedLine Feature Classes. Implementers of
the APDM must address these two attributes (and any others with a string length greater
than 255 characters) by changing the physical UML model with string length settings
appropriate to the target RDBMS being used to host the geodatabase. Of course, any
changes to the APDM physical model should be noted and documented in a log file or
manual by the implementer and/or consultant. The following table depicts the maximum
string length supported by some industry standard RDBMS software.
RDBMS
Oracle
Oracle
SQL Server
SQL Server
DB2
Informix
MS Access
String Data Type
VarChar
VarChar2
Char
Text, NText
?
?
Memo
Maximum Length
2000
?
8000
2 Gb
?
?
63K
Documentation Standards
The following are the standards and conventions for describing object/feature classes and
relationship classes.
Object or Feature Class
Class Name:
Feature Class
Geometry:
APDM
Inheritance:
Name of the Class
Describe geometry as “Implemented as an M-Aware Polyline
feature class” or “Implemented as an Object Class” or
“Implemented as an Object Class used to build ‘Event’ themes.
List the APDM abstract and ESRI Core classes from which this
class inherits or is derived.
Top Class (Ancestor) Æ Next Class (Ancestor) Æ Parent
(Ancestor) Æ ClassName (Concrete)
Example:
ESRI Simple Object Æ ESRI Simple Feature (Optional) Æ
ESRI Technical Paper
149
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Attributes:
(name, type,
length, precision,
scale, domain,
description)
Relationships:
(cardinality,
optionality,
attributes,
composite)
FeatureArchive (Abstract) Æ CenterlinePolyline (Abstract)
Æ ClassName (Concrete)
Describe each attribute by name, type, (length, precision, scale, and
domain name if applicable) and a description of the attribute
including a reason why it was incorporated in the model.
Example:
EventID (GUID, String, 38) – A globally unique identifier for the
class.
OperationalStatus (Long Integer, 9) gnOperationalStatus (required
APDM domain) – A domain value indicating the status of a
feature that has some ‘operational’ lifespan based on the US
Federal Energy Regulatory Commission (FERC) and Office of
Pipeline Safety (OPS) definitions. Applied to centerline features
or facility features with complex operational lifespans. The
gnOperationalStatus domain is considered a ‘core’ APDM
domain that ‘inherits’ values from the ‘gnStatus’ domain and
must be implemented verbatim.
Describe the relationships this class has to other classes in the
model. The format for describing relationships is to list the name,
if the relationship is considered Core (and therefore must be
implemented), the origin class, the relationship cardinality and
the destination class.
RelationshipName (Core): OriginClass is 1:M with
DestinationClass
SubTypes:
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
1 – Subtype One
2 – Subtype Two
etc.
Attributed Relationship Class
Class Name:
Feature Class
Geometry:
Attributes:
May 2007
The name of the relationship class.
Describe geometry as “Implemented as an M-Aware Polyline
feature class” or “Implemented as an Object Class” or
“Implemented as an Object Class used to build ‘Event’ themes.
Implemented as an attributed many-to-many relationship class.
Describe each attribute by name, type, (length, precision, scale, a
150
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
(Name, type,
length, precision,
scale, domain,
notes)
Related Tables:
domain name if applicable) and a description of the attribute
including a reason why it was incorporated in the model.
CompanyEventID (String, 38) – Foreign key to the Company object
class.
LineLoopEventID (String, 38) – Foreign key to the Company
object class.
ParticipantPercentage (Long Integer, 9) – (Default = 0) –
clParticipantPercent – Percentage (0–100%) of ownership.
ParticipantType (Long Integer, 9) – (Default = 0) –
cParticipantType – Type of participation, e.g. ‘Ownership’,
‘Operator’.
List the name of the origin and destination object/feature classes
that participate in the relationship.
Company: Origin
LineLoop: Destination
ESRI Technical Paper
151
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Appendix B - Glossary
A
Abstract Classes
In ArcObjects, a specification for subclasses that is often shown on object model
diagrams to help give structure to the diagram. An abstract class is not defined in a type
library and cannot be instantiated.
In the APDM, abstract classes are a collection of broad data type categories, each of
which has its own defined behaviors, and are used to coarsely define the semantic
behavior of the various feature and object classes in the APDM.
APDM
APDM stands for ArcGIS Pipeline Data Model.
The ArcGIS Pipeline Data Model is designed for storing information pertaining to
features found in gathering and transmission pipelines, particularly gas and liquid
systems.
The APDM was expressly designed for implementation as an ESRI geodatabase for use
with ESRI's ArcGIS and ArcSDE® products.
APDM core classes
Core elements in an APDM geodatabase that maintain the semantic framework and
behavior of the model. For an APDM- compliant geodatabase implementation, core
classes must be implemented with the same names, attributes and relationship classes as
described in the APDM Whitepaper.
Arc-node topology
The data structure in a coverage used to represent linear features and polygon boundaries
and to support analysis functions, such as network tracing. Nodes represent the beginning
and ending vertices of each arc. Arcs that share a node are connected, and polygons are
defined by a series of connected arcs. An arc that intersects another arc is split into two
arcs. Each arc that defines all or part of a polygon boundary records the number of the
polygon to its left and to its right, giving it a direction of travel.
May 2007
152
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Attribute
Information about a geographic feature in a GIS, usually stored in a table and linked to
the feature by a unique identifier. For example, attributes of a river might include its
name, length, and average depth.
In raster datasets, information associated with each unique value of raster cells.
Information that specifies how features are displayed and labeled on a map; the graphic
attributes of a river might include line thickness, line length, color, and font for labeling.
Attribute data
See Also: nonspatial data
Tabular or textual data describing the geographic characteristics of features.
Attribute domain
See Also: Coded value domain, Domain, Range domain
In a geodatabase, a mechanism for enforcing data integrity. Attribute domains define
what values are allowed in a field in a feature class or nonspatial attribute table. If the
features or nonspatial objects have been grouped into subtypes, different attribute
domains can be assigned to each of the subtypes.
Attribute table
See Also: Text attribute table
A database or tabular file containing information about a set of geographic features,
usually arranged so that each row represents a feature and each column represents one
feature attribute. In raster datasets, each row of an attribute table corresponds to a certain
zone of cells having the same value. In a GIS, attribute tables are often joined or related
to spatial data layers, and the attribute values they contain can be used to find, query, and
symbolize features or raster cells.
B
Baseline Assessment Plan (BAP)
See Also: Integrity Management Plan
A plan of inline inspections, direct assessment and close interval survey inspections to
determine the structural integrity and health of a pipeline. A BAP is an integral part of an
Integrity Management Plan (IMP)
ESRI Technical Paper
153
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Boundary
A line separating adjacent political entities, such as countries or districts; adjacent tracts
of privately-owned land, such as parcels; or adjacent geographic zones, such as
ecosystems. A boundary is a line that may or may not follow physical features, such as
rivers, mountains, or walls.
C
CAD
Acronym for Computer Aided Design. Software and techniques used to render schematic
diagrams representing facilities or mapped area on or along a pipeline system.
Cathodic Protection
The prevention of electrolytic corrosion of a usually metallic structure (as a pipeline) by
causing it to act as the cathode rather than as the anode of an electrochemical cell
Centerline
A line digitized along the center of a linear geographic feature, such as a street or a river
that at a large enough scale would be represented by a polygon.
CIS
Acronym for Close Interval Survey. A procedure where soil loss potential measurements
are taken from a pipeline by a person stabbing a thin metal wire into the ground spaced
by a regular distance from the previous measurement.
Class
See Also: Abstract Classes; Concrete Class
1. A set of entities grouped together on the basis of shared attribute values.
2. Pixels in a raster file that represent the same condition.
3. A template for a type of object in an object-oriented programming language. A class
is used to create objects that share the same structure and behavior.
4. In Arc Web Services, a set of one or more types of features in the data. Each class has
an associated set of symbols. The symbol used for a class may vary depending on the
map scale and style.
May 2007
154
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
CLSID
See Also: GUID
Acronym for class identifier. Refers to the globally unique number that is used by the
system registry and the COM framework to identify a particular co-class.
Coded value domain
See Also: Domain
A type of attribute domain that defines a set of permissible values for an attribute in a
geodatabase. A coded value domain consists of a code and its equivalent value. For
example, for a road feature class, the numbers 1, 2, and 3 might correspond to three types
of road surface: gravel, asphalt, and concrete. Codes are stored in a geodatabase, and
corresponding values appear in an attribute table.
Coincident
Occupying the same space. Coincident features or parts of features occupy the same
space in the same plane. In geodatabase feature classes, vertices or boundaries that fall
within the set cluster tolerance of one another are coincident; they are snapped together
during the validate topology process.
Coincident geometry
See Also: Topology
In a geodatabase, how the coordinates of coincident features are stored. For example, if
two lines are coincident, they are both drawn in ArcMap, with one line lying precisely on
top of the other. For two adjacent polygons, the coordinates for the shared boundary are
stored with each polygon and the boundary is drawn twice.
COM
Acronym for Component Object Model. A binary standard that enables software
components to interoperate in a networked environment regardless of the language in
which they were developed. Developed by Microsoft, COM technology provides the
underlying services of interface negotiation, life cycle management (determining when an
object can be removed from a system), licensing, and event handling. The ArcGIS system
is created using COM objects.
Concrete Class
See Also: Abstract Classes
ESRI Technical Paper
155
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
A feature or object class that is implemented within the Geodatabase. Within APDM a
concrete class may inherit attributes and relationships from one or more APDM Abstract
Classes.
Constraints
Limits imposed on a model to maintain data integrity. For example, in a water network
model, an 8-inch pipe cannot connect to a 4-inch pipe.
Control point
An accurately surveyed coordinate location for a physical feature that can be identified
on the ground. Control points are used in a least squares adjustment as the basis for
improving the spatial accuracy of all other points to which they are connected.
One of various locations on a paper or digital map that has known coordinates and that is
used to transform another dataset--spatially coincident but in a different coordinate
system--into the coordinate system of the control point. Control points are used in
digitizing data from paper maps, in georeferencing both raster and vector data, and in
performing spatial adjustment operations such as rubber sheeting.
Coordinate system
A reference framework consisting of a set of points, lines, and/or surfaces, and a set of
rules, used to define the positions of points in space in either two or three dimensions.
The Cartesian coordinate system and the geographic coordinate system used on the
earth's surface are common examples of coordinate systems.
Coordinates
See Also: Geographic coordinates, x,y coordinates
Values represented by x, y, and possibly z, that define a position in terms of a spatial
reference framework. Coordinates are used to represent locations on the earth's surface
relative to other locations.
CP
See Also: Cathodic Protection
cp – The prefix used for the Cathodic Protection domains.
May 2007
156
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Core Classes
In the APDM, those abstract, feature, object and relationship classes, and domains, that
must be implemented to attain APDM compliance.
Crows Feet
A database modeling term used to describe the end symbol on a relationship represent
‘many’ or ‘one or more’.
D
Database
See Also: Geodatabase
One or more structured sets of persistent data, managed and stored as a unit and generally
associated with software to update and query the data. A simple database might be a
single file with many records, each of which references the same set of fields. A GIS
database includes data about the spatial locations and shapes of geographic features
recorded as points, lines, areas, pixels, grid cells, or TINs, as well as their attributes.
Data model
See Also: Data structure
In GIS, a mathematical paradigm for representing geographic objects or surfaces as data.
The vector data model represents geography as collections of points, lines and polygons;
the raster data model represents geography as cell matrixes that store numeric values; the
TIN data model represents geography as sets of contiguous, non-overlapping triangles.
In ArcGIS, a set of database design specifications for objects in a GIS application. A data
model describes the thematic layers used in the application (for example, counties, roads,
hamburger stands); their spatial representation (for example, point, line, or polygon);
their attributes; their integrity rules and relationships (for example, streets cannot selfintersect, 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.
ESRI Technical Paper
157
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Dataset
See Also: Feature dataset
Any organized collection of data with a common theme.
Data source
Any data. Data sources may include coverages, shapefiles, rasters, or feature classes.
DBA
Acronym for Database Administrator. The person responsible for the creation,
management and monitoring of a Relational Database Management System (RDBMS)
implementation for integrity and performance purposes.
DLL
Acronym for dynamic link library. A type of file that stores shared code to be used by
multiple programs (a "code library"). Programs access the shared code by linking to the
.dll file when they run, a process referred to as dynamic linking. The .dll file must be
registered for other programs to locate it.
Domain
See Also: Attribute domain, Coded value domain, Range domain
A group of computers and devices on a network that are administered as a unit with
common rules and procedures. Within the Internet, a domain is defined by IP address. All
devices sharing a common part of the IP address are said to be in the same domain.
The range of valid values for a particular metadata element.
Domain name
See Also: Domain
The unique name of a computer system on the Internet, such as www.apdm.net
Domain names (Namig Convention) in the APDM
cl – domains applied to centerline feature and object classes
cp – cathodic protection domains.
en – domains applied to feature classes pertaining to feature classes modeling
encroachments to the pipeline.
fc – domains applied to facility feature classes.
May 2007
158
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
gn (generic) – domains that are applied to object classes and many different
feature classes across the model.
in – domains applied to inspection feature classes.
op – domains applied to feature classes pertaining to pipeline operations.
Dynamic segmentation
The process of calculating the shapes of point and line route events at run time.
E
Edge
In a network system, a linear feature (for example, a pipeline in a sewer system) through
which a commodity, such as information, water, or electricity flows.
In a geometric network, a network edge can be simple or complex. A simple edge is
always connected to exactly two junction features, one at each end. A complex edge is
always connected to at least two junction features at its endpoints, but it can also be
connected to additional junction features along its length.
In a network dataset, a network edge is only connected to two junctions at its endpoints.
Elevation
The vertical distance of a point or object above or below a reference surface or datum
(generally mean sea level). Used especially in reference to vertical height on land.
Equation
A deliberate break in the monotonicity of stationing along a Lineloop. Equations
represent the start or end of a station series of a different reference within a given
Lineloop. Equations are sometimes referred to as Station Equations.
Event
See Also: route event, temporal event, x,y event
A geographic location stored in tabular rather than spatial form. Event types include
address events, route events, x,y events, and temporal events.
EventID
Provides a mechanism for uniquely identifying each feature or object in the geodatabase
independent of the feature or object class to which it belongs.
ESRI Technical Paper
159
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Event layer
In ArcGIS, a layer created from an event table.
Event table
A data source containing location information in tabular format (called events) that is
used to create a spatial dataset. For example, an event table might contain x,y coordinates
or routes.
Extrapolation
In GIS, using known or observed data to infer or calculate values for unobserved times,
locations or other variables outside a sampled area. In the absence of data, extrapolation
may be a good method for making predictions, but it is not always accurate. For example,
based on observed economic indicators, an economist can make predictions about the
state of the economy at a future time. These predictions may not be accurate because they
cannot take into account seemingly random events such as natural disasters.
F
Feature
A representation of a real-world object on a map.
Feature class
A collection of geographic features with the same geometry type (such as point, line, or
polygon), the same attributes, and the same spatial reference. Feature classes can be
stored in geodatabases, shapefiles, coverages, or other data formats. Feature classes allow
homogeneous features to be grouped into a single unit for data storage purposes. For
example, highways, primary roads, and secondary roads can be grouped into a line
feature class named "roads." In a geodatabase, feature classes can also store annotation
and dimensions.
Feature data
Data that represents geographic features as geometric shapes.
Feature dataset
A collection of feature classes stored together that share the same spatial reference; that
is, they have the same coordinate system, and their features fall within a common
May 2007
160
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
geographic area. Feature classes with different geometry types may be stored in a feature
dataset.
Feature layer
See Also: Layer
A layer that references a set of feature data. Feature data represents geographic entities as
points, lines, and polygons.
G
Geodatabase
See Also: Database
A collection of geographic datasets for use by ArcGIS. There are various types of
geographic datasets, including feature classes, attribute tables, raster datasets, network
datasets, topologies, and many others. There are various styles of Geodatabase including:
personal, file-based, workgroup, and enterprise.
Geographic coordinates
See Also: Geographic Coordinate System
A measurement of a location on the earth's surface expressed in degrees of latitude and
longitude.
Geographic coordinate system
A reference system that uses latitude and longitude to define the locations of points on
the surface of a sphere or spheroid. A geographic coordinate system definition includes a
datum, prime meridian, and angular unit.
Geographic data
Information about real-world features, including their shapes, locations, and descriptions.
Geographic data is the composite of spatial data and attribute data.
Geometric coincidence
The distance within which features in a geometric network are deemed to be coincident
and, therefore, connected.
ESRI Technical Paper
161
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Geometric network
Edge and junction features that represent a linear network, such as a utility or hydrologic
system, in which the connectivity of features is based on their geometric coincidence. A
geometric network does not contain information about the connectivity of features; this
information is stored within a logical network. Geometric networks are typically used to
model directed flow systems.
Geometry
The measures and properties of points, lines and surfaces. In a GIS, geometry is used to
represent the spatial component of geographic features.
Georeferencing
Aligning geographic data to a known coordinate system so it can be viewed, queried, and
analyzed with other geographic data. Georeferencing may involve shifting, rotating,
scaling, skewing, and in some cases warping or rubber sheeting the data.
GIS
See Also: Model, Spatial data
Acronym for geographic information system. An integrated collection of computer
software and data that people use to view and manage information about geographic
places, analyze spatial relationships, and model spatial processes. A GIS provides a
geographic framework for gathering and organizing spatial data and related information
into layers of data that can be displayed and analyzed.
GPS
Acronym for Global Positioning System. A system of geosynchronous, radio-emitting and
receiving satellites used for determining positions on the earth. The orbiting satellites
transmit signals that allow a GPS receiver anywhere on earth to calculate its own location
through triangulation. Developed and operated by the U.S. Department of Defense, the
system is used in navigation, mapping, surveying, and other applications in which precise
positioning is necessary.
GUI
Acronym for graphical user interface. A software display format of the input and output
of a program that lets the user choose commands by pointing to icons, dialog boxes, and
lists of menu items on the screen, typically using a mouse. This contrasts with a
command line interface where communication is accomplished via the exchange of
strings of text.
May 2007
162
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
GUID
See Also: CLSID
Acronym for globally unique identifier. A string used to uniquely identify an interface,
class, type library, or component category.
H
Hierarchical database
See Also: database
A database that stores related information in a tree-like structure, where records can be
traced to parent records which in turn can be traced to a root record.
High Consequence Area (HCA)
A geographic region of significant environmental or cultural significance or population
density that if, a pipeline rupture or burst were to occur, would incur substantial cost in
terms of loss of life, environmental or financial consequence to a pipeline operator and
those living in proximity of the pipeline.
I
ILI
Acronym for Inline Inspection. A procedure by which a mechanical devices equipped
with sensors and/or cleaning devices is pushed, under pressure, through the pipeline for
the purposes of detecting anomalies in the structure or ovality of the pipe or for removing
sludge and other undesirable elements from inside the pipeline.
Index
A data structure, usually an array, used to speed the search for records in a database or for
spatial features in geographic datasets. In general, unique identifiers stored in a key field
point to records or files holding more detailed information.
Inheritance
An term or convention used by object-oriented modelers describing the ‘passing’ of
attributes, interfaces, and relationships from a parent to child object.
ESRI Technical Paper
163
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
IMP
Acronym for Integrity Mangement Programs. A formalized set of operating procedures
for planning the remediation and mitigation of threats posed to a pipeline from corrosion,
third party damage, current operating conditions, etc.
The IMP is designed to guide a pipeline operator in performing the required functions to
maintain the structural and operational integrity of a pipeline system.
Interoperability
See Also: OGC
The capability of components or systems to exchange data with other components or
systems, or to perform in multiple environments. In GIS, interoperability is required for a
GIS user using software from one vendor to study data compiled with GIS software from
a different provider.
Interpolation
In the context of linear referencing, the calculation of measure values for a route between
two known measure values.
J
Joining
See Also: relate
Appending the fields of one table to those of another through an attribute or field
common to both tables. A join is usually used to attach more attributes to the attribute
table of a geographic layer.
Connecting two or more features from different sets of data so that they become a single
feature.
Junction
For network data models in a geodatabase, a point at which two or more edges meet.
In a coverage, a node joining two or more arcs.
May 2007
164
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
K
Keyword
See Also: index
A significant word from a document that is used to index or search content.
A word searched for in a search command. Keywords are searched for in any order.
When defining metadata, users can enter theme and place keywords.
Known point
A surveyed point that has an established x,y coordinate value. Known points are used in
survey operations to extend survey computations into a project area.
L
Layer
1. The visual representation of a geographic dataset in any digital map environment.
Conceptually, a layer is a slice or stratum of the geographic reality in a particular
area, and is more or less equivalent to a legend item on a paper map. On a road map,
for example, roads, national parks, political boundaries and rivers are examples of
different layers.
2. In ArcGIS, a reference to a data source, such as a coverage, geodatabase feature class,
raster, and so on, that defines how the data should be symbolized on a map. Layers
can also define additional properties, such as which features from the data source are
included. Layers can be stored in map documents (.mxd) or saved individually as
layer files (.lyr). Layers are conceptually similar to themes in ArcView 3.x.
3. A stand-alone feature class in a geodatabase managed with SDE 3 or ArcSDE.
Line
See Also: line feature, polyline
On a map, a shape defined by a connected series of unique x,y coordinate pairs. A line
may be straight or curved.
Line event
In linear referencing, a feature that describes a portion of a route using a from- and tomeasure value. Examples include pavement quality, salmon spawning grounds, bus fares,
pipe widths, and traffic volumes.
ESRI Technical Paper
165
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Line feature
See Also: line, polyline feature
A map feature that has length but not area at a given scale, such as a river on a world map
or a street on a city map.
Line loop
An object class designed to store information describing a line in the pipeline system.
A construct that represents a single pipeline from the source (the gathering fields or
refineries) to the terminus of the line (connection at town border stations to distribution
centers or refineries). A line loop might be a mainline transmission pipe or a branch from
a gathering field. Often several line loops run parallel to each other. A line loop may have
gaps along the entire pipeline as pipes are often shared between several lines. In almost
all cases a line loop is an aggregation of one or more station series features but can also
be the aggregation of one or more line loops.
Logical LineLoop – A LineLoop object that has no related StationSeries features but
may have one or more related child LineLoop objects.
Physical LineLoop – A parent LineLoop object that has one or more related child
StationSeries features.
Linear interpolation
The estimation of an unknown value using the linear distance between known values.
Linear referencing
See Also: dynamic segmentation
A method for storing geographic data by using a relative position along an already
existing linear feature; the ability to uniquely identify positions along lines without
explicit x,y coordinates. Location is given in terms of a known linear feature and a
position, or measure, along it. Linear referencing is an intuitive way to associate
multiple sets of attributes to portions of linear features.
Linear unit
See Also: Unit of Measure
The unit of measurement on a plane or a projected coordinate system, often meters or
feet.
May 2007
166
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
M
Many-to-many relationship
An association between two linked or joined tables in which one record in the first table
may correspond to many records in the second table, and vice versa.
Many-to-one relationship
See Also: joining, many-to-many relationship, one-to-many relationship, one-to-one
relationship
An association between two linked or joined tables in which many records in the first
table may correspond to a single record in the second table.
Metadata
Information that describes the semantic behavior, schema and data content of an APDM
geodatabase.
Two types of metadata constructs are implemented in the APDM:
Class-level metadata – stores additional behavioral information for an object
or feature class that applies to all objects in the class, or to all objects within a
subtype of the class.
Feature-level metadata – stores information that defines the behavior of
individual features within a feature class. Feature-level metadata is used to
define the behavior of online events and ControlPoint features during
centerline editing operations that change the shape of the centerline or
alter station values.
Model
1. An abstraction and representation of reality used to represent objects, processes,
or events.
2. A set of clearly defined analytical procedures used to derive new information
from input data.
3. A set of rules and procedures for representing a phenomenon or predicting an
outcome. In geoprocessing, a model consists of one process or a sequence of
processes connected together, and is created in Model Builder.
4. A data representation of reality, such as the vector data model.
ESRI Technical Paper
167
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Monotonic
Increasing or decreasing values in a single direction without breaks, gaps, or repetitions
in values.
M-value
Vertex attributes that are stored with x,y point coordinates in ESRI's Geometry Engine.
Every type of geometry (point, polyline, polygon, and so on) can have attributes for every
vertex.
In linear referencing, measure values that may be added to linear features to perform
dynamic segmentation. In linear referencing, m-values are used on vertices to imply a
measurement along a linear feature. The m-value allows a location along a line to be
found.
N
Nonspatial data
See Also: attribute data
Data without inherently spatial qualities, such as attributes.
NPMS
Acronym for the National Pipeline Mapping System. The U.S. Government requires that
all pipelines report the location and other attributes describing the pipeline using the
standard NPMS reporting format.
O
Object
In GIS, a digital representation of a spatial or nonspatial entity. Objects usually belong to
a class of objects with common attribute values and behaviors.
In object-oriented programming, an instance of the data structure and behavior defined by
a class.
Object class
In a geodatabase, a collection of nonspatial data of the same type or class. While spatial
objects (features) are stored in feature classes in a geodatabase, nonspatial objects are
stored in object classes.
May 2007
168
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
A table in a geodatabase used to store a collection of objects with similar attributes and
behavior. Objects with no location information are stored as rows or records in object
classes. Spatial objects, or features, are stored as rows in feature classes, which are a
specialized type of object class in which objects have an extra attribute to define their
geographic location.
Offline Linear Features
Offline linear features are stored in a polyline feature class. It is possible for an offline
linear feature to intersect the centerline in multiple places and thus have one or more
online point location features as referenced locations. Offline linear features must have
the following attribute:
•
EventID (string, 38) − A globally unique identifier for the feature.
Offline Point Features
Offline Point features are stored in an M Aware (optionally Z Aware) point feature class
that is located off the centerline. Offline features may be referenced against a location on
the centerline. Offline point features must have the following attribute:
•
EventID (string, 38) − A globally unique identifier for the feature.
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.
ESRI Technical Paper
169
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
One-to-many relationship
See Also: joining, many-to-many relationship, many-to-one relationship, one-to-one
relationship
An association between two linked or joined tables in which one record in the first table
corresponds to many records in the second table.
One-to-one relationship
See Also: joining, many-to-many relationship, many-to-one relationship, one-to-many
relationship
An association between two linked or joined tables in which one record in the first table
corresponds to only one record in the second table.
Online Linear Features
Online linear features are stored in an M Aware (optionally Z Aware) polyline feature
class that is geometrically constrained and coincident with the centerline. Online linear
features are located by linear referencing using a Route-ID and two Measure fields.
Online linear features can exist as concrete features located along the centerline or
as online locations for offline polyline and offline polygon features. Online Linear
feature classes must have the following attributes:
•
StationSeriesEventID (sting, 38) − A foreign key to a station series feature
(route) along which the online linear feature is located.
•
BeginStation (double 15, 2) − A station value (measure) along a station series
used to position and locate the start of the linear feature.
•
EndStation ( double 15, 2) − A station value (measure) along a station series
used to position and locate the end of the linear feature.
•
EventID (string, 38) − A globally unique identifier for the 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:
•
May 2007
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.
170
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
•
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.
•
EventID (string, 38) − A globally unique identifier for the feature.
•
SymbolRotation (double 15, 2) − A rotation angle from 0-360 for a point
symbol (uses gnAngle domain).
op
Prefix applied to domains describing feature classes describing pipeline operations.
OPS
Acronym for the Office of Pipeline Safety. The OPS is the regulatory branch of the
Pipeline and Hazardous Materials Safety Administation (PHMSA) under the auspices of
the U.S. Department of Transportation (DOT) and Federal Energy Regulatory
Commission (FERC).
P
Personal geodatabase
A geodatabase that stores data in a single-user relational database management system. A
personal geodatabase can be read simultaneously by several users, but only one user at a
time can write data into it.
Point
See Also: Point Feature
A geometric element defined by a pair of x,y coordinates.
ESRI Technical Paper
171
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Point event
In linear referencing, a feature that occurs at a precise point location along a route; it uses
a single measure value. Examples include accident locations along highways, signals
along rail lines, bus stops along bus routes, and pumping stations along pipelines.
Point feature
See Also: Point
A map feature that has neither length nor area at a given scale, such as a city on a world
map or a building on a city map.
Polygon
See Also: Polygon Feature
On a map, a closed shape defined by a connected sequence of x,y coordinate pairs, where
the first and last coordinate pair are the same and all other pairs are unique.
Polygon feature
See Also: Attribute Table, Polygon
A map feature that bounds an area at a given scale, such as a country on a world map or a
district on a city map.
Polyline
See Also: polyline feature
In ArcGIS software, a shape defined by one or more paths, where a path is a series of
connected segments. If a polyline has more than one path (a multipart polyline) the paths
may either branch or be discontinuous.
Polyline feature
See Also: attribute table, polyline
In ArcGIS software, a digital map feature that represents a place or thing that has length
but not area at a given scale. A polyline feature may have one or more parts. For
example, a stream is typically a polyline feature with one part. If the stream goes
underground and later reemerges, it might be represented as a multipart feature with
discontinuous parts. If the stream diverges around an island and then rejoins itself, it
might be represented as a multipart feature with branching parts. A multipart polyline
feature is associated with a single record in an attribute table.
May 2007
172
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Primary key
A column or set of columns in a database that uniquely identifies each record. A primary
key allows no duplicate values and cannot be null.
Q
Query
A request to select features or records from a database. A query is often written as a
statement or logical expression.
R
Range domain
See Also: Attribute domain, Coded value domain, Domain
A type of attribute domain that defines the range of permissible values for a numeric
attribute. For example, the permissible range of values for a pipe diameter could be
between one and 32 inches.
Raster
See Also: Vector
A spatial data model that defines space as an array of equally sized cells arranged in rows
and columns. Each cell contains an attribute value and location coordinates. Unlike a
vector structure, which stores coordinates explicitly, raster coordinates are contained in
the ordering of the matrix. Groups of cells that share the same value represent the same
type of geographic feature.
RDBMS
Acronym for relational database management system. A type of database in which the
data is organized across several tables. Tables are associated with each other through
common fields. Data items can be recombined from different files. In contrast to other
database structures, an RDBMS requires few assumptions about how data is related or
how it will be extracted from the database.
Oralce and MS SQLServer are two vendor specific RDBMS that both support
implementation of an ESRI Geodatabase.
ESRI Technical Paper
173
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Reference mode
Reference modes represent different methods of recording station values and how these
values are applied at the LineLoop level.
Relate
See Also: joining
An operation that establishes a temporary connection between records in two tables using
an item common to both.
Relationship class
An item in the geodatabase that stores information about a relationship. A relationship
class is visible as an item in the ArcCatalog tree or contents view.
Relational database
A data structure in which collections of tables are logically associated with each other by
shared fields.
Re-Route
The procedure where the current position of a portion of the pipeline is altered by either:
•
adding length to the beginning or end of the pipeline,
•
deleting length from the pipeline
•
abandoned or removing a portion of the pipeline and replacing that segment with
another segment of pipe at the same or a slightly difference location.
Right of Way (ROW)
A legal agreement between a pipeline operator and a land owner granting the operator
access and useage of a portion of land along and to either side of a pipeline that intersects
the owned property.
ROI
Acronym for Return on Investment. A financial term used to measure the potential return
(in monetary value) on an investment.
May 2007
174
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Route event
In linear referencing, linear, continuous or point features occurring along a base route
system.
S
Segment
In ArcGIS software, a geometric element from which paths are constructed. A segment
consists of a start point, an endpoint, and a function that describes a straight line or curve
between these two points. Curves may be circular arcs, elliptical arcs, or Bézier curves.
Shape
The characteristic appearance or visible form of a geographic object as represented on a
map. A GIS uses variations of three basic shapes to represent geographic objects: points,
lines, and polygons.
Shapefile
A vector data storage format for storing the location, shape, and attributes of geographic
features. A shapefile is stored in a set of related files and contains one feature class.
Single-user geodatabase
A personal geodatabase that can handle a single editor and multiple readers.
Spatial data
See Also: nonspatial data, temporal data
Information about the locations and shapes of geographic features and the relationships
between them, usually stored as coordinates and topology.
Any data that can be mapped.
Spatial database
A collection of spatial data and its related descriptive data, organized for efficient storage
and retrieval.
ESRI Technical Paper
175
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Spatial reference
The coordinate system used to store a spatial dataset. For feature classes and feature
datasets within a geodatabase, the spatial reference also includes the spatial domain.
Stationing
1. In the pipeline industry, another name for linear referencing. Stationing is the
measured distance along the station series.
2. Stationing allows any point along a pipeline to be uniquely identified.
Station series
A linear path representing a portion of the centerline of a pipeline, or the route that the
pipeline follows across the surface of the earth.
Station Value
The measure value assigned to a point location.
Subsystem
A subsystem is an area on or along the pipeline system. Typically subsystems are
represented by polygonal features such as states, counties, operating areas, inspection
zones, site boundaries etc. A subsystem could also be represented by one or more linear
‘reaches’ or ‘events’ along a pipeline system.
Logical SubSystem – A SubSystem object that has no related SubSystemRange
features but may have one or more related child SubSystem objects.
Physical SubSystem – A parent SubSystem object that has one or more related child
SubSystemRange features.
Subtype
In geodatabases, a subset of features in a feature class or objects in a table that share the
same attributes. For example, the streets in a streets feature class could be categorized
into three subtypes: local streets, collector streets, and arterial streets. Creating subtypes
can be more efficient than creating many feature classes or tables in a geodatabase. For
example, a geodatabase with a dozen feature classes that have subtypes will perform
better than a geodatabase with a hundred feature classes. Subtypes also make editing data
faster and more accurate because default attribute values and domains can be set up. For
May 2007
176
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
example, a local street subtype could be created and defined so that whenever this type of
street is added to the feature class, its speed limit attribute is automatically set to 35 miles
per hour.
T
Table
A set of data elements arranged in rows and columns. Each row represents a single record
for an entity, such as a feature. Each column represents a field of the record. Rows and
columns intersect to form cells, which contain a specific value for one field in a record.
Tabular data
See Also: Table
Descriptive information, usually alphanumeric, that is stored in rows and columns in a
database and can be linked to spatial data.
Temporal data
See Also: Spatial data
Time- and date-specific information for geographic locations that enables tracking of
real-time, future, or past observations, which can be discrete, such as lightning strikes;
moving, such as airplanes; or static, such as traffic sensors.
Temporal event
See Also: event
In ArcGIS Tracking Analyst, a type of event used to describe observations through time
of particular objects or groups of objects.
Text attribute table
See Also: Attribute table
A table containing text attributes, such as color, font, size, location, and placement angle,
for an annotation subclass in a coverage. In addition to user-defined attributes, the text
attribute table contains a sequence number and text feature identifier.
Topology
See Also: Arc-node topology
ESRI Technical Paper
177
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
In geodatabases, the arrangement that constrains how point, line, and polygon features
share geometry. For example, street centerlines and census blocks share geometry, and
adjacent soil polygons share geometry. Topology defines and enforces data integrity rules
(for example, there should be no gaps between polygons). It supports topological
relationship queries and navigation (for example, navigating feature adjacency or
connectivity), supports sophisticated editing tools, and allows feature construction from
unstructured geometry (for example, constructing polygons from lines).
The branch of geometry that deals with the properties of a figure that remains unchanged
even when the figure is bent, stretched, or otherwise distorted.
U
Unit of measure
See Also: Linear unit
A standard quantity used for measurements such as length, area, and height.
V
Vector
See Also: Raster
A coordinate-based data model that represents geographic features as points, lines, and
polygons. Each point feature is represented as a single coordinate pair, while line and
polygon features are represented as ordered lists of vertices. Attributes are associated
with each feature, as opposed to a raster data model, which associates attributes with
grid cells.
Any quantity that has both magnitude and direction.
Vertex
One of a set of ordered x,y coordinate pairs that defines a line or polygon feature.
W
Wormhole
A database or object-modeling term used to show a relationship to a class using a small
colored oval to represent the class in a logical model diagram as opposed to representing
the class in it’s entirety. Is used in logical model diagrams for simplifying the drawing.
May 2007
178
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
X
X,Y coordinates
A pair of values that represents the distance from an origin (0,0) along two axes, a
horizontal axis (x), and a vertical axis (y). On a map, x,y coordinates are used to represent
features at the location they are found on the earth's spherical surface.
X,Y event
See Also: coordinates, event, event layer, event table, x,y coordinates
A simple coordinate pair that describes the location of a feature, such as a set of latitude
and longitude degrees.
Y
Z
Z-value
The value for a given surface location that represents an attribute other than position. In
an elevation or terrain model, the z-value represents elevation; in other kinds of surface
models, it represents the density or quantity of a particular attribute.
ESRI Technical Paper
179
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Appendix 3 – APDM 3.0 to APDM 4.0 Conversion
Utility Script
In moving from version 3.0 to version 4.0 of the APDM, the following specific naming
changes to various object classes, relationship classes and fields have occurred:
1. All object classes with the naming convention <class name>Activity have been
renamed <class name>Audit.
2. All M-N relationship classes with the naming convention <class
name>ActivityDocument have been renamed <class name>AuditDocument.
3. Within the above relationship classes, foreign key fields with the naming
convention <class name>ActivityEventID have been renamed <class
name>AuditEventID
Within the APDM are a large number of classes that follow these naming conventions.
While it is possible to manually rename object and relationship classes in ArcCatalog,
this activity is extremely tedious and prone to error. Also, unfortunately, ESRI
geodatabase technology does not permit any renaming of fields. To deal with the
relationship classes defined above, it is actually necessary to define new relationship
classes with the desired names, copy information into them from the old relationship
classes, and then remove the old relationship classes. This can only be accomplished via a
utility program.
The following VBA script is designed explicitly to implement the naming changes
described above. The script is fairly generic, and can easily be modified to address other
facets of migrating an APDM version 3.0 geodatabase in place to version 4.0.
Disclaimer
1. PUBLIC DOMAIN
Environmental Systems Research Institute, Inc. (ESRI) expressly states the script is being
placed in the public domain or is "Freeware." The script may be freely used and
redistributed, is provided "AS-IS" without warranty of any kind, and there is no technical
support provided.
2. LICENSE AGREEMENT
Reservation of Ownership and Grant of Rights This is a license agreement
(Agreement) and not an agreement for sale. ESRI retains exclusive title and ownership of
the copy of the VBScript script (referred to hereinafter as "Script") licensed under this
Agreement and grants you (hereinafter referred to as "User") a personal, nonexclusive,
nontransferable, worldwide, royalty-free license to use, copy, edit, modify, merge,
incorporate, and/or prepare derivative work(s) of the Script with any new scripting code
and/or data, and thereafter the copyright license to demonstrate, reproduce, redistribute,
and publicly display the derivative work(s) embedding the Script to User's clients for the
May 2007
180
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
client's own internal use. All rights not specifically granted in this Agreement are
reserved to ESRI. In the event User transfers a copy of the unmodified Script to another
party, User expressly agrees to always include this Agreement file with all copies of the
unmodified Script.
Copyright The Script is owned by ESRI and is protected by United States copyright laws
and applicable international laws, treaties, and/or conventions. The following ESRI
attribution information must be given in comment form in the Script, in an "Help-About"
dialog box, in a supporting digital "Read Me" file, and/or provided in digital form for online documentation, and at the beginning or end acknowledgment page of any hard-copy
documentation:
"Portions of this work include intellectual property of Environmental Systems Research
Institute, Inc. and are used herein with permission. Copyright (C) [Insert year(s)]
Environmental Systems Research Institute, Inc. All rights reserved."
The parties mutually agree that User may make an application for copyright registration
in the derivative work(s) prepared by User based on the preexisting Script so long as User
identifies and discloses all respective ownership rights in preexisting material(s) that
comprise User's derivative work(s) in section 6, Derivative or Compilation on Form TX
and/or any other applicable form(s) of the United States Copyright Office or the
applicable forms in other legal jurisdictions.
Disclaimer of Warranty User expressly acknowledges that the Script is unsupported
scripting code and that no technical support shall be provided to User by ESRI.
THE SCRIPT IS PROVIDED "AS-IS," WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, BY STATUTE OR OTHERWISE, INCLUDING, BUT NOT
LIMITED TO ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE. ESRI DOES NOT WARRANT THAT
THE OPERATION OF THE SCRIPT SHALL BE UNINTERRUPTED OR ERROR
FREE. USER BEARS ALL RISK AS TO THE QUALITY AND PERFORMANCE OF
THE SCRIPT.
Exclusive Remedy and Limitation of Liability The parties expressly agree that ESRI's
liability hereunder for any damages to User, regardless of the form of action, shall not
exceed the total amount paid for the license granted herein.
IN NO EVENT SHALL ESRI BE LIABLE TO USER FOR COSTS OF
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOST
SALES OR BUSINESS EXPENDITURES, INVESTMENTS, OR COMMITMENTS IN
CONNECTION WITH ANY BUSINESS, LOSS OF ANY GOODWILL, OR FOR ANY
INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THIS AGREEMENT OR USE OF THE SCRIPT, HOWEVER CAUSED, ON
ESRI Technical Paper
181
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
ANY THEORY OF LIABILITY, AND WHETHER OR NOT ESRI HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. THESE LIMITATIONS
SHALL APPLY NOTWITHSTANDING ANY FAILURE OF ESSENTIAL PURPOSE
OF ANY LIMITED REMEDY.
Governing Law This license is governed by the laws of the United States of America
and the state laws of California without reference to conflict of laws principles.
Entire Agreement The parties agree that this Agreement constitutes the sole and entire
agreement of the parties as to the matter set forth herein and supersedes any previous
agreements, understandings, and arrangements between the parties relating hereto when
User assents to be bound by these terms and conditions by using the Script.
ConvertAPDM3to4
Option Explicit
Option Compare Text
Public Sub Test_Convert()
'Pass the data source string to the main subroutine. (Must be changed for ArcSDE.)
Run_Convert "C:\EIM\APDM_PDM_041211.mdb"
End Sub
Private Sub Run_Convert(strMDBFile As String)
On Error GoTo ErrorHandler
'Connect to the geodatabase. For ArcSDE, this must be modified.
Dim pWSF As IWorkspaceFactory
Set pWSF = New AccessWorkspaceFactory
Dim pW As IWorkspace
Set pW = pWSF.OpenFromFile(strMDBFile, 0)
Dim pFW As IFeatureWorkspace
Set pFW = pW
'Spin through every geodatabase object and change the word Activity to Audit
wherever the class name ends in Activity.
Dim i As Long, j As Integer
Dim pEnumDS As IEnumDataset
Dim pDS As IDataset
Set pEnumDS = pW.Datasets(esriDTAny)
pEnumDS.Reset
May 2007
182
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Set pDS = pEnumDS.Next
Dim strDS As String
Dim strNewDS As String
'Define classes to exclude. For instance, the ACTIVITY object class will be excluded.
Const EXCLUDE_TABLES = "|ACTIVITY|OTHERTABLE"
Do While Not pDS Is Nothing
strDS = pDS.Name
'Check for the word Activity (as in <class>Activity).
If Right(strDS, Len("Activity")) = "Activity" And InStr(EXCLUDE_TABLES, "|" &
strDS) = 0 Then
'Change Activity to Audit…
strNewDS = Replace(strDS, "Activity", "Audit")
If pDS.CanRename Then
Debug.Print "DETECTED->" & strDS & " RENAMED->" & strNewDS
pDS.Rename strNewDS
Else
Debug.Print "DETECTED->" & strDS & " COULD NOT RENAME!"
End If
End If
Set pDS = pEnumDS.Next
Loop
'Spin through the relationship classes, looking for M-N classes containing a foreign
key field with a name of the form <class>ActivityEventID.
Set pEnumDS = pW.Datasets(esriDTRelationshipClass)
pEnumDS.Reset
Dim pRC As IRelationshipClass
Set pDS = pEnumDS.Next
'Define fields to exclude from processing. (For instance, ActivityEventID will not be
processed.)
Const EXCLUDE_FIELDS = "|ActivityEventID|OtherFields"
ESRI Technical Paper
183
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Dim bCopyRC As Boolean
Do While Not pDS Is Nothing
'Check to see if this is an M-N attributed relationclass.
If TypeOf pDS Is ITable Then
'QI to IRelationshipClass
Set pRC = pDS
Debug.Print "PROCESSING " & pDS.Name
'Open up table
Dim pTable As ITable
Set pTable = pDS
bCopyRC = False
Dim
Dim
Dim
Dim
strNewField As String
strOldField As String
pNewField As IFieldEdit
pField As IField
'Check for the <class>ActivityEventID field.
For i = 0 To pTable.Fields.FieldCount - 1
Set pField = pTable.Fields.Field(i)
strOldField = pField.Name
If InStr(strOldField, "ActivityEventID") > 0 And InStr(EXCLUDE_FIELDS, "|" &
strOldField) = 0 Then
bCopyRC = True
Exit For
End If
Next
'Re-create the M-N relationship class with the desired new name.
If bCopyRC Then
Debug.Print "----CREATING NEW RELATIONSHIPCLASS"
'The new field name
strNewField = Replace(strOldField, "ACTIVITY", "AUDIT")
Dim pOldFieldsEdit As IFields
May 2007
184
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Dim pNewFieldsEdit As IFieldsEdit
Set pNewFieldsEdit = New esrigeodatabase.Fields
Set pOldFieldsEdit = pTable.Fields
For j = 0 To pOldFieldsEdit.FieldCount - 1
If pOldFieldsEdit.Field(j).Name <> strOldField Then
pNewFieldsEdit.AddField pOldFieldsEdit.Field(j)
Else
Set pField = pOldFieldsEdit.Field(j)
'Re-create this field
Set pNewField = New esrigeodatabase.Field
'Copy field parameters to the new field
With pNewField
.Name = strNewField
.AliasName = Replace(pField.AliasName, "ACTIVITY", "AUDIT")
.Type = pField.Type
.Length = pField.Length
.Precision = pField.Precision
End With
pNewFieldsEdit.AddField pNewField
End If
Next
'Rename the relationship class
strDS = Replace(pDS.Name, "Activity", "Audit")
Dim pNewRC As IRelationshipClass
'Add _TMP to the new relationship class name, when the old relationship
class is deleted, the _TMP will be removed.
Set pNewRC = pFW.CreateRelationshipClass(strDS & "_TMP",
pRC.OriginClass, pRC.DestinationClass, pRC.ForwardPathLabel, pRC.BackwardPathLabel,
pRC.Cardinality, pRC.Notification, pRC.IsComposite, pRC.IsAttributed, pNewFieldsEdit, _
Replace(pRC.OriginPrimaryKey, strOldField, strNewField), _
Replace(pRC.DestinationPrimaryKey, strOldField, strNewField), _
Replace(pRC.OriginForeignKey, strOldField, strNewField), _
Replace(pRC.DestinationForeignKey, strOldField, strNewField))
Debug.Print "--------OPK->" & pNewRC.OriginPrimaryKey
Debug.Print "--------OFK->" & pNewRC.OriginForeignKey
Debug.Print "--------DPK->" & pNewRC.DestinationPrimaryKey
ESRI Technical Paper
185
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
Debug.Print "--------DFK->" & pNewRC.DestinationForeignKey
'Dump data across from the old relationship class to the new relationship
class.
Dim pSourceCur As ICursor
Set pSourceCur = pTable.Search(Nothing, True)
Dim pSourceRow As IRow
Set pSourceRow = pSourceCur.NextRow
Dim pNewTable As ITable
Set pNewTable = pNewRC
Dim pNewCur As ICursor
Dim pNewRB As IRowBuffer
Set pNewCur = pNewTable.Insert(True)
Set pNewRB = pNewTable.CreateRowBuffer
If Not pSourceRow Is Nothing Then
Debug.Print "-------COPYING RECORDS"
End If
Dim iPos As Long
iPos = 1
Do While Not pSourceRow Is Nothing
'If there is an error, do not add this row.
On Error Resume Next
For j = 0 To pNewTable.Fields.FieldCount - 1
'Do not copy over non-editable fields (i.e. RID).
If pNewRB.Fields.Field(j).Editable Then
pNewRB.Value(j) = pSourceRow.Value(j)
End If
Next
If Err.Number = 0 Then
pNewCur.InsertRow pNewRB
Else
Debug.Print "----------ERROR COPYING SOURCE OID->" &
pSourceRow.OID & " " & Err.Description
Err.Clear
Resume
End If
May 2007
186
ArcGIS Pipeline Data Model Version 4.0 Abstract and Core Classes
May 2007
'Commit every 500 records.
If iPos Mod 500 = 0 Then
pNewCur.Flush
End If
iPos = iPos + 1
Set pSourceRow = pSourceCur.NextRow
Loop
'Back to original errorHandling.
On Error GoTo ErrorHandler
'Commit remaining.
pNewCur.Flush
'Release objects.
Set pSourceCur = Nothing
Set pNewCur = Nothing
'Delete the old relationship class.
pDS.Delete
'Rename the new relationship class.
Set pDS = pNewRC
pDS.Rename strDS
End If
End If
'Next relationship class.
Set pDS = pEnumDS.Next
Loop
MsgBox "Done"
Exit Sub
ErrorHandler:
MsgBox "ProcessError() " & Erl & "-" & Err.Description
End Sub
ESRI Technical Paper
187