APDM WhitePaper v3

ArcGIS Pipeline Data Model
An ESRI Technical Paper September 2004
ESRI 380 New York St., Redlands, CA 92373-8100, USA TEL 909-793-2853 FAX 909-793-5953 E-MAIL info@esri.com WEB www.esri.com
Copyright 2004 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. 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.
U.S. GOVERNMENT RESTRICTED/LIMITED RIGHTS
J-9137

An ESRI Technical Paper
Contents Page Introduction...........................................................................................1 What Is the APDM?..............................................................................1 APDM and Other Pipeline Data Models ..............................................2 Why Use the APDM? ...........................................................................2 History of the APDM............................................................................3 APDM Steering Committee............................................................4 APDM Technical committee ..........................................................4 Difference Between a Standard and a Template...................................4 Design Rationale...................................................................................4 Core Elements.................................................................................5 Stationing and Station Equations ....................................................6 Distance Based..........................................................................7 Arbitrary (Pseudodistance Based).............................................7 The Centerline (Routes, Measures, and Events).............................8 Hierarchy.........................................................................................8 Coincident Geometry ......................................................................9 Events Versus Features ...................................................................9 APDM Conceptual Model ....................................................................10 Core Elements.................................................................................10 Online Features ...............................................................................10 Offline Features ..............................................................................11 APDM Core Feature Classes and Objects ............................................11 EventID ...........................................................................................11 Station Series ..................................................................................12 Control Points .................................................................................12 LineLoop.........................................................................................13 Conceptual Feature Classes ............................................................13 Pipe Segment ............................................................................13 Online Point Features................................................................13 Online Linear Features..............................................................13 Offline Point Features ...............................................................14
ESRI Technical Paper

J-9137
Offline Linear Features .............................................................14 Offline Polygon Features ..........................................................14 Topology .........................................................................................15 Centerline........................................................................................15 APDM Geodatabase..............................................................................15 Structure..........................................................................................16 Domains ..........................................................................................16 Inheritance.......................................................................................16 Object........................................................................................17 Auditing ....................................................................................17 Feature.......................................................................................18 Point ..........................................................................................18 Fitting........................................................................................18 Online Point ..............................................................................18 Online Polyline .........................................................................19 EventID .....................................................................................19 Object and Feature Classes ...................................................................19 Object Classes.................................................................................19 Activity (Object Class) .............................................................19 <classname>ActivityEvent (Object Class) ...............................20 Address (Object Class) .............................................................20 AltRefMeasure (Object Class)..................................................21 Company (Object Class) ...........................................................21 Contact (Object Class) ..............................................................22 ExternalDocument (Object Class) ............................................22 GeoMetaData (Object Class) ....................................................23 Instrument Parameter (Object Class) ........................................24 LineLoop (Object Class, Core) .................................................24 LineLoopHierarchy (Object Class)...........................................25 OwnerOperatorShip (Object Class) ..........................................25 Reading (Object Class) .............................................................25 SubSystem (Object Class).........................................................26 SubSystemHierarchy (Object Class).........................................26 Feature Classes................................................................................26 AlignmentSheet (Offline Polygon Feature Class) ....................26 Anomaly (Online Point Feature Class) .....................................27 AnomalyCluster (Multipoint Feature Class).............................28 Appurtenance (Online Point Feature Class) .............................29 CPAnode (Offline Point Feature Class)....................................29 CPBond (Offline Point Feature Class)......................................30 CPCable (Offline Polyline Feature Class) ................................30
January 2004
ii

J-9137
CPGroundBed (Offline Point Feature Class)............................30 CPRectifier (Offline Point Feature Class) ................................31 CPTestStation (Offline Point Feature Class) ............................32 CPOnlineLocation (Online Point Feature Class)......................32 Casing (Online Polyline Feature Class)....................................33 Closure (Online Point Feature Class, Fitting)...........................33 Coating (Online Polyline Feature Class) ..................................33 ControlPoint (Point FeatureClass, Core) ..................................34 DocumentPoint (Offline Point Feature Class) ..........................35 Elbow (Online Point Feature Class, Fitting).............................35 ElevationPoint (Online Point Feature Class) ............................36 FieldNote (Offline Point Feature Class) ...................................36 HCAClass (Online Polyline Feature Class)..............................36 HighConsequenceArea (Offline Polygon Feature Class) .........37 InspectionRange (Online PolyLine Feature Class)...................37 Instrument (Online Point Feature Class)...................................38 Leak (Online Point Feature Class)............................................39 LineCrossing (Offline Polyline Feature Class).........................39 LineCrossingEasement Online Polyline Feature Class) ...........40 LineCrossingLocation (Online Point Feature Class) ................40 Marker (Offline Point Feature Class) .......................................40 Meter (Online Point Feature Class, Fitting)..............................41 NonStationedPipe (Offline Polyline Feature Class) .................41 OperatingPressure (Online Polyline Feature Class) .................41 PiggingStructure (Offline Polyline Feature Class) ...................42 PipeJoinMethod (Online Point Feature Class)..........................43 PipeSegment (Online Polyline Feature Class, Core) ................43 PressureTest (Online Polyline Feature Class)...........................45 Reducer (Online Point Feature Class, Fitting)..........................45 RemovedLine (Online Polyline Feature Class) ........................46 RemovedPoint (Online Point Feature Class) ............................46 RightOfWay (Online Polyline Feature Class) ..........................46 RiskAnalysis (Online Polyline Feature Class)..........................47 SiteBoundary (Offline Polygon Feature Class) ........................48 Sleeve (Online Polyline Feature Class) ....................................48 StationSeries (Polyline Feature Class, Core) ............................48 Structure (Offline Point Feature Class).....................................50 StructureLocation (Online Point Feature Class) .......................50 StructureOutline (Offline Polygon Feature Class)....................51 Tap (Online Point Feature Class)..............................................51 Tee (Online Point Feature Class, Fitting) .................................52
iii

J-9137
Valve (Online Point Feature Class, Fitting)..............................53 Vessel (Online Point Feature Class) .........................................54 Implementation Issues ..........................................................................55 Features as Events, Events as Features ...........................................55 Topology and the Geometric Network ...........................................55 EventID, OriginEventID, and GroupEventID ................................56 Developing Applications ................................................................56 Conversion To/From PODS and ISAT ...........................................56 Getting Data Into the Model ...........................................................57 Model Future.........................................................................................57
January 2004
iv
J-9137

Introduction This technical paper explains the ArcGIS Pipeline Data Model (APDM) and is written for those interested in implementing a transmission pipeline geodatabase using ESRI ArcGIS software. The document is written for pipeline company managers, developers, and graphic operators. It provides a detailed description of the objects in the model, how the model is organized, and suggestions of how the model can be implemented within an organization. The document assumes that the reader has a working knowledge of common pipeline terminology, such as stationing, centerline, station series, and control points, and a working knowledge of ESRI linear referencing technology.
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. 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 model and supporting documentation can be downloaded by any member of the ESRI Pipeline Interest Group (PIG) from ESRI's Web site at www.esri.com/pipeline or by the public at ESRI's data model Web site http://support.esri.com/datamodels. The APDM was initially derived from existing published data models and was expanded to meet the needs of gas and liquid transmission pipelines. The APDM was developed by members of the ESRI Pipeline Interest Group steering and technical committees, under the guidance of ESRI. The technical committee includes representatives from pipeline and pipeline vendor companies. The model was designed to include a sampling of standard features typically found in 80 percent of pipeline companies but was tailored to include current hot topic items such as integrity, pipe inspection, high-consequence areas, and risk analysis. In keeping with the spirit of other published ESRI models, the APDM is not designed to be a comprehensive or all encompassing model. Rather, the APDM was designed to be a template from which a pipeline company would start with the core elements of the model and modify the model by adding features or refining existing features. A primary objective of the model was to account for linear referencing of features (stationing). Most transmission pipeline companies refer to the location of features or events that occur along the pipeline system as events occurring along a route (station series) at a certain distance (measure). Stationing was handled in the model using out-of-the-box technology referred to as routes and measures. The APDM was designed as a starting point. It was not the purpose and focus of the APDM technical committee to design a model that was 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. It was the intent of the model to provide a set of core objects and attributes that describe and effectively handle stationing, plus a core set of conceptual objects by which most, if not all, pipeline features could be categorized. The purpose behind providing a core set
What Is the APDM?

J-9137
of features is to provide pipeline 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, and any new features added must fall into one of the conceptual APDM categories: referenced features or nonreferenced features, online features or offline features. Another focus of the APDM was to develop a model that end users could 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 custom data model that meets its business needs.
APDM and Other Pipeline Data Models
The APDM was derived in part from established pipeline data models: Integrated Spatial Analysis Technology (ISAT), Pipeline Open Data Standard (PODS), and Industry Standard Pipeline Data Management (ISPDM). These three models are designed for industry-standard relational database management systems. The APDM is designed to fully exploit ESRI geodatabase technology. The feature classes in the APDM were derived from the tables contained in the ISPDM, ISAT, and PODS models. The salient attributes found in the feature classes of the APDM can be found 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 the standard RDBMS technology. The APDM is an object-relational database management system and, therefore, cannot be accessed using standard Structured Query Language (SQL) or other data access technologies (e.g., Open Database Connectivity [ODBC] or Microsoft ActiveX Data Objects [ADO]). The primary method for customizing and accessing the data stored in the APDM is through the core ESRI ArcGIS technology and its underlying component model, ArcObjects. 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. The prime consideration for using the APDM over a standard relational database model is: Do the benefits of the extended geographic information system (GIS)analytical, cartographic, and editing functionalityoverride the need to integrate the database with other industry-standard applications and data access technologies? Other considerations for using a geodatabase over a relational model include the following: The RDBMS enforces relational data integrity but not spatial data integrity. The geodatabase does enforce referential and spatial data integrity. The RDBMS cannot easily enforce the link between feature geometry and attribute data. Editing operations in the RDBMS world require application logic to drive updates of feature geometry and attributes or attributes then feature geometry. This is a dilemma in the relational model where feature geometries are typically snapshots of the database; each time the database is modified, then the feature geometries are potentially dated 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.
Why Use the APDM?
January 2004

J-9137
The geodatabase (and the APDM) offers less expensive data maintenance of 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. Utilizing a geodatabase for storage of GIS data provides end user access to all the powerful ESRI GIS analytical technology. Other compelling technology included in the geodatabase includes multi-user, long transaction versioned editing; coincident feature editing via topology; geoprocessing; raster-based spatial analysis; state-of-the-art map display/ cartographic production tools; integration to the Web via ArcIMS and ArcServer. disconnected editing via Tablet PC and handheld personal digital assistants (PDAs) running ArcPad; and dynamic annotation. The APDM was 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 model was developed for ESRI enterprise software ArcGIS/ArcSDE technology, which is entirely predicated on the geodatabase. The APDM was developed by a committee of pipeline company operators and vendors. The intellectual property of the APDM is owned by ESRI (the world's leading GIS software vendor) who, in conjunction with pipeline companies and vendors, will continue to manage, evolve, and publish the model on a triannual basis. The APDM will return lower cost, better data creation and management, and better analysis of that data, all important to a highly regulated and important industry such as transmission pipelines.
History of the APDM
The APDM was developed jointly by the ESRI Pipeline Interest Group steering and technical committees. The technical committee was responsible for developing the structure, content, and technological aspects of the model. The steering committee was 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 were derived from the ISAT, PODS, and ISPDM models. Every attempt was made to make the APDM open to data transfer between each model. The steering and technical committees strove to balance the interests of each pipeline model group, the pipeline companies, and the pipeline vendor community. Participation in both committees was divided between operational (client) and vendor communities and ISAT/PODS data model members. Below is a brief chronology of the model's development. March 2002M.J. Harden, starts the initial work on the model. July 2002The 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 2002The initial meeting of interested member groups occurs at ESRI, Redlands, California. October 2002The steering and technical committees are officially formed at the ESRI Electric/Gas Utility User Group Conference (EGUG), Coeur d'Alene, Idaho. December 2002June 2003Monthly technical and steering committee meetings at various member organizations. Development of intellectual property agreement,

J-9137
steering committee charter, technical committee mandate, operational procedures, and APDM content and structure. March 2003The APDM is released for public comment at the ESRI (Petroleum Users Group )PUG meeting, Houston, Texas. July 2003Version 1 of the APDM is officially released at the ESRI International User Conference, San Diego, California. October 2003Model reviewed and version 2 proposed by the APDM technical committee at the ESRI EGUG Conference, Galveston, Texas. Active members of PIG elect the members of the 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. The technical committee will continue to meet regularly at the ESRI International User Conference and the ESRI EGUG and PUG meetings. The following persons and agencies participated in the original steering and technical committees (as of August 2003).
APDM Steering Committee
A ten (10) person committee 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. Greg McCool (greg.mccool@elpaso.com) is the current chairperson of the APDM Steering 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 the anyone interested in furthering the model however only the technical committee members are allowed to vote on changes to the APDM. Peter Veenstra (peter.veenstra@ge.com) is the current chairperson of the APDM Technical Committee. 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 in the model were determined to be 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 was never to create a database standard but rather to create a database template from which custom models could be created and evolved. However, one of the design criteria of the model was to create and delineate core elements of the model that must be maintained in order to preserve a standard for data transfer, application development, and conversion efforts between APDM implementations. The APDM is a geodatabase model that was developed for implementing transmission (gas and liquid) pipelines. This section will outline the design rationale considered at every stage of developing the APDM. These justifications served as guidelines for ensuring the model met the needs of the pipeline industry. Each justification describes
APDM Technical committee
Difference Between a Standard and a Template
Design Rationale
January 2004

J-9137
some of the considerations and background material that were 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 Managing Data Later sections of this document will 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. The APDM is designed to provide a set of core elements that will remain consistent for any APDM implementation. The core elements are designed to ease data transfer between existing pipeline data models and for the development of portable APDM applications by third party vendors. The APDM will provide 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. Features (or tables or objects) will be included in the APDM if they are required by 80 percent of all pipeline companies and are required by United States government regulatory agencies.1 The APDM can be implemented and maintained within a geodatabase without the need for custom application code.
Core Elements
The prime object of the technical committee was to keep a small, well-defined set of core objects with required attributes. These core elements would provide the mechanism for linear referencing to locate events as geometric features or dynamic events. These also would provide a foundation from which other features could be added to the model, or existing features in the model could 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 have been classified into a set of conceptual features that provides 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 included in the model provide examples of the
_______________________________________________________
The APDM technical committee was aware that the APDM would be implemented in international settings. Every attempt was made to avoid an American-centric view of the model. It was the carefully weighed opinion of the committee that transmission pipeline regulations in the United States were some of the most rigorous in the world. Many of the participating agencies in the development of the model have holdings and operations outside of the United States and at each step of the process were consulted to facilitate requirements of the international pipeline community.

J-9137
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 featuresthe rest is up to the end users to pick and choose which elements to include, which to remove, and which to alter to suit their needs. To this end, some users might notice that common pipeline features, such as regulators, compressors, pumps, tanks, extrusions, welds, and the various types of stations (e.g., meter, compressor, town border, and regulator), are not specified in the model. If possible, these features were modeled as domain values or subtypes of more generalized feature classes. The APDM does not restrict or require inclusion of these features. Other than the core elements of the model, it is up to the user to determine what is or is not included in the model. The amount of data that pipeline companies are able to access has exponentially increased within the last decade. In the historical paper world it was conceivable to manage thousands of features. With the advent of faster computers, better integration between disparate systems, and the proliferation of readily available digital data in a wide variety of formats, the potential for the management of millions, if not billions, of features is quite conceivable for many large pipeline companies. By keeping a small core of required elements, the APDM is very open and flexible to integration with larger corporate or enterprise data systems. In this manner, the APDM can be implemented as the front door to the enterprise repository of data by modeling a detailed, rich set of features, or the GIS can be seen as an extension of the entire enterprise by modeling only the positional aspect of features in a data warehouse situation.
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 could be located along a station series representing the location of a feature or the start or end of a 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 a begin point to an endpoint of a station series. Once stationing is assigned to the centerline, the stationing values for known points along the centerline do not change. When the pipeline is first built, the stationing measurements were 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 has been 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 will have 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
January 2004

J-9137
feature is determined using either absolute or relative positioning, then the other positioning values can be determined (provided an underlying centerline of station series features is available). It is important to realize that the ArcGIS Pipeline Data Model puts more emphasis on absolute rather than relative positioning. If the underlying control point and station series network is highly representative of the underlying terrain with accurate positioning in sufficient density, then the calculation of relative position is easily obtained once the station values of known control points are determined and quantified. However, performance of large numbers of event or relative positioned features has performance ramifications. Transmission pipeline stationing systems have been historically collected by field survey. Given the coordinates and arbitrary station value for a known starting point, the surveyor would delineate the centerline of the pipeline using a distance (measured by chains) and angle from the last collected point of the centerline. The angle and distance calculations established from point to point create what is known as the centerline. The known points created from the angle and distance measurements were the control points of the pipeline. Only recently, and in small instances, has absolute positioningwith the advent of the global positioning system (GPS) in conjunction with highly accurate digital rectified orthophotographybecome mainstream for creating the known points of 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. The more common forms of stationing measurement are described below.
Distance Based
Slack Chain (slope, vertical, engineering)The distance between two points is the three-dimensional distance of 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). HorizontalThe two-dimensional surveyed 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 surveyed vector distance). ContinuousStationing 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.

J-9137
Arbitrary (Pseudodistance Based)
Mile PostingPosts or other markers are placed in or on the ground at arbitrary intervals and are used as reference points for locating features. Offset BasedMeasurements are taken as offset values from known points along the centerline (e.g., valve sectionthe feature is located 100 feet downstream from the mainline valve). The centerline of a pipeline system is composed of a station series, which in turn is 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 and a beginning and end station value and belongs to a line loop. Control points are points along the pipeline centerline with known geographic position coordinates and a known station value. When a group of control points is assigned to a specific station series, then 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 route 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 will have 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 represent an interpolated distance from the start of a station series through the known control points (that act as vertices of the station series) to the point where the event occurs. If the event falls along the station series in between two control points (each with a different station value), the position of the event is interpolated along the station series relative to the station values of the bordering control points and the station value of the event. Point events are located on a single route feature. Currently, ESRI linear referencing technology dictates that linear events must also start and end on the same route. Station series features are modeled as M Aware or Z (elevation) Aware polyline features in the APDM. Control points are modeled as M Aware or Z Aware point features in the
The Centerline (Routes, Measures, and Events)
January 2004

J-9137
APDM. Both station series and control points are considered core elements of the APDM.
Hierarchy
Pipeline companies often organize or group features according to a hierarchy. Typically hierarchy is based on where particular station series features are located. A typical hierarchy will place a station series feature belonging to a single line. Each line will belong to a single pipeline system. Many pipeline systems will belong to a pipeline company. Even a simple hierarchy can be broken down into more complex organizational structures such as discharge subsystems, valve sections, branches, and main lines. There is no standard hierarchy structure that pipeline companies adhere to other than some kind of hierarchy present in most pipeline systems. The most ubiquitous form of hierarchy in pipeline systems is the line loop. The APDM accounts for hierarchy by assigning each and every station series to one or more line loops. A line loop is 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 will 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. The APDM does not account for any logical network or 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 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, which are optional objects that can be used to define the hierarchy of a pipeline system.
Coincident Geometry
Another consideration when designing the APDM was the prevalence of coincident point and line features in a transmission pipeline. Any feature that is located by relative position 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, 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 was to mitigate the effects of editing parent features geometry or station (measure) attributes. Relationship classes can be used to maintain the station (measure) relationships between the centerline and dependent child features. Topology is the recommended solution for handling the geometric relationships between coincident geometries from different feature classes. 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 benefit to using geometry is that performance is excellent, the features can be displayed quickly through the Internet via ArcIMS, and the features can
Events Versus Features

J-9137
be edited directly in ArcMap. The dilemma that arises when using geometry is that the feature does not automatically recalculate the feature geometry when the underlying Route-ID and measure values (or begin/end Route-ID and measure values) are updated. The benefit of using events is that whenever the Route-ID and measure values are updated, then the geometry can be quickly refreshed. If an error occurs when the event geometry is being created, then an error message can be appended to the row containing the feature. The dilemma when using events is that each feature does not have permanent geometry and, thus, performance is poor and the features are not available 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. The geometry of the feature is automatically updated when the Route-ID and measure values are altered or the Route-ID and measure values of the features are updated when the geometry is 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.
APDM Conceptual Model Core Elements
All the features in the APDM can be organized into one of three categories: core elements (centerline features and stationing attributes), referenced features (online and offline features), and non-referenced features (land base and support features). Each category of features is described relative to the APDM. Core elements are standard objects or items (e.g., feature classes, object classes, and attributes) within the geodatabase that define the model as APDM-compliant. Core elements comprise the feature/object classes that make the centerline and hierarchy: station series, control point, and line loop. Core elements of the APDM also include the attributes that are required to locate features that are located by linear referencing (stationing): referenced features. The core elements of the model are described later in this document. Online features represent a classification of features that are found as events on the centerline. Online features can be located by the x,y values in the coordinates of the feature geometry, and they can be located by linear referencing (i.e., a position [measure] a certain distance from the begin point of a linear route feature). Online features can only be point or line features. Online features must be geometrically coincident and geometrically constrained to the centerline features (station series) of the pipeline. Features that are geometrically coincident are point or linear features that share the same edge as the station series features that comprise the centerline. Features that are geometrically constrained are linear features that share not only the edge of the centerline but also every intervening vertex between the start and endpoint of the linear feature, which is shared with the station series feature. All online features must have an attribute that identifies a unique route feature (station series) on which the feature will be located. Online point features must also have a measure value (station) along the specified route. Online linear features must have a begin measure attribute (station) and an end measure attribute (station) along the specified route. In some cases, online features may act as "online locations" for offline point, polyline, and polygon features. Online point features acting as an online location must have a station series ID attribute, a measure attribute, an offset distance attribute, and an offset
Online Features
January 2004
10

J-9137
angle attribute. An offline point feature is located by the offset distance and angle from the online point location feature on the centerline. The offset angle is the angle of the line drawn from the point on the centerline to the offline point feature. The offset angle is measured from the centerline, looking toward the increased station values. 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.
Offline Features
Offline features are located by geographic coordinates only. Offline features comprise any feature that is ancillary to the operations and description of the pipeline system and the underlying geography. There are no core offline feature classes. Feature classes in this category are for reference purposes only. However, any offline point, polyline, and/or polygon feature may have one or more online locations, which are stored in an Online feature class. 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 several core elements that must remain consistent for each implementation of the APDM. The core elements are required to maintain the centerline and the framework for applying and using linear referencing along the centerline. The core elements consist of several feature and object classes and attributes for describing centerline and referenced features. Online feature classes (such as online points and online polylines) are conceptual feature classes and contain core attributes that are used to locate these feature classes via linear referencing. 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 names for core elements in the model are suggested names. ArcObjects provides a construct for naming objects in a geodatabase using model names. The APDM accepts object names and model names as the same. The core elements must be named using either an object name or a model name. The following is a description of the objects in the APDM (feature classes, object classes, and attributes) that comprise the core elements of the model.
APDM Core Feature Classes and Objects
EventID
All feature classes and object classes must have an attribute named EventID. This attribute can be a long integer (Int32, precision 9) or a globally unique identifier (GUID) (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 as a GUID format (38 character string) 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. Using an long integer or the Object ID does not ensure global uniqueness or the preservation of a unique ID value assigned to each feature on export and import. 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 could have as easily been replaced by a term such as "Feature ID" or "GeoEntity ID".
11

J-9137
Station Series
Station Series is an M Aware (optionally Z Aware) polyline feature class that describes the centerline. The geometry of a station series feature must be simple. Many of the core ESRI linear referencing tools do not work with multipart geometry. Each station series ostensibly represents a set of monotonically increasing or decreasing stationing without any gaps or breaks in the stationing values. Each station series represents a unique set of station values for a single line loop. The Station Series feature class must have the following attributes: BeginStation (double, 15, 2)The station value assigned to the beginning of the station series. EndStation (double, 15, 2)The station value assigned to the end of the station series. SubTypeCD (long integer, 9)The subtype field. Each subtype denotes a new type of stationing measurement. EventID (string, 38)Globally unique identifier. FromSeriesEventID (string, 38)The foreign key of the Station Series feature that is connected up station of the station series feature. Connectivity between station series features provides the basis of a logical network along the centerline. ToSeriesEventID (string, 38)The foreign key of the Station Series feature that is connected down station of the station series feature. SeriesOrder (long integer, 9)An arbitrary number assigned to a station series for the purposes of sorting queries and creating connectivity between station series features. The Station Series feature class must have at least one subtype. The default subtype for the station series will be considered the primary measurement system (or primary reference mode) for the pipeline system. Each subtype represents a unique method of stationing. The Control Points and Station Series feature classes must share the same subtypes. All other attributes in the Station Series feature class are optional and can be deleted, added, or modified as required.
Control Points
Control Points is an M Aware and Z Aware point feature class that describes the centerline. Each control point represents a known point of stationing including each vertex and the endpoints of the station series feature. Each control point represents a point of inflection (bend), a known point of stationed position, a monument, or a line crossing along the station series. Control points contain the station information for the station series. The Control Points feature class must have the following attributes. StationValue (double, 15, 2)The stationing value assigned to the control point. StationSeriesEventID (string, 38)The foreign key to the Station Series feature class denoting the station series to which the control point belongs. SubTypeCD (long integer, 9)The subtype field. Each subtype denotes a new type of stationing measurement. EventID (long integer, 9)Globally unique identifier.
January 2004
12

J-9137
The Control Points feature class must have at least one subtype. The default subtype for control points will be considered the primary measurement system for the pipeline system. Each subtype represents a unique method of stationing. The Control Points and Station Series feature classes must share the same subtypes. All other attributes in the Control Points feature class are optional and can be deleted, added, or modified as required.
LineLoop
LineLoop is an object class designed to store information describing a line in the pipeline system. One line loop object may have one or more station series features that comprise the line. A single line loop may have one or more line loops that comprise the line. The LineLoop object class must have the EventID attribute (string, 38), which uniquely identifies the line loop within the geodatabase. All other attributes in the LineLoop object class are optional and can be deleted, added, or modified as required. Pipe Segment is the only feature class (other than Station Series and Control Points) that is considered core to the APDM. The features in the Pipe Segment feature class are M Aware online polyline features. Pipe segment features are geometrically constrained and coincident with the centerline. Pipe segments are referenced online polyline features. The Pipe Segment feature class is included in the APDM since it is the most ubiquitous feature in transmission pipelines, and many other features (e.g., coating, pressure test, inspection range) are derived from the presence of a pipe segment. When a pipe segment geometry is altered, the alteration affects many other features. Most colinear features in the model are dependent on the Pipe Segment feature class. The conceptual feature class descriptions are provided as templates. Any referenced feature class that is located on or along the pipeline by means of linear referencing (stationing) falls into one of the conceptual feature class types. The conceptual feature classes provide a listing of the required attributes for each type of referenced feature class. Almost any referenced feature class in a pipeline system will belong to one of these conceptual classes. 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 Route-ID and a Measure field. Online point features can be used to model concrete features that occur along the centerline or as online locations for offline point or offline polyline features. Online Point feature classes must have the following attributes: BeginOffsetDistance (double, 15,2)(optional) The distance of the point feature from a point referenced on the centerline. Only used if the online point feature is acting as an online location for an offline point or offline linear feature. BeginOffsetAngle (double, 15,2)The angle of the vector from the referenced point on the centerline to the offline point. The angle is measured from the upstream vector of the centerline. Only used if the online point feature is acting as an online location for an offline point or offline linear feature. BeginStation (double, 15, 2)A station value (measure) along a station series used to position and locate the point feature.
Pipe Segment
Conceptual Feature Classes
Online Point Features
13

J-9137
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 0360 for a point symbol (uses gnAngle domain). All other attributes in the Online Point conceptual feature class are optional and can be deleted, added, or modified as required.
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: BeginStation (double, 15,2)A station value (measure) along a station series used to position and locate the start of the linear feature. StationSeriesEventID (string, 38)A foreign key to a station series feature (route) along which the starting and ending point of the online linear feature is located. 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. All other attributes in the Online Linear conceptual feature class are optional and can be deleted, added, or modified as required.
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 feature classes must have the following attribute: EventID (string, 38)A globally unique identifier for the feature. why are there so many spaces here?All other attributes in the Offline Point conceptual feature class are optional and can be deleted, added, or modified as required.
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. Online linear features must have the following attribute: EventID (string, 38)A globally unique identifier for the feature. All other attributes in the Online Linear conceptual feature class are optional and can be deleted, added, or modified as required.
January 2004
14

J-9137
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 linear feature as an online location for an offline polygon where the linear feature represents the intersection and overlap of the centerline by the polygon. The APDM is designed to incorporate topology rather than the geometric network as a mechanism to ensure data quality and for maintaining 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 data set. The centerline feature classesControl Points and Station Seriesare the core of the topology. Therefore, all referencing feature classes must participate in the topology as well. The APDM stores all feature classes in the model in the Transmission feature data set. This section outlines some of the rules or assumptions about the APDM centerline features. Control points represent the vertices of station series linear features. 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 of subtypes other than the default subtype only need control points at the beginning and end of the station series features. Station series are M Aware simplified 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 different StationSeriesEventID.
Topology
Centerline
15

J-9137
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. It is assumed, however, 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.
APDM Geodatabase Structure
The following subsections describe the content of the APDM including descriptions of structure, domains, inheritance, abstract classes, object classes, and feature classes. The APDM contains one feature data set 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 will participate in the topology must be stored in the same feature data set. At present, all core and suggested feature classes are located in the Transmission feature data set. The domains that are provided with the model are designed to contain common values found in most pipeline systems. The purpose of these domains is to provide common values that are representative of the attributes they are populating. The provided domain values are not an attempt to provide a comprehensive or universal listing of values. The domain names in the model are prefaced with a two-letter designation that denotes the organizational category to which the domain belongs: gn (genericdomains that could be applied to object classes and many different feature classes across the model), cp (cathodic protection domains), op (domains applied to feature classes pertaining to pipeline operations), en (domains applied to feature classes pertaining to feature classes modeling encroachments to the pipeline), fc (domains applied to facility feature classes), cl (domains applied to centerline feature and object classes), and in (domains applied to inspection feature classes).
Domains
Inheritance
The APDM is depicted in a Universal Modeling Language (UML) diagram contained in a Visio 2002 drawing file. UML provides a mechanism for modeling the objects, classes, relationships, domains, and subtypes of a geodatabase in a diagram. The UML diagrams containing the depiction of the APDM are called static structure diagrams. Static structure diagrams are particularly useful for documenting the relationships between various objects in the geodatabase, especially the concept of inheritance. Inheritance is defined in object-oriented terminology as "the facility by which child objects may use a method or property of a parent object." In other terms, children objects inherit the behavior and attributes of their parent objects. Parent classes are often referred to as abstract classes, particularly in static structure diagrams specifically built for ESRI geodatabases. The purpose of inheritance is to define some sort of behavior (a method) or property (an attribute) once at a generalized high level and have more specialized versions of the parent inherit the methods and attributes and add to them as required. Depicting ESRI geodatabases in static structure UML diagrams relies heavily on inheritance to pass attributes from parents to children objects; the APDM is no exception to this.
January 2004
16

J-9137
There is one aspect of inheritance with respect to the APDM that requires explanation. The conceptual core elements described in previous sections rely on inheritance, but the conceptual diagrams and object descriptions will differ somewhat from the way those objects are depicted in the UML diagrams. This incongruity is a limitation of UML and the inherent nature of relationships within the geodatabase. The prime example of this behavior is the attribute EventID, which should be located in the abstract class Auditing in the UML model. However, since EventID is used for relationships between object and feature classes, it must be present as an attribute of the actual class rather than being inherited from an abstract class, or an error will occur in the UML model. In the conceptual and logical diagrams of the APDM, the attribute EventID will appear as part of the parental abstract classes. In the static structure UML diagram that is used to generate the geodatabase schema, EventID will be located in the bottom-most child feature and object classes. This point is only being made to alleviate any confusion that might be present when viewing discrepancies between the conceptual/logical diagrams of the model and the UML static structure diagram of the model. The diagram below describes the inheritance hierarchy in the APDM.
Object Object Object Object Object FeatureAuditing Feature FeatureAuditing Feature FeatureAuditing Feature FeatureAuditing Feature Auditing Object Class Point Fitting Online Point Feature Class Polyline Online Polyline Feature Class Point Online Point Feature Class (Offline) Feature Class
Object
The Object class is the highest object in the hierarchy of inheritance. A standard ESRI object provides an ObjectID (OID, long integer attribute). ObjectID is the internal, ArcSDE software-assigned unique identifier/primary key for the feature or object class inheriting from Object. FeatureAuditing and Auditing are APDM abstract classes and are identical. The former is applied to feature classes and the latter to object classes. Neither class appears as physical classes in the generated geodatabase schema. However, all the attributes of these classes are passed on to any child objects underneath them in the inheritance hierarchy. The attributes contained in the auditing classes are described below. CreatedBy (string)User-ID of the operator who created the feature CreatedDate (date)The date/time the feature was created EffectiveFromDate (date)The date/time the feature was in operation in the pipeline EffectiveToDate (date)The date/time the feature was decommissioned from the pipeline GroupEventID (long integer)Used to aggregate or generalize two or more features together OriginEventID (long integer)The EventID of a parent object 2
Auditing
_______________________________________________________
2
The OriginEventID field propogates the EventID of a split parent feature. All child segments of the parent feature can maintain the original EventID of the parent. There is no mechanism or attribute for handling the parent EventID of features that were merged.
17

J-9137
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. LastModified (date)The date/time the feature was last updated ModifiedBy (string)User ID of the operator who last updated the feature Remarks (string)Open field used for comments, remarks, or notes OperationalStatus (domain)Status of the feature (e.g., active, abandoned, proposed)
Feature Point Fitting
Feature is a standard ESRI object that provides the shape (binary, esriGeometryType) attribute. The shape attribute contains the geometry for a feature (e.g., point, line, polygon, annotation). The Point abstract class is an APDM class. The Point abstract class contains the single attribute SymbolRotation (double, 15,2), which is used to store a value from 0360 (the angle rotation of the symbol for a point feature class inheriting this object). The Fitting abstract class is an APDM object and is used to group a set of attributes for manufactured facility features. DateManufactured (date)Date the fitting was manufactured Grade (domain)The grade of material the fitting is rated to (e.g., SMYS 40 KSI) InletConnectionType (domain)The inlet connection type (e.g., weld, thread) InletDiameter (domain)The diameter of the inlet opening InletWallThickness (domain)The wall thickness around the inlet opening InServiceDate (date)The date/time the fitting was put into service Manufacturer (domain)The manufacturer of the fitting Material (domain)The material the fitting is made from (e.g., PVC, steel) PressureRating (domain)The pressure the fitting is rated for Specification (domain)The specification the fitting was machined to (e.g., ANSI, API 5)
Online Point
This APDM object contains the Route-ID and Measure values for locating the feature on the centerline at a stationed position using the default measurement type. StationSeriesEventID (long integer)Foreign key to station series feature this point is located on
January 2004
18

J-9137
BeginStation (double, 15,2)Measure or station value at which the point feature is located along a Station Series feature (or route) SymbolRotation (double, 15,2)A rotation angle from 0360 for a point symbol (uses gnAngle domain). OffsetDistance (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. OffsetAngle (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.
Online Polyline
This APDM object contains the Route-ID and Measure values for locating the end of a linear feature on the centerline. The begin Route-ID and Measure values are inherited from the Online Point class. Inherits from the Online Point and Offline Point classes. EndStation (double, 15,2)Measure or station value at which the linear feature ends on a Station Series feature (or route)
EventID
The EventID attribute is required by all feature classes and abstract classes in the APDM. EventID acts as a globally unique identifier, independent of feature class or object class. Logically, EventID should be inherited from the highest object in the hierarchy but must be located in each individual feature and object class since it is used as a primary key and foreign key in every ESRI relationship class that is used in the APDM. The current implementation of the APDM calls for EventID to store a GUID as a 38 character string. The following subsections describe the core and proposed feature/object classes in the model. The object and feature classes presented in this section comprise both core and suggested elements of the APDM. Core elements are denoted with Core. Suggested elements (object/feature classes) are described normally. Each feature/object class is described by a name, a class description, an APDM class description (Core, Online, Offline, Non-referenced), a geometry descriptive (for feature classes), brief description of what the class represents, a description of why the class was included in the model, a description of the relationships between the class and any other classes in the model, a description of class subtypes, and a description of the attributes describing the class. Any attributes inherited from any of the parent objects are not included in the specific class descriptions listed below.
Object and Feature Classes
Object Classes Activity (Object Class)

The rows in the Activity object class store information pertaining to activities that are 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 <featureclassname>ActivityEvents object class. These relationships model that fact that one activity can have one or more events (of different types) that were affected by or participated in the activity. Activity has a many-to-many relationship with ExternalDocuments, whereas many documents might provide source material to the activity. Activity has a one-to-many relationship with InspectionRange indicating that a
19

J-9137
given activity could occur over many linear areas of the pipeline. The Activity object class also has an attribute named ActivityParentEventID that can be used as a self-relate field to group a set of activities underneath a parent activity. The Activity object class is designed to be implemented in systems in which it is important to track regular pipeline activities and the events that are affected by those activities. ActivityDate (date)The date on which the activity occurred ActivityDescription (string)A description or categorization of the activity. ActivityName (string)A title or description of the activity ActivityParentEventID (long integer)A foreign key self-relate to the activity to establish a hierarchy of activities EventID (string, 38)Globally unique identifier
<classname>Activity Event (Object Class)
The <classname>ActivityEvent object class - provides a table for storing historical comments about a feature including an optional relationship between a feature and an Activity. A <classname>Activity table can be created for any other feature class or object class within the geodatabase. The premise is that a given feature <a> will have one-or-more <a>ActivityEvents such as comments, field notes, and/or activities. The relationship from Activity to <classname>ActivityEvent is a one-to-many relationship and is optional. An optional one-to-many relationship from <classname>ActivityEvent to ExternalDocuments may also exist. <ClassName>EventID (srting, 38)Foreign key to a given feature/object class specified by <classname> ActivityEventID (string, 38)(optional) Foreign key to Activity object class Remarks (string)May contain historical notes, comments, inspection results, and other information that chronologically describes the life of a feature or event.
Address (Object Class)
The Address object class contains information about a specific address. This address information pertains to encroaching structures, company addresses, and individual mailing addresses. The Address object class is related to the Contact and Company object classes using many-to-many relationship classes named ContactAddress and CompanyAddress respectively. The Address object class is also related to the Structure and RightOfWay feature classes via many-to-many relationship classes. The Address object class was designed to maintain a list of commonly required addresses pertaining to geographic and organizational features in the model that might be contacted via surface mailing. Note: The Address object class can be supplanted by a separate customer/contact information system (CIS) database. City (string)City name County (string)County name Country (string)Country name
January 2004
20

J-9137
EventID (string, 38)Globally unique identifier StateProvince (string)State/Province name Street1 (string)Street direction prefix, street number, street name Street2 (string)Street direction suffix, address modifier, apartment/lot number ZipPostalCode (string)ZIP/Postal Code
AltRefMeasure (Object Class)
The AltRefMeasure object class is designed to store stationing information for all measurement systems for Online Point and Online Polyline 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. 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 can be used to store the begin and end station values for the aggregate feature, if desired. In this case, one row in AltRefMeasure is related many features. AltRefMeasure is subtyped in the same fashion as ControlPoint and StationSeries; each subtype denotes a different measurement system. AltRefMeasure is related to each Online Point and Online Polyline feature class via a many-to-many relationship class. AltRefMeasure inherits from the Audit abstract class and contains the following additional attributes: EventID (string, 38)Globally unique identifier. StationSeriesEventID (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. 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. SubTypeCD (long integer, 3)The subtype field. Each subtype denotes a different type of stationing measurement. TotalLength (double, 15, 2)The length (in measurement system units) of an Online Polyline feature. For split Online Polyline features, the aggregate length.
Company (Object Class)
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 many-to-many
21

J-9137
relationship classes with the Address and Contact object classes. These relationships reflect that many people work for many companies, and many companies can have many addresses. The Company object class also has a many-to-many relationship with the LineCrossing feature class reflecting ownership of the line. The Company object class has a one-to-many relationship with the OwnerOperatorShip object class reflecting the percentage ownership of the actual line loops of a pipeline system. Note: The Company Object Class can be supplanted by a separate customer/CIS database. CompanyLabel (string)Additional label, acronym, or designation used for the company CompanyName (string)Company name CompanyType (string)Describes the services the company provides (pipeline, contractors, etc.) EventID (string, 38)Globally unique identifier
Contact (Object Class)
The Contact object class contains the contact information for communicating with any person who has contact with or works for a pipeline company and its contractors. Examples of contacts include right-of-way property owners, structure owners, cathodic protection inspectors, emergency contacts, contractors, and company employees (managers, field crews, GIS operators, etc.). The Contact object class has many-to-many relationships with the Reading and Company object classes and with the InspectionRange, LineCrossing, OperatingPressure and RightOfWay, and Structure feature classes. These relationships model the person conducting a reading at a facility feature, inspection, or pressure test. The relationships between Contact and LineCrossing, RightOfWay, and Structure reflect ownership or primary contact information. Note: The Company object class can be supplanted by a separate customer/CIS database. CompanyEventID (long integer)Foreign key relationship to the company the contact works for ContactType (domain)Brief job description/organizational position of contact person Email (string)E-mail address EventID (string, 38)Globally unique identifier Fax (string)Fax number FirstName (string)First name LastName (string)Last name Mobile (string)Mobile/Cell phone number
January 2004
22

J-9137
Pager (string)Pager phone number Phone (string)Phone number
ExternalDocument (Object Class)
The ExternalDocument object class stores information describing the location and content of a file object stored on an external disk drive. The purpose of the ExternalDocument object class is to link features and events with external documentation using a similar method as the ArcMap Hyperlink tool but storing the information within the underlying database table so that external applications might be able to access the information. Using this design, multiple documents can be related to multiple features. The ExternalDocument object class has a one-to-many relationship with the GeoMetaData object class, which models the fact that external documents contain metadata pertaining to the origin/provenance of features described in the GeoMetaData object class. The ExternalDocument object class has a many-to-many relationship with the DocumentPoint feature class, allowing one point feature to display one or more documents that might describe additional point features or other locations. (See DocumentPoint feature class description.) ExternalDocument has a many-to-many relationship with Activity indicating that many documents provide information about many specific activities. The same kind of relationship exists between ExternalDocument and <classname>ActivityEvents object classes. DocumentType (domain)Describes type of external document (e.g., CAD drawing, document, map) EventID (string, 38)Globally unique identifier FilePath (string)UNC or mapped drive path to directory containing file FileName (string)Name of file including extension GeoMetaDataEventID (string, 38)Foreign key relationship describing origin of metadata
GeoMetaData (Object Class)
The GeoMetaData object class describes the geographic provenance of point features in the model, namely ControlPoint and FieldNote whose geographic coordinates are absolute and known. The GeoMetaData allows the database to store highly accurate coordinate information derived from the field for points whose current position has been degraded to suit a projection/precision limitation or has been moved to conflate the current feature to an existing background or control layer (e.g., land base or orthophotography). The GeoMetaData object class is used to maintain a historic tie to the original geographic location of these features in the event that this information is required for more accurate or detailed analysis. The GeoMetaData object class has relationships to the ControlPoint and FieldNote feature classes. These relationships model the need to store original data collected in the event that a feature is later conflated to another position. A relationship is also created with ExternalDocument to record the provenance of the original location information. DateCollected (date)The date the original or previous point location was recorded ESRIProjectionID (string)The ESRI Projection String Identifier the original coordinates were collected in
23

J-9137
EventID (string, 38)Globally unique identifier OriginalX (double, 15,2)The original x location of the point OriginalY (double, 15,2)The original y location of the point OriginalZ (double, 15,2)The original z location of the point PositionSource (domain)The origin or method the original point location was derived from
Instrument Parameter (Object Class)
The InstrumentParameter object class stores information about Instruments. A single instrument feature may have multiple Instrument Parameter records associated with it. The valid parameter types are dependent on the instrument type. For this reason InstrumentParameter is subtyped identically to Instrument; SubTypeCD for InstrumentParameter records must match that of the parent Instrument record. InstrumentParameter maintains a many-to-one composite relationship with Instrument; the longevity of InstrumentParameter records is controlled by the parent Instrument record. InstrumentParameter contains the following attributes: EventID (string, 38)Globally unique identifier InstrumentEventID (string, 38)Foreign key to the parent Instrument feature SubTypeCD (long integer)Defines the instrument subtype (must match the subtype of the parent Instrument feature ParameterType (domain)The parameter type; dependent on the SubTypeCD ParameterValue (string, 80)The value of the parameter (number values are stored as string)
LineLoop (Object Class, Core)
The LineLoop object class is designed to store the information describing pipelines and line loops used to classify pipes into continuous or logical groupings. Most pipeline companies group continuous sections of pipes with common diameters and other attributes that stretch for tens, hundreds, or thousands of miles as a single line or line number. Each station series feature may belong to one or more LineLoop objects. A single line loop may be the parent to one or more children line loops. The LineLoop object class has many-to-many relationships with the StationSeries feature class and the SubSystem and OwnerOperatorShip object classes. The relationship between LineLoop and SubSystem provides a mechanism where parts of LineLoops can be broken down or classified as belonging within different subsystems, areas, or districts. The relationship between LineLoop and OwnerOperatorShip models the percentage owner/operatorship of each LineLoop in the pipeline system. The relationship to StationSeries indicates that many station series can belong to one or more line loops. LineLoop has a one-to-many relationship with LineLoopHierarchy, which models a hierarchy between parent and children LineLoops. A relationship exists between LineLoop and RightOfWay, which models that each RightOfWay linear feature falls on one and only one LineLoop and is used as a source of identification.
January 2004
24

J-9137
The LineLoop object class is a core element of the APDM. EventID (string, 38 long integer)Globally unique identifier LineName (string)Name of the pipeline LineType (domain)Classification of the line type (distribution, transmission, gathering, etc.) Product (domain)Type of product the line typically transports
LineLoopHierarchy (Object Class)
The LineLoopHierarchy object class models relationships between parent and child LineLoops and is used to establish 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 system. The LineLoopHierarchy object class has two many-to-one relationships with the LineLoop object class. EventID (string, 38)Globally unique identifier ParentLineLoopEventID (string, 38)Foreign key to a parent LineLoop object ChildLineLoopEventID (string, 38)Foreign key to a child LineLoop object
OwnerOperatorShip (Object Class)
The OwnerOperatorShip object class is used to define the percentage ownership and/or operatorship for a LineLoop. The OwnerOperatorShip object class has a many-to-many relationship with LineLoop reflecting that many owners/operators can own/operate many LineLoops. The OwnerOperatorShip object class has a many-to-one relationship with the Company object class modeling that one company can have ownership/operatorship of many LineLoops in a pipeline system. CompanyEventID (string, 38 long integer)Foreign key to Company object class EventID (string, 38 long integer)Globally unique identifier LineLoopEventID (string, 38 long integer)Foreign key to LineLoop object class OperatorPercentage (domain)Percentage (0100%) of ownership/operatorship OperatorType (domain)Owner, operator, or lessee
Reading (Object Class)
The Reading object class is used to store generic readings (or measurements) of typically fluctuating information taken at various features found on or along a pipeline system. The Reading object class has many-to-many relationships with the CPGroundBed, CPTestStation, Meter, PipeSegment, and Valve feature classes. These relationships model that at any of these features zero or more readings may be taken over time. The relationships that the cathodic protection feature classes reflect are continuous corrosion control efforts. The readings taken at valves, meters, and pipe segments model flow conditions typically recorded for SCADA systems. The Reading object class has a manyto-many relationship with the Contact object class, which models that many staff members can take/read/measure many readings. The three subtypes of the Reading
25

J-9137
object class provide an example of three typical readings taken at features along a pipeline system: SCADA, Corrosion, and Close Interval Survey. EventID (string, 38)Globally unique identifier ReadingDate (date)The date on which the reading was taken ReadingUnits (domain)The measured units of the reading ReadingValue (double, 15,2)The value of the reading taken SubTypeCD (subtypelong integer)The subtype of the reading
SubSystem (Object Class)
The SubSystem object class is used to categorize, organize, and group LineLoop records into logical groupings. Groups typically reflect organizational boundaries, districts, and operating areas within a pipeline company, the most common of which is the "discharge" subsystem. The SubSystem object class has a many-to-many relationship with LineLoop modeling, and many LineLoop features can belong to many different nonexclusive, often overlapping, systems or districts. The subsystem object class also has two many-to-one relationships with the SubSystemHierarchy object class modeling in that SubSystems can be ordered into hierarchical groupings within the SubSystem object class. It is possible for a relationship to exist between a polygon feature class and the SubSystem object class. Each polygon would represent the spatial extent of a SubSystem. It is also possible to store the actual polygon geometry with the SubSystem record itself converting the SubSystem from an object class to a feature class. EventID (string, 38)Globally unique identifier SubSystemName (string)The name or label that identifies the subsystem
SubSystemHierarchy (Object Class)
The SubSystemHierarchy object class models the hierarchy between different subsystem features in the model. It is common to have organizational groupings or areas contain subareas that, in turn, could contain other subareas. The SubSystemHierarchy object class has two one-to-many relationships with the SubSystem object class modeling parent to child relationships between subsystem objects. EventID (string, 38)Globally unique identifier ParentSubSystemEventID (string, 38)Foreign key to a parent subsystem object ChildSubSystemEventID (string, 38)Foreign key to a child subsystem object
Feature Classes AlignmentSheet (Offline Polygon Feature Class)

The AlignmentSheet feature class stores the polygonal boundary of the printable geographic map portion of an alignment sheet generated along a reach or section of the pipeline system. The attributes of the AlignmentSheet feature class were purposefully designed to store only generic information due to the high variance of alignment sheet
January 2004
26

J-9137
requirements between different pipeline companies. Only the broadest attributes that describe alignment sheets in the most generic terms were included in the model. EventID (string, 38)Globally unique identifier SheetName (string)An organizational name or code that identifies the alignment sheet SheetNumber (string)An organizational name, code, or alias that identifies the alignment sheet SheetType (domain)The type of alignment sheet (e.g., engineering, new construction)
Anomaly (Online Point Feature Class)
The Anomaly feature class is used to describe anomalies in the pipeline system as detected from inline inspection runs of a pigging device. Typical anomalies include corrosion, geometric distortions, and/or material defects such as gouges or dents. The Anomaly feature class participates in a many-to-one relationship with the AnomalyCluster feature class. This relationship models that each anomaly point could be a member of a cluster of like anomalies. The Anomaly feature class is subtyped into four generic types of anomalies: external corrosion, internal corrosion, gouges, and dents. These subtypes are considered to be examples of a range of possible anomaly types. Typically, anomalies are classified according to what kind of inline PIG inspection is conducted on the pipe segments of a pipeline system. The Anomaly feature class has a many-to-many relationship with the InspectionRange feature class. This relationship models the fact that an anomaly location can be determined by many different inspections. AnomalyClusterEventID (string, 38)Foreign key relationship with cluster the anomaly is part of BPRCalculated (double, 15,2)Calculated burst pressure ratio BPRPig (double, 15,2)Burst pressure ratio recorded based on values retrieved by an inline PIG run BPRVariance (double, 15,2)Variance between calculated/PIG burst pressure ratios Depth (double, 15,2)Depth to the anomaly from ground surface EventID (string, 38)Globally unique identifier InspectionRangeEventID (string, 38)Foreign key to the inspection range used to locate the anomaly Length (double, 15,2)The length of the anomaly MaximumDiameter (double, 15,2)The maximum diameter of the pipe segment at the anomaly
27

J-9137
MinimumDiameter (double, 15,2)The minimum diameter of the pipe segment at the anomaly Orientation (domain)The location of the anomaly on the pipe (zero degrees is up) Ovality (domain)Measure of the ovality of the pipe segment at the anomaly RecommendedRemediation (domain)Suggested method of remediation (e.g., repair, replace) RPRCalculated (double, 15,2)Calculated rupture pressure ratio RPRPig (double, 15,2)Rupture pressure ratio recorded by an inline PIG run RPRVariance (double, 15,2)Variance between calculated/PIG rupture pressure ratios SubTypeCD (long integer)The subtype of the reading SymbolRotation (double, 15,2)Value used to determine symbol rotation for each feature Width (double, 15,2)The width of the anomaly
AnomalyCluster (Multipoint Feature Class)
The AnomalyCluster feature class contains mean (average) values for a set of anomaly point features. One feature in the AnomalyCluster feature class represents a set of anomalies stored as a multipoint shape. The purpose behind the AnomalyCluster feature class is to allow analysis of clustered anomalies, of similar types, which were discovered during an inline PIG run. AnomalyType (domain)The type of anomaly cluster (e.g., dents, gouges, corrosion) AveBPRCalculated (double, 15,2)Calculated average anomaly burst pressure ratio AveBPRPig (double, 15,2)Calculated average recorded anomaly burst pressure ratio AveBPRVariance (double, 15,2)Calculated average variance between calculated and recorded anomaly burst pressure ratios AveDepth (double, 15,2)Calculated average anomaly depth AveLength (double, 15,2)Calculated average anomaly length AveMaximumDiameter (double, 15,2)Calculated average anomaly maximum diameter AveMinimumDiameter (double, 15,2)Calculated average anomaly minimum diameter
January 2004
28

J-9137
AveOrientation (double, 15,2)Calculated average anomaly orientation AveOvality (double, 15,2)Calculated average anomaly ovality AveRPRCalculated (double, 15,2)Calculated average calculated anomaly rupture pressure ratio AveRPRPig (double, 15,2)Calculated average recorded anomaly rupture pressure ratio AveRPRVariance (double, 15,2)Calculated average variance between calculated and recorded anomaly burst pressure ratios AveWidth (double, 15,2)Calculated average anomaly width EventID (string, 38)Globally unique identifier
Appurtenance (Online Point Feature Class)
The Appurtenance feature class is used to store ad hoc, nonpressurized point features that are found on and along a pipeline system. The Appurtenance feature class can be used as a catchall for referenced online point features that do not fit into any other APDM feature class and for which a minimum common set of attributes must be recorded. Typical appurtenances include anchor rods, hold-down blocks, river weights, and thrust blocks. AppurtenanceType (domain)The appurtenance type (e.g., anchor rod, river weight) EventID (string, 38)Globally unique identifier InServiceDate (date)The date the appurtenance was placed in service SymbolRotation (double, 15,2)Value used to determine symbol rotation for each feature
CPAnode (Offline Point Feature Class)
The CPAnode feature class stores sacrificial anodes. Anodes receive electrical current and are sacrificed to reduce the probability of pipeline corrosion. The weight of the anode and the size of the pipeline are factors determining how anodes are placed and managed along a pipeline. The CPAnode feature class has a many-to-one relationship with CPGroundBed modeling the fact that one or more anodes are located within a single ground bed. CPAnode feature class has a many-to-many relationship with the CPOnlineLocation feature class showing that each anode may have one or more online locations. AnodeMaterial (domain)The anode material (e.g., graphite, steel pipe) AnodeType (domain)The type of anode used (e.g., magnesium, zinc) AnodeWeight (domain)The weight of the anode CPGroundBedEventID (string, 38)Foreign key relationship with the EventID field of the GroundBed feature class
29

J-9137
EventID (string, 38)Globally unique identifier InServiceDate (date)The date anode was placed into service SymbolRotation (double, 15,2)Value used to determine symbol rotation for each feature
CPBond (Offline Point Feature Class)
The CPBond feature class stores information describing cathodic protection bonds that link one or more bond wires together. Bonds are often placed where nonmetallic fittings or valves join pipe segments together as a means of carrying over (or stopping) electric current from one set of pipes to another. CPBond feature class has a many-to-many relationship with the CPOnlineLocation feature class showing that each bond may have one or more online locations. BondType (domain)The type of bond used (e.g., interference, continuity) CriticalBond (yes/no)Indicates whether or not the bond is critical EventID (string, 38)Globally unique identifier InServiceDate (date)The date the bond was placed into service SymbolRotation (double, 15,2)Value used to determine symbol rotation for each feature
CPCable (Offline Polyline Feature Class)
The CPCable feature class stores information about the cathodic protection cables that carry current to/from different cathodic protection devices and the pipe segments of the pipeline. CPCables provide a physical connection between cathodic protection point features and pipe segment features. CPCable has a many-to-many relationship with CPOnlineLocation indicating that each cable may have one or more online point locations. CableCoating (domain)The coating material used on the cable (e.g., HMWPE, plastic) CableSize (domain)The size of the cable (e.g., 4/0, 2/0, 1, 10) CableType (domain)The type of cable (e.g., solid, stranded) ColorCode (domain)The color code value of the cable (e.g., red, black, green) EventID (string, 38)Globally unique identifier InServiceDate (date)The date the cable was put in service NumberOfCables (domain)The number of cables in the CPCable feature (14)
CPGroundBed (Offline Point Feature Class)
The CPGroundBed feature class is the location on or off the centerline where one or more anodes are placed. Anodes within a ground bed are used to reduce corrosion caused by the flow of direct current from one part of the metal pipeline to another. The CPGroundBed feature class has a one-to-many relationship with the CPAnode feature
January 2004
30

J-9137
class. The CPGroundBed feature class has a many-to-one relationship with the CPRectifier feature class. These relationships model the configuration that typically one CPRectifier feature will have one or more CPGroundBeds, each containing one or more CPAnodes. The CPGroundBed feature also maintains a NumberOfAnodes attribute that may be used in lieu of its association to CPAnode. CPGroundBed also has a one-tomany relationship with the Reading object class in which each CPGroundBed can have one or more readings over time. CPGroundBed feature class has a many-to-many relationship with the CPOnlineLocation feature class showing that each ground bed may have one or more online locations. AnodeSpacing (domain)The measured spacing between each anode in the ground bed BackfillMaterial (domain)The ground material used to backfill the ground bed CPRectifierEventID (string, 38)A foreign key relationship with the EventID of the related CPRectifier EventID (string, 38)Globally unique identifier InServiceDate (date)The date ground bed was placed into service LocationDescription (string)Free form description of the feature location NumberOfAnodes (integer)The total number of anodes placed with ground bed WaterSystem (domain)Indicates if the ground bed has a water system (Yes/No) SymbolRotation (double, 15,2)Value used to determine symbol rotation for each feature
CPRectifier (Offline Point Feature Class)
The CPRectifier feature class stores information about a rectifier. A rectifier is a cathodic protection device that manages the power conversion from AC (alternating current) to DC (direct current) before it is passed on to a pipeline. A CPCable feature can be used to provide connectivity between a rectifier and a pipe segment. The CPRectifier feature class has a one-to-many relationship with the CPGroundBed feature class. This relationship models that zero or more ground beds serve one rectifier. CPRectifier feature class has a many-to-many relationship with the CPOnlineLocation feature class showing that each rectifier may have one or more online locations. EventID (string, 38)Globally unique identifier InServiceDate (date)The date the rectifier was put in service Manufacturer (domain)The rectifier manufacturer Model (domain)The rectifier model type NumberOfNegatives (domain)The number of negatives on the rectifier (14) NumberOfAnodes (integer)The number of anodes serving the rectifier
31

J-9137
OperatingAmpsOut (domain)Actual amperage output by rectifier OperatingVoltsOut (domain)Actual volts output by rectifier PowerSource (domain)Power source for rectifier (e.g., solar, electric) RatedAmpsOut (domain)Maximum rated amperage output by rectifier RatedVoltsOut (domain)Maximum rated volts output by rectifier RectifierStackType (domain)The type of stack used by the rectifier (e.g., silicon bridge, silicon diode) ReplaceByDate (date)The date by which the rectifier must be replaced SymbolRotation (double, 15,2)Value used to determine symbol rotation for each feature
CPTestStation (Offline Point Feature Class)
The CPTestStation feature class stores the information describing a cathodic protection test station. Test stations are located at strategic points along a pipeline and are used to take readings and measurements of the cathodic protection system. The CPTestStation feature class has a one-to-many relationship with the Reading object class. This relationship models that many readings are taken for a particular test station over time. CPTestStation feature class has a many-to-many relationship with the CPOnlineLocation feature class showing that each test station may have one or more online locations. EventID (string, 38)Globally unique identifier InServiceDate (date)Date the test station was put in service TestStationType (domain)The type of test station (e.g., anode, single wire, bonded) SymbolRotation (double, 15,2)Value used to determine symbol rotation for each feature
CPOnlineLocation (Online Point Feature Class)
The CPOnlineLocation feature class stores the online locations for CPAnode, CPBond, CPGroundBed, CPRectifier, and the CPTestStation offline point features. This feature class has a many-to-many relationship from those five feature classes, allowing a common location table for all corrosion features. CPOnlineLocations are calculated for each of the following classes (each represented by a subtype of the class): 1 CPRectifier, 2 CPGroundBed, 3 CPAnode, 4 CPBond, 5 CPTestStation, and 6 CPCable. EventID (string, 38)Globally unique identifier LinkedFeatureEventID (string, 38) The identifier for the feature that the online point location is representing. The class containing the feature is indicated by the SubTypeCD description value for the class. OffsetDistance (double, 15,2)(optional) The distance from the online location to the offline point feature
January 2004
32

J-9137
OffsetAngle (double, 15,2)The angle of the vector from the online location to the offline point feature (angle measured from upstream centerline direction) SubTypeCD (long integer) Indicates the class for which the online point location is calculated for. SymbolRotation (double, 15,2)Value used to determine symbol rotation for each feature
Casing (Online Polyline Feature Class)
The Casing feature class represents a protective structural device surrounding a pipe segment. Casings are used to protect pipelines from the weight, pressure, and vibration caused by traffic on roads, railroads, and other types of line crossings. CasingLength (integer)The length of the casing unit along the pipeline CrossingType (domain)The type of line crossing over the pipeline (e.g., road, railroad) EventID (string, 38)Globally unique identifier Filled (domain)Indicates if the casing is filled with some material (Yes/No) InServiceDate (date)The date the casing was put in service InsulatorType (domain)The type of insulator protecting the casing (e.g., concrete, plastic) OutsideDiameter (domain)The outside diameter of the casing (e.g., 24", 36") SealType (domain)The type of seal used to close the casing (e.g., epoxy, case seal) Shorted (domain)Indicates if the casing is electrically conductive (Yes/No) Vented (domain)Indicates if the casing is vented for air/water circulation/drainage (Yes/No) WallThickness (domain)The wall thickness of the casing
Closure (Online Point Feature Class, Fitting)
The Closure feature class represents the terminus or endpoint of a pipeline. A closure is designed to interrupt (and typically contain) pressurized flow at the end of a pipe segment. Closure inherits attributes from the Fitting Abstract Class. ClosureType (domain)The type of closure (e.g., blind flange, hinged, plug) EventID (string, 38)Globally unique identifier
Coating (Online Polyline Feature Class)
The Coating feature class represents the materials that are spread over a set of pipe segments and fittings to preserve the metal from corrosion and exposure to environmental conditions. Coating can be applied to the internal and/or external surfaces of pipe segments. It is also common for coating features to overlap other coating features. A
33

J-9137
pipe segment can potentially have zero or more internal and zero or more external applications of coating. CoatingCondition (domain)The last known condition of the coating (e.g., disbonded, intact) CoatingLength (double, 15,2)The length of the coating application CoatingLocation (domain)The location of the coating (e.g., internal/external) CoatingMaterial (domain)The type of coating (e.g., epoxy, asphalt, enamel) CoatingMill (domain)The mill that manufactured the coating (e.g., Dupont, BASF) CoatingSource (domain)The place the coating was applied (e.g., mill, in situ) EventID (string, 38)Globally unique identifier InServiceDate (date)The date the coating was put into service InternalCoating (domain)Indicates if coating was applied to inside of pipe (Yes/No)
ControlPoint (Point FeatureClass, Core)
The ControlPoint feature class contains points of known x,y position and known station value (measure) along a pipeline. Each control point feature is also a point representation of a vertex belonging to a station series polyline route feature. The station (or measure) value stored with the control point feature can be used to set the M value of a vertex of a station series feature located at the exact same x,y position as the control point. The ControlPoint feature class is a core element of the APDM. The ControlPoint feature class has a many-to-many relationship with GeoMetaData. This relationship models the provenance of the control point feature. GeoMetaData stores original coordinate information and metadata describing how the control point feature was initially obtained in the field. The ControlPoint feature class has a many-to-one relationship with the StationSeries feature class. This relationship models the fact that each station series feature is composed of two or more control point features and that each control point is a vertex (including endpoints) of the station series feature. The subtypes of the ControlPoint feature class represent different types of linear referencing measurement systems that are used for stationing along a pipeline. The APDM requires that one subtype be the default measurement system for the pipeline. The default measurement system (or subtype) becomes the primary stationing method. The control points and station series that comprise the primary stationing method become, in effect, the centerline for the pipeline system in the APDM. 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. Station series features used to demarcate secondary measurement systems are only required to have control points located at the start and end points of the station series feature. A typical primary measurement system is Horizontal
January 2004
34

J-9137
Slack Chain. The Continuous and Unspecified measurement systems are also core elements of the APDM. ControlPointAngle (double, 15, 2)A direction angle marking the change in vector direction of the station series from one one control point to the next (45) ControlPointType (domain)The type of control point (e.g., point of inflection, monument, line crossing) EventID (string, 38)Globally unique identifier PIDirection (long integer)The direction of the horizontal at the control point from the vector of the last line segment of which the control point is the endpoint (right, left, none) StationValue (double, 15, 2)The known station value (measure) along a station series at the control point location StationSeriesEventID (string, 38)Foreign key relationship with StationSeries EventID SubTypeCD (long integer)The subtype (measurement system) of the control point SymbolRotation (double, 15,2)Value used to determine symbol rotation for each feature
DocumentPoint (Offline Point Feature Class)
The DocumentPoint feature class contains points that are used to link to one or more external documents stored on a file server to one or more features in the geodatabase. DocumentPoint features can be used to annotate (with supporting documents) features that are not explicitly defined in the geodatabase. A document point might be used in a site area polygon representing the boundary of a meter station or a town border station. The site area can have hyperlinked documents in ArcMap, the DocumentPoint can refer to documents pertaining to specific points within the site area polygon. The DocumentPoint feature class has a many-to-many relationship with the ExternalDocument object class. This relationship models that many document point features can display the same external document and that many external documents can be displayed by one or more document points. DPName (string)A name, alias, or other identifier for the document point EventID (string, 38)Globally unique identifier SymbolRotation (double, 15,2)Value used to determine symbol rotation for each feature
Elbow (Online Point Feature Class, Fitting)
The Elbow feature class describes manufactured elbow fittings. An elbow feature typically represents a bend in the pipeline at a specific angle. An elbow is typically manufactured in angle increments of 15 degrees. Elbow features are designed to carry pressurized product. ElbowAngle (double, 15,2)The angle the elbow bends the pipeline (e.g., 30, 45)
35

J-9137
ElbowRadius (double, 15,2)The radius of the elbow from one endpoint of the elbow to the other endpoint EventID (string, 38)Globally unique identifier
ElevationPoint (Online Point Feature Class)
The ElevationPoint feature class is designed to store elevations taken at specific points along the pipeline centerline. Anytime that a section of pipe is excavated (or initially placed in the ground) the depths of the pipeline features from the ground surface are recorded. The ElevationPoint feature class is also useful for storing the depth of offshore features that are under water. EventID (string, 38)Globally unique identifier FeatureElevation (double, 15, 2)Depth of a pipeline feature below ground surface GroundElevation (double, 15, 2)Elevation of the ground at a specific location MeasurementDate (date)Date the elevation value was recorded SymbolRotation (double, 15,2)Value used to determine symbol rotation for each feature WaterElevation (double, 15, 2)Depth of a pipeline feature below water surface
FieldNote (Offline Point Feature Class)
The FieldNote feature class is designed to store data collected during preliminary routing of pipeline, engineering, environmental, or cultural field surveys. Field notes serve as placeholders for information pertaining to proposed features or survey notes. Field notes also serve as memos or notations that provide additional comments, descriptions, or annotation about existing events or features on or along the pipeline. The FieldNote feature class has a one-to-many relationship with the GeoMetaData object class. The GeoMetaData for a field note stores the provenance of the field note's original position and data collection method. The FieldNote feature class has the following subtypes: cultural notes, environmental notes, facility notes, geopolitical notes, hydrology notes, line crossing notes, operations notes, routing notes, and transportation notes. EventID (string, 38)Globally unique identifier FieldNoteType (domain)The type of field note (e.g., structure location, routing angle) based on the subtype of the field note SubTypeCD (long integer)The field note subtypes (e.g., cultural, geopolitical) SymbolRotation (double, 15,2)Value used to determine symbol rotation for each feature
HCAClass (Online Polyline Feature Class)
The HCAClass feature class (or High Consequence Area Class) denotes the Department of Transportation (DOT) class rating assigned to segments of the pipeline centerline. Class ratings are assigned to pipe segments based on the proximity of populated and other significant high consequence areas that encroach into the boundary of the DOT Class
January 2004
36

J-9137
Corridor3 . Higher class ratings indicate the consequences of an unplanned release of product will be more severe in terms of loss of environmental quality, property, and life. ClassType (domain)The class value assigned to the reach of pipeline (I, II, III, IV) ClassSource (domain)The source of the class rating (e.g., populated area, wetlands) ClassLength (double, 15,2)The length of the continuous reach of class rating EventID (string, 38)Globally unique identifier
HighConsequenceArea (Offline Polygon Feature Class)
The HighConsequenceArea feature class denotes the boundary of high consequence areas that encroach upon the DOT Class Corridor of the pipeline center and effectively drive up the HCA class rating of segments of the pipeline. High consequence areas are navigable waterways, ecological reserves, drinking water recharge zones, and densely populated areas. AreaType (domain)The type of area (e.g., navigable waterway, populated area) ClassArea (domain)The automatic rating assigned to the reach of pipeline that this area affects EventID (string, 38)Globally unique identifier
InspectionRange (Online PolyLine Feature Class)
The InspectionRange feature class represents the length or range of an inline PIG run, the linear extents of an Activity or another type of inspection along a pipeline. Currently there is no published standard format for most of this data. Most of the data returned from an inline PIG run is typically stored in an external data source and is not always easily integrated as part of the GIS. The InspectionRange feature class provides a mechanism to relate this information to a geometric feature in the geodatabase. The InspectionRange feature class has many-to-many relationships with the Anomaly feature class and the Contact object class. These relationships model the occurrence of many discovered anomalies for an inline run and list a contact person for the contractor who conducted the inline run. Inspection Range also has a many-to-many relationship with Activity (many linear ranges represent the spatial extent of one or more recurring activities). InspectionRange models other types of inspections that span a reach of the pipeline; these are modeled as subtypes and include smart PIG runs, cleaning PIG runs, geometry PIG runs, leak surveys, close interval surveys, visual surveys, aerial surveys, and excavations. EventID (string, 38)Globally unique identifier InspectionDate (date)Date the inspection occurred SubTypeCD (long integer)The subtype of the inspection range (e.g., PIG run, aerial survey)
_______________________________________________________
3
HCA Corridors are calculated based on a relationship between pipe diameter and pressure. Corridors can be up to 1000 feet from the pipeline.
37

J-9137
Instrument (Online Point Feature Class)
The Instrument feature class stores information about facilities and equipment typically found on a Process and Instrumentation Diagram (P&ID). Examples of these types of equipment include pressure and temperature sensors, pressure and temperature transmitters, pressure regulators, level indicators, level controllers, valve position indicators, valve positioners, gas samplers, gas chromatographs, flow computers, E/R probes, etc. The instrument feature class is subtyped by instrument type, so new instrument types may be easily added to the model with out resorting to the creation of additional feature classes. Many implementers will choose not to capture all the piping found in a compressor or pump station. For this reason, not all records in the Instrument feature class will have a shape, a Station value and a StationSeriesEventID value. Instrument maintains a manyto-one relationship with SiteBoundary, so Instrument features not related to a Station Series may still be related to a Site Boundary (compressor, valve, or pumping station). In addition, an Instrument feature may be associated with one feature from any of the following online point feature classes via the LinkedFeatureEventID attribute: Tap, Tee, Meter, or Vessel. The relationship of Instrument to Tap, Tee, Meter or Vessel is many-toone. Note the integrity of these relationships is predicated by EventID uniqueness; EventID must be unique across the database to prevent data collisions. The Instrument feature class maintains a one-to-many composite relationship with the InstrumentParameter object class (table). The InstrumentParameter table store information about instruments. Instrument inherits from the FeatureAudit abstract class and contains the following additional attributes: EventID (string, 38)Globally unique identifier SubTypeCD (long integer)The instrument subtype (e.g., Pressure Switch, Solar Panel, Corrosion Coupon, etc.) InServiceDate (date)The date the instrument was first put into service Manufacturer (domain)The manufacturer of the instrument Model (domain)The instrument model (model domain is dependent on instrument type) SerialNumber (string, 30)The instrument serial number DateManufactured (date)The date the instrument was manufactured InstrumentName (string, 80)The instrument name or description PandIDReference (string, 30)The reference label to the instrument on a P&ID diagram (the reference to the actual diagram can be stored in the ExternalDocument table) LinkedFeatureEventID (string, 38)Foreign key to a record in Tap, Tee, Meter or Vessel
January 2004
38

J-9137
SiteBoundaryEventID (string, 38)Foreign key to a record in SiteBoundary
Leak (Online Point Feature Class)
The Leak feature class stores information about leaks, ruptures, and unexpected deliveries or releases that are discovered along the pipeline system and repaired. DateRepaired (date)The date the leak was repaired DateReported (date)The date the leak was discovered/reported Depth (double, 15, 2)The depth of the leak below the surface of the ground EventID (string, 38)Globally unique identifier LeakCause (domain)The cause of the leak (e.g., outside force, corrosion) LeakOrigin (domain)The origin of the leak on the pipe (e.g., girth weld, tap) LeakStatus (domain)The status of the leak (e.g., no leak, repaired) MethodDetected (domain)How the leak was detected (e.g., leak survey, third party) RepairType (domain)Type of repair (permanent or temporary) SymbolRotation (double, 15,2)Value used to determine symbol rotation for each feature
LineCrossing (Offline Polyline Feature Class)
The LineCrossing feature represents a set of linear features (roads, rivers, fences, etc.) that intersect the centerline of the pipeline. Every pipeline company must track any of these features for right-of-way purposes, ownership purposes, and DOT/FERC safety regulations. The LineCrossing feature class has no inherent referential position but relies on the LineCrossingLocation (online point) and LineCrossingEasement (online polyline) to store referenced location information about the line crossing. The LineCrossing feature class has a one-to-many relationship with LineCrossingLocation and LineCrossingEasement feature classes. The LineCrossing feature class also has many-tomany relationships with the Contact and Company object classes. These relationships model the line crossing owner/operator and first contact information for the line crossing. The LineCrossing feature class has the following subtypes: geographic (navigable waterways, drainage, hydrology), cultural/transportation (roads, fences, political boundaries), and utility (foreign pipelines, electric wires). Clearance (double, 15,2)The distance of the line crossing above or below the pipeline at the point of crossing CrossingType (domain)The type of line crossing based on the line crossing subtype (e.g., road, river) EasementWidth (double, 15,2)The total easement width where the LineCrossing intersects the centerline EventID (string, 38)Globally unique identifier
39

J-9137
Name (string)The name of the line crossing (e.g., Kansas Northern Railroad). SubTypeCD (long integer)The subtype of the line crossing Implementation note: Not all companies digitize the linear feature crossing the pipeline centerline, or do so only sporadically. In the situation where digitization of crossing features is sporadic, the LineCrossing feature class will contain some features with <null> shapes. Those companies who do not digitize crossing features at all may prefer to implement LineCrossing as an object class (table), rather than as a feature class.
LineCrossingEasement (Online Polyline Feature Class)
The LineCrossingEasement feature class stores the online location of the easement to either side of a LineCrossing feature when it intersects the centerline. A LineCrossing feature may contain one or more easements. EventID (string, 38)Globally unique identifier LineCrossingEventID (string, 38)The foreign key to the LineCrossing feature
LineCrossingLocation (Online Point Feature Class)
The LineCrossingLocation feature class stores the online location where a LineCrossing feature intersects the centerline. Each LineCrossing feature may have zero or more LineCrossingLocations. EventID (string, 38)Globally unique identifier LineCrossingEventID (string, 38)The foreign key relationship to the LineCrossing feature Orientation (domain)The orientation of the line crossing compared to the pipeline SymbolRotation (double, 15,2)Value used to determine symbol rotation for each feature The Marker feature class stores information about monuments, aerial markers, mileposts, and other offline features that determine position along a pipeline. Marker features are not control points since they do not explicitly mark the route of a centerline. Markers are placed at regular intervals or at points of known locations along the pipeline and serve as reference points. Markers may serve as calibration points for station series features for alternate measurement systems. The Marker feature class has the following subtypes: milepost, aerial marker, monument, survey point, and PIG signal (above ground marker). EventID (string, 38)Globally unique identifier InServiceDate (date)Date marker put into service MarkerNumber (string)An organizational name, code, or number identifying the marker SubTypeCD (long integer)The marker subtypes SymbolRotation (double, 15,2)Value used to determine symbol rotation for each feature
Marker (Offline Point Feature Class)
January 2004
40

J-9137
Meter (Online Point Feature Class, Fitting)
The Meter feature class contains information describing manufactured, pressurized fittings that are used to monitor flow, pressure, and composition of product as it is transported along a pipeline. The Meter feature class inherits additional attributes from the Fitting abstract class. EventID (string, 38)Globally unique identifier MeterFunction (domain)The main function the meter provides (e.g., check, custody transfer) MeterName (string)An organizational name or number assigned to the meter MeterNumber (integer)Uniquely identifies the meter within a group of meters MeterType (domain)The meter style or type (e.g., turbine, rotary, positive displacement) RemoteNetworked (domain)Indicates if the meter can be operated via remote network (Yes/No) SerialNumber (string)The factory assigned serial number for the meter
NonStationedPipe (Offline Polyline Feature Class)
The NonStationedPipe feature class can be used to store pipe segment features not referenced along the pipeline centerline. Nonstationed pipe can be the internal workings of a compressor station that is located along the pipeline, or it can be feeder lines between main lines, meters, or wells and pumps. Nonstationed pipes might also be used as invisible connectors to maintain connectivity within a network of mainline pipes for analytical purposes. Diameter (domain)The outside diameter of the pipe EventID (string, 38)Globally unique identifier InServiceDate (date)The date the pipe was put into service PipeType (domain)The type or function of the pipe (e.g., blowoff, interconnect, kicker) WallThickness (domain)The wall thickness of the pipe
OperatingPressure (Online Polyline Feature Class)
The OperatingPressure feature class is designed to store features describing the current, designed, and maximum allowable operating pressure zones along a pipeline. Operating pressure features can potentially stretch over long reaches of the pipeline system sharing common attribute values. When lengthy linear features span station series, these features must be segmented into lengths no longer than the underlying station series features. The GroupEventID attribute inherited from the Audit abstract class can be used to aggregate many separate operating pressure features, with equal attributes, into a single grouped element. The OperatingPressure feature class has a many-to-many relationship with the
41

J-9137
Contact object class. This relationship establishes the person responsible for verifying the attributes of an operating pressure feature. ActualPressure (integer)The recorded or established pressure for a reach along a pipeline AgreedToPressure (integer)The agreed-to pressure between client and customer for a reach of a pipeline CalculatedPressure (integer)The calculated pressure for a reach of pipeline based on physical and operational characteristics of the pipeline EventID (string, 38)Globally unique identifier PressureType (domain)The type of operating pressure (e.g., maximum allowable, grandfather, operational) VerifiedByEventID (string, 38)Foreign key relate item to the EventID attribute of the Contact object class
PiggingStructure (Offline Polyline Feature Class)
The PiggingStructure feature class models launcher and receiver facilities used to launch and receive inline inspection PIGs. Inline inspection PIGs are used to detect corrosion and geometric anomalies in a reach of pipeline using pressurized flow to propel the PIG through the pipe. Launchers and receivers are often fabricated in situ by a pipeline company. Some pipeline companies station or locate pigging structures via stationing; other companies consider these features to be non-referenced. The APDM does not mandate whether pigging structure features are to be referenced or not. Referenced pigging structure features can optionally be stored as a subtype of the PipeSegment feature class rather than maintained in a separate feature class. BarrelDiameter (domain)The outer diameter of the barrel or pipe of the structure BarrelGrade (domain)The grade of the material to which the structure barrel is rated BarrelWallThickness (domain)The wall thickness of the structure barrel or pipe EventID (string, 38)Globally unique identifier InServiceDate (date)The date the structure was put into service Manufacturer (domain)The manufacturer of the structure barrel or pipe Material (domain)The material used to manufacture the structure (e.g., steel) MillLocation (domain)The name/location of the mill that manufactured the structure StructureLength (double, 15,2)The actual length of the structure PressureRating (domain)The pressure rating of the structure
January 2004
42

J-9137
SubTypeCD (long integer)The subtype identifier for the structure
PipeJoinMethod (Online Point Feature Class)
The PipeJoinMethod feature class stores information about the features that are used to join pipe segments with varying attributes and features for which information must be explicitly recorded. A pipe segment feature in a pipeline system is a generalized feature that is composed of many pipes sharing the same attribute values. When attribute values change between pipe segments, then a pipe join method feature (typically a weld) is placed in between the pipe segments. Other features that are used to link two connected pipe segments can be stored in the PipeJoinMethod feature class. The PipeJoinMethod feature class is divided into the following subtypes: weld, coupling, flange, screw, and electro stop. These features share a common set of attributes and can be divided into separate feature classes as required. Some join method features are manufactured (flanges) and others are constructed or applied in the field (e.g., welds, couplings). EventID (string, 38)Globally unique identifier InServiceDate (date)Date the join method was put into service Insulated (domain)Indicates if the join method is insulated (used to delineate cathodic projection zones) (Yes/No) JoinType (domain)Description of the join method type depending on the feature subtype Manufacturer (domain)The manufacturer of the join method (if applicable) PressureRating (domain)The pressure rating of the join method SubTypeCD (long integer)The subtype of the feature SymbolRotation (double, 15,2)Value used to determine symbol rotation for each feature
PipeSegment (Online Polyline Feature Class, Core)
The PipeSegment feature class is used to model the primary conduit of pressurized product flow of a pipeline system: pipes. The typical size of a pipe used in transmission pipelines is 40 feet. Pipe segment features aggregate many of these pipes into a single feature with common attribute values. Traditionally it is common implementation practice to not explicitly represent each pipe or the joints in between each individual pipe. Rather, pipes were aggregated into larger pipe segment features where all attribute values between the pipes were equal. Where the attribute values changed from pipe segment to pipe segment, a pipe join feature was placed. The PipeSegment feature class has the following subtypes: pipe, bend, and transition. Pipes represent straight pipe features. A bend is a field fabrication where a pipe is bent over a distance to force the pipeline to turn. A transition pipe segment represents where the diameter of the pipe changes over a specified distance. The PipeSegment feature class is considered a core element of the APDM. The rationale for including PipeSegment as a core element is twofold: first, all transmission pipeline systems model pipe segments at some level; second, transmission pipeline systems have many linear features (such as pressure tests, operating pressure, coating, and sleeves) that are dependent on the presence of a pipe segment feature. When a pipe segment feature is altered, removed, or abandoned, then a cascade of data
43

J-9137
maintenance must occur to maintain concurrency between the pipe segment feature and the dependent features. BendRadius (domain)The radius from a centerpoint to the ends of the pipe segment DateManufactured (date)The date the pipe segment was originally manufactured EventID (string, 38)Globally unique identifier GirthWeld (domain)The type of weld used to link the pipes that form the pipe segment Grade (domain)The grade of the material used to construct the pipe segment InletWallThickness (domain)The inlet wall thickness of the pipe segment InServiceDate (date)The date the pipe segment was put into service LongitudinalSeam (domain)The type of well used along the length of the pipes that form the pipe segment Manufacturer (domain)The manufacturer of the pipes that form the pipe segment Material (domain)The material that pipes were constructed of (e.g., PVC, steel) MillLocation (domain)The location of the mill where the pipes that form the pipe segment were manufactured MillTestPressure (long integer)The recorded test pressure when the pipe was milled OutsideDiameter (domain)The diameter of the outer wall of the pipes that form the pipe segment OutletWallThickness (domain)The outlet wall thickness of the pipe segment PipeType (domain)The function the pipe segment performs (e.g., kicker, interconnect, lateral) PreTested (domain)Indicates if the pipe was pretested before it was installed (Yes/No) PressureRating (domain)The pressure rating of the reducer SegmentLength (double, 15,2)The assigned/recorded length of the pipe segment Specification (domain)The specification the pipe segment was manufactured to (e.g., ANSI, API 5) SubTypeCD (long integer)The subtype identifier for each pipe segment
January 2004
44

J-9137
PressureTest (Online Polyline Feature Class)
The PressureTest feature class is designed to store features describing pressure tests conducted along parts of the pipeline. Pressure test features can potentially stretch over long reaches of the pipeline. When lengthy pressure test features span station series, these features must be segmented into lengths no longer than the underlying station series features. The GroupEventID attribute inherited from the Audit abstract class can be used to aggregate many separate pressure test features, with equal attributes, into a single grouped element. EventID (string, 38)Globally unique identifier MinAdjustedPressure (integer)The minimum adjusted pressure of the pressure test MinDesignPressure (integer)The minimum design pressure of the pressure test PreTest (domain)Indicates if a pretest was conducted before the actual pressure test (Yes/No) TestDate (date)The date on which the pressure test was conducted or started TestDuration (domain)The duration of the pressure test (e.g., 4, 8, 16 hours) TestMedium (domain)The medium used to conduct the pressure test (e.g., water, nitrogen) TestName (string)The organizational name assigned to the pressure test TestType (domain)The type of pressure test conducted (e.g., leak, strength, spike)
Reducer (Online Point Feature Class, Fitting)
The Reducer feature class stores information about a reducer facility. Reducers are points along the pipeline where the internal diameter of the pipeline is decreased or increased by the reducer. Reducers are manufactured fittings designed to carry pressurized product. The Fitting abstract class contains attribute definitions for inlet connection type, diameter, and wall thickness. The Reducer feature class inherits from the Fitting abstract class and contains the attributes describing the outlet connection type, diameter, and wall thickness. OutletConnectType (domain)The inlet connection type (e.g., weld, thread) OutletDiameter (domain)The diameter of the outlet OutletWallThickness (domain)The thickness of the fitting at the outlet opening EventID (string, 38)Globally unique identifier ReducerSize (domain)The size of both input and output pipe diameters connected to the reducer (e.g., 4x12, 6x8) ReducerType (domain)The type of reducer (e.g., concentric weld, full open, swage)
45

J-9137
RemovedLine (Online Polyline Feature Class)
The RemovedLine feature class is a container for polyline features that belong to other feature classes in which features have been deleted, removed from the ground, or abandoned in place. Removed lines capture the stationing information that was last used to locate the feature by linear referencing. The attribute names and values are appended into a single string separated by colons and semicolons respectively. These name/value pairs are stored in the Attributes field. The projection information of the original feature's coordinates is also stored for each feature. Attributes (string)The concatenated name/value pairs of the removed features attributes EventID (string, 38)Globally unique identifier EventType (domain)Original feature class name of the removed feature ProjectionID (string)The ESRI projection string unique identifier of the original feature RemovedDate (date)The data the original feature was deleted, removed, or abandoned
RemovedPoint (Online Point Feature Class)
The RemovedPoint feature class is a container for point features that belong to other feature classes in which features have been deleted, removed from the ground, or abandoned in place. Removed points capture the stationing information that was last used to locate the feature by linear referencing. The attribute names and values are appended into a single string separated by colons and semicolons respectively. These name/value pairs are stored in the Attributes field. The projection information of the original feature's coordinates is also stored for each feature. Attributes (string)The concatenated name/value pairs of the removed features attributes EventID (string, 38)Globally unique identifier EventType (domain)Original feature class name of the removed feature ProjectionID (string)The ESRI projection string unique identifier of the original feature RemovedDate (date)The date the original feature was deleted, removed, or abandoned
RightOfWay (Online Polyline Feature Class)
The RightOfWay feature class stores information describing easements and right-of-way information of the pipeline as it passes through polygonal boundaries such as property parcels, operating districts, and municipal/political boundaries. Right-of-way polyline features are used to indicate the starting position of the pipeline as it enters and exits an area including a distance or length value of the reach of the pipeline within the area. Right-of-way features contain easement widths that can be used to buffer the feature. The RightOfWay feature class has many-to-many relationships with the Address, LineLoop, and Contact object classes. These address and contact relationships model ownership and address information for the section of the pipeline that passes through each right-of-way. The line loop relationship provides a mechanism for quickly relating
January 2004
46

J-9137
the right-of-way to an element in the pipeline hierarchy. This relationship is particularly useful for contacting all property owners who fall along the reach of an entire line loop. EasementWidth (double, 15,2)The width of the easement to either side of the right-of-way feature EventID (string, 38)Globally unique identifier ParcelNumber (string)Records the parcel identification number the right-of-way feature passes through and can be used to link the right-of-way to a property information system ROWType (domain)Describes the arrangement between the land owner and the pipeline (e.g., easement, fee, license). TraverseLength (double, 15,2)The measured length of the right-of-way feature.
RiskAnalysis (Online Polyline Feature Class)
The RiskAnalysis feature class stores polylines representing the results of a risk analysis along a reach of the pipeline. Potential risk (probability of failure, rupture, or unplanned release) along the pipeline is calculated based on the structural ability of the pipeline to carry product under pressure. Parameters used for risk analysis might include pipe segment wall thickness, anomaly frequency, soil and other environmental conditions, and coating condition. Risk analysis also entails some quantification of the consequences of a pipeline rupture on property, the environment, and human life. The RiskAnalysis feature class was designed to be customizable and includes suggested attributes. ConsequenceEconomic (double, 15,2)An assigned/calculated economic consequence rating ConsequenceEnvironmental (double, 15,2)An assigned/calculated loss-ofenvironmental consequence rating ConsequenceLife (double, 15,2)An assigned/calculated loss-of-life consequence rating ConsequenceProperty (double, 15,2)An assigned/calculated loss-of-property consequence rating ConsequenceThroughput (double, 15,2)An assigned/calculated loss-of-throughput consequence EventID (string, 38)Globally unique identifier POFConstruction (double, 15,2)Probability of failure due to construction defects POFInternalCorrosion (double, 15,2)Probability of failure due to internal corrosion POFMaterials (double, 15,2)Probability of failure due to material defects POFOutsideForce (double, 15,2)Probability of failure due to an outside force
47

J-9137
POFThirdParty (double, 15,2)Probability of failure due to third party interference TotalConsequence (double, 15,2)Total "loss-of" consequence rating TotalPOF (double, 15,2)Total probability of failure rating TotalRisk (double, 15,2)Total risk rating for the section of pipeline
SiteBoundary (Offline Polygon Feature Class)
The SiteBoundary feature class was designed to store the polygonal boundaries of the various stations and other property owned by a pipeline company. Site boundary 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 boundary features may also be used to demarcate the limit of stationed pipes and nonstationed pipes. One site boundary feature may have one or more DocumentPoint features used to store references to schematics describing in detail the inner connectivity of pipes and other facilities within a site. EventID (string, 38)Globally unique identifier SiteName (string)The organizational site name SiteType (domain)The type of site contained within the boundary (e.g., meter station, compressor station)
Sleeve (Online Polyline Feature Class)
The Sleeve feature class stores information about sleeves, clamps, reinforcements, and other repair features that are applied around the girth of pipes. Sleeve features do not typically overlap each other and are dependent on the presence of a pipe segment feature. EventID (string, 38)Globally unique identifier Grade (domain)The grade of the material from which the sleeve is constructed InServiceDate (date)The date when the sleeve was put into service NominalDiameter (domain)The nominal outside diameter of the sleeve SleeveLength (double, 15,2)The measured/calculated length of the sleeve SleeveType (domain, 15,2)The type of sleeve applied to the pipe (e.g., repair, clamp, composite) WallThickness (domain)The wall thickness of the sleeve
StationSeries (Polyline Feature Class, Core)
The StationSeries feature class is a polyline M Aware feature class used to store the routes by which all referenced features in the APDM are located as events. 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 can have a measure (or station) value assigned to it. Point and linear events are located along the station series route by assigning the Route-ID and a measure value as attributes of the feature (begin and end
January 2004
48

J-9137
measure values for linear events). Linear events must start and end on the same station series (route).4 The APDM UML model has a relationship between each referenced feature class and the StationSeries feature class. It is optional whether these relationships remain explicit or implicit. The StationSeries feature class also has a one-to-many relationship with the ControlPoint feature class. These relationships model the fact that two or more control points act as point representations of the vertices of the station series feature and that the control points have station values that can be used to calibrate the station series feature. The StationSeries feature class has the following subtypes: 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). Slack Chain stationing is typically the default stationing method in most pipeline implementations. Continuous stationing method allows for the aggregation of station series features (typically in the same line loop) into longer, continuous features where stationing values increase monotonically along the entire length of a pipeline. These continuous station series features can be used to generate longer linear event features that span the traditionally segmented smaller slack chain station series features. Unspecified measurement type allows some flexibility for importing control points that have no assigned or calculated stationing that might be the case for preliminary pipeline routing, new construction, or proposed pipeline reroutes. 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 can be used as the ultimate arbitrator of an event's position on or along the pipeline centerline. 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. EventID (string, 38)Globally unique identifier. FromSeriesEventID (string, 38)the EventID of the StationSeries feature connected to the current up station feature SeriesName (string, 45) An operational label or name applied to the station series feature for query and labeling purposes. SeriesOrder (long integer)An arbitrary number used to order station series features for querying and connectivity purposes.
_______________________________________________________
4
Taps, tees, and branch connections are common features found in pipeline models. The APDM models taps and tees explicitly. Branch connections are considered to be an amalgamation of taps and tees and are not explicitly modeled.
49

J-9137
SubTypeCD (long integer)The subtype of the station series representing a unique form of linear referencing or stationing. ToSeriesEventID (string, 38)The EventID of the StationSeries feature connected to the current down station feature.
Structure (Offline Point Feature Class)
The Structure feature class stores information pertaining to any structure located within 660 feet of either side of the pipeline centerline (class corridor). The Federal Department of Transportation requires that pipeline companies maintain information regarding any occupied structure within the class corridor of the pipeline. Typically structures are located as features off the centerline, but a referenced position on the centerline is maintained for each structure. The Structure feature class has a many-to-many relationship with the Address and Contact object classes and a one-to-many relationship with StructureOutline. The address and contact relationships model occupancy and owner emergency contact information. The relationship between structure and outline allows the storage of one or more structure outlines with a structure point allowing for more flexibility in spatial analysis of proximity of the structure with the pipeline centerline. The Structure feature class has a one-to-many relationship with StructureLocation, indicating that the structure may have one or more online point locations. Structure also has a one-to-one relationship with StructureOutline, indicating that the structure can exist as either or both an offline point and/or offline polygon. The Structure feature class is divided into the following subtypes, each representing a generalized classification of the types of structures and primary occupants: residential, business, and civic. DaysOfWeek (domain)The number of days per week the structure is occupied EventID (string, 38)Globally unique identifier OccupantCount (integer)The number of permanent occupants of structure StructureStatus (domain)Indicates how new the structure is (existing, new) StructureType (domain)A description of the structure type and primary usage based on the structure subtype SubTypeCD (long integer)The subtype of the structure WeeksPerYear (domain)The number of weeks per year the structure is occupied YearAdded (integer)The four-digit year that the structure was added to the geodatabase records
StructureLocation (Online Point Feature Class)
The StructureLocation feature class contains the online point locations for a structure that falls within a certain distance (usually 660 or 1,000 feet) of the centerline. A many-toone relationship exists between the StructureLocation feature class and the Structure feature class. This relationship models that many online locations reference an offline structure on the centerline. 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
January 2004
50

J-9137
acting as an online location for an offline point or offline linear feature. (Inherited from OnlinePoint). 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. (Inherited from OnlinePoint). DimensionTie1 (string)Notation describing location information of the structure compared to the location of other known points. DimensionTie2 (string)Secondary notation describing location information of the structure. EventID (string, 38)Globally unique identifier. StructureEventID (long integer)Foreign key relate to EventID attribute in the Structure feature class.
StructureOutline (Offline Polygon Feature Class)
The StructureOutline feature class contains the polygon outlines of structures. A manyto-one relationship exists between the StructureOutline feature class and the Structure feature class. This relationship models that many buildings are associated with a single structure point that is referenced by a point on the centerline. StructureEventID (long integer)Foreign key relate to EventID attribute in the Structure feature class EventID (string, 38)Globally unique identifier
Tap (Online Point Feature Class)
The Tap feature class stores information describing both manufactured tap fittings and tap fabrication (hot taps) located on a pipeline system. The APDM considers a tap to be the joining of two or more pipes at a junction for the purpose of releasing product in a controlled fashion. A tap is usually found in conjunction with a shutoff, check, or release valve.5 The Tap feature class has the following subtypes: tap fitting and tap fabrication. BranchConnectionType (domain)Description of a reinforcing structure around the tap (e.g., saddle, full encirclement) Capacity (integer)A measure of the tap flow capacity CapacityUnits (domain)The units of flow capacity Capped (domain)Indicates if the tap is currently capped and does not conduct product flow (Yes/No) EventID (string, 38)Globally unique identifier
_______________________________________________________
5
Taps, tees, and branch connections are common features found in pipeline models. The APDM models taps and tees explicitly. Branch connections are considered to be an amalgamation of taps and tees and are not explicitly modeled.
51

J-9137
FlowDirection (domain)Indicates flow direction into/from the pipeline system (delivery, receipt, bidirectional) InServiceDate (date)The date the tap was put into service Manufacturer (domain)The name of the tap manufacturer Material (domain)The material that the tap is constructed with (e.g., steel, PVC) Metered (domain)Indicates the tap contains a meter as part of the feature (Yes/No) PressureRating (domain)The pressure rating of the tap SymbolRotation (double, 15,2)Value used to determine symbol rotation for each feature TapSize (domain)The sizes of the branch pipe connected to the tap (1"24") TapType (domain)The function or style of the tap (e.g., blow-off, siphon, threado-let) TappingMethod (domain)The method used to create the tap (e.g., cold tap, hot tap, weld plus) SubTypeCD (long integer)The subtype of the tap
Tee (Online Point Feature Class, Fitting)
The Tee feature class contains information describing manufactured branch or tee fittings designed to carry pressurized product flow from a main to a branch or secondary pipe. The Tee feature class inherits the attributes from the Fitting abstract class and contains information that describes the properties of the connection to the branch pipe. The Tee feature class contains the following subtypes: full on tee, tapping tee, split tee, and wide open tee. BranchConnectionType (domain)The element used to connect the branch to the main pipe (e.g., weld, flange, thread) BranchDiameter (domain)The outside diameter of the branch pipe BranchWallThickness (domain)The wall thickness of the branch pipe Event ID (string, 38)Globally unique identifier ScraperBars (domain)Indicates if the branch has scraper bars to prevent structural interference with inline pigging devices SubTypeCD (long integer)The subtype of tee TeeSize (domain)The diameters of the main and branch pipes (e.g., 12x12x4, 6x6x2) TeeType (domain)The type of tee (e.g., split, stopple, barrel, reducing)
January 2004
52

J-9137
Valve (Online Point Feature Class, Fitting)
The Valve feature class contains information describing manufactured, pressurized fittings used to control or impede flow of product through a pipeline system. Valves provide the control structure for the pipeline system and are often connected to the SCADA monitoring system for a pipeline. Valve features are often part of a generalized pipeline network used for capacity, flow, and hydraulic analyses. Valves describe the inlet and outlet connection and diameter and wall thickness information of the connection input and output pipe features. The pipes that run along a single, unaltered (no station equations) station series contain starting and ending values. The Valve feature class has a relationship with the Reading object class, which models that zero or more readings may be taken at a single valve feature. The valve feature class contains the following subtypes, which are used to define the style of valve: angle, ball, block, check, control, curb, gate, and plug. Automated (domain)Indicates if the valve will automatically open or close in certain circumstances (Yes/No) EventID (string, 38)Globally unique identifier InletConnectionType (domain)The type of connection at the inlet (e.g., weld, flange) InletDiameter (domain)The diameter of the pipe connected to the valve inlet InServiceDate (date)The date the valve was put into service Manufacturer (domain)The valve manufacturer NormalPosition (domain)The normal position the valve is set to (Open/Closed) OperatorType (domain)The operator used to open/close the valve (e.g., gas, manual, electric) OutletConnectionType (domain)The type of connection at the outlet OutletDiameter (domain)The diameter of the pipe connected to the valve outlet PresentPosition (domain)The current position the valve is set at (Open/Closed) PressureRating (domain)The pressure rating of the valve SubTypeCD (long integer)The subtype of the feature class describing the style of valve SymbolRotation (double, 15,2)Value used to determine symbol rotation for each feature ValveFunction (domain)The function that the valve performs (e.g., check, release, main line) ValveNumber (string, 15)An organizational number assigned to the valve
53

J-9137
Vessel (Online Point Feature Class)
The Vessel feature class describes large volume facility features that are used to contain, process, or alter product on or along the pipeline. EventID (string, 38)Globally unique identifier InServiceDate (date)The date the vessel was put into service Manufacturer (domain)The manufacturer of the vessel SerialNumber (string, 30)The serial number stamped or applied to the vessel by the manufacturer VesselType (domain)The type of vessel (e.g., odorizer, filter, scrubber, storage tank) SymbolRotation (double, 15,2)Value used to determine symbol rotation for each feature
Implementation Issues
The following section describes some issues that will need to be addressed by an organization planning to implement the APDM as a geodatabase. The technical committee strove to provide a data model that can be implemented out of the box using the tools found in version 8.3 of ArcToolbox, ArcCatalog, and ArcMap. However, some implementation decisions will require the use of custom code to achieve desired behavior of objects and classes within the model. Every effort was made to mitigate the need for custom code. The APDM is a data model not an object model and thus can only provide a construct for storing and organizing data rather than provide mechanisms that define object behavior. The choices of how the APDM is to be implemented will determine if and when custom code is required to create desired object behavior. The target platform for the APDM 2 is ArcGIS 8.3. All design and implementation considerations were based on the technology available at this release of ArcGIS.
Features as Events, Events as Features
Point and linear events occur along routes at specified measures along the routes. Events 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 and 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. Transmission pipelines have many coincident features whose position is derived from the centerlinein effect, features are essentially dynamic events. These features are geometrically coincident with the underlying centerline. This is the basis for transmission pipelineeverything is located via stationing. A mechanism to identify dependent features that must also be updated when edits to the features and/or centerline occur is topology.
Topology and the Geometric Network
January 2004
54

J-9137
Topology is a set of rules that define where geometry 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 data integrity. The rules of topology define how these 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. "Dirty areas" appear for points, lines, and polygons when topological rules are broken. Dirty areas are used to identify exceptions to the topology rules and allow for data maintenance and quality control. Topology exists as a structure within the geodatabase, and, for all intents and purposes, acts as another feature layer in ArcCatalog and ArcMap. Some general guidelines and rules to keep in mind when implementing a topology are listed below. Annotation, dimension, and geometric network features are complex features and cannot participate in a topology. Multiple topologies can exist in a single feature data set. One feature class can participate in only one topology. A topology and a geometric network can coexist in the same feature data set, 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 will hurt performance since each error that is generated for a topology is an error that is written into the geodatabase. Using subtypes will increase performance since less 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 a geometric network on a stand-alone data set stored in a personal
55

J-9137
geodatabase and that the results of the analysis be loaded back into the enterprise geodatabase.
EventID, OriginEventID, GroupEventID and LinkedFeatureID
The EventID attribute is used to globally identify each feature in the geodatabase independently of the feature or object class to which the object belongs. EventID can be stored as a long integer (approximately two billion unique identifiers) or a 16 character string containing a GUID (potentially unlimited range of unique values). In the case that the long integer format is used for EventID, then the last used EventID value must be maintained in an object class or another storage construct. It is possible to apply and maintain the last used EventID value manually, but this is a tedious process. At some point, an organization will see the need to maintain this value programmatically or via the underlying RDBMS (identifiers, sequences, etc.). The OriginEventID and GroupEventID attributes are provided for historical tracking purposes and for grouping a set of referenced linear or point features together as a "superfeature." The typical application of GroupEventID is to maintain connectivity between sections of a linear feature that must be broken at the boundaries of station series features (station equations). OriginEventID is used to store the EventID of a parent feature that has been split or broken into separate child features. In this case, the child feature would store the original EventID in the OriginEventID field. The naming convention for foreign keys in the data model is <foreign class name>EventID. In some classes, a foreign key named LinkedFeatureEventID can be found. LinkedFeatureEventID stores the foreign key to one of several feature classes. LinkedFeatureEventID is used when a feature may be related to only one of several different feature classes. Examples of feature classes implementing LinkedFeatureEventID include CPOnlineLocation and Instrument. Some feature classes use SubTypeCD to indicate which feature class the LinkedFeatureEventID is pointing to.
Developing Applications
The delineation of the core elements of the APDM should provide a standard framework for application developers and software vendors to develop portable applications that will work on most, if not every, properly implemented APDM. It is suggested that application developers write applications that respond to the core attributes and feature classes in the model according to the specifications recorded in this document. Applications should be responsible to the variations in other feature classes and attributes. The APDM was designed to provide a core set of objects that would 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 will need to respond dynamically to objects that are defined within the APDM beyond the core elements. 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,
Conversion To/From PODS and ISAT
January 2004
56

J-9137
the begin/end offset angle, and distance and side attributes for on/offline features. Import nonreferenced features with geometry as required.
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 could 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. 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.
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 Pipeline Special Interest Group steering and technical committees. The positions on the APDM steering and technical committees are elected. Contact Andrew Zolnai (ESRI petroleum market manager) at azolnai@esri.com for more information on serving on the APDM technical or steering Committees. The APDM technical committee will meet three times a year, at the following venues, to discuss proposed improvements and alterations to the model. ESRI Electric and Gas Utility User Group Meeting (September/October) ESRI Petroleum User Group Meeting (February/March) APDM User Group Meeting at the ESRI User Conference (July/August) If you have any suggestions for changes or requests for information please contact Greg McCool (El Paso Corporation) greg.mccool@elpaso.com (Steering Committee Chairperson) Peter Veenstra (GE Energy) peter.veenstra@og.ge.com (Technical Committee Chairperson) Andrew Zolnai (ESRI) azolnai@esri.com (ESRI Petroleum Market Manager)
57

APDM WhitePaper v3

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

APDM WhitePaper v3

Caricato da

Copyright:

Formati disponibili

ArcGIS Pipeline Data Model

An ESRI Technical Paper September 2004

ArcGIS Pipeline Data Model

ESRI Technical Paper

ArcGIS Pipeline Data Model

ArcGIS Pipeline Data Model

ESRI Technical Paper

ArcGIS Pipeline Data Model

ArcGIS Pipeline Data Model

What Is the APDM?

ESRI Technical Paper

ArcGIS Pipeline Data Model

APDM and Other Pipeline Data Models

Why Use the APDM?

ArcGIS Pipeline Data Model

History of the APDM

ESRI Technical Paper

ArcGIS Pipeline Data Model

APDM Steering Committee

APDM Technical committee

Difference Between a Standard and a Template

ArcGIS Pipeline Data Model

ESRI Technical Paper

ArcGIS Pipeline Data Model

Stationing and Station Equations

ArcGIS Pipeline Data Model

ESRI Technical Paper

ArcGIS Pipeline Data Model

Arbitrary (Pseudodistance Based)

The Centerline (Routes, Measures, and Events)

ArcGIS Pipeline Data Model

Events Versus Features

ESRI Technical Paper

ArcGIS Pipeline Data Model

APDM Conceptual Model Core Elements

ArcGIS Pipeline Data Model

APDM Core Feature Classes and Objects

ESRI Technical Paper

ArcGIS Pipeline Data Model

ArcGIS Pipeline Data Model

Conceptual Feature Classes

Online Point Features

ESRI Technical Paper

ArcGIS Pipeline Data Model

Online Linear Features

Offline Point Features

Offline Linear Features

ArcGIS Pipeline Data Model

Offline Polygon Features

ESRI Technical Paper

ArcGIS Pipeline Data Model

APDM Geodatabase Structure

ArcGIS Pipeline Data Model

ESRI Technical Paper

ArcGIS Pipeline Data Model

Feature Point Fitting

ArcGIS Pipeline Data Model

Object and Feature Classes

Object Classes Activity (Object Class)

ESRI Technical Paper

ArcGIS Pipeline Data Model

<classname>Activity Event (Object Class)