APDM_WhitePaper_v3

7/27/2019 APDM_WhitePaper_v3

http://slidepdf.com/reader/full/apdmwhitepaperv3 1/63

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

ArcGIS ® Pipeline Data Model

An ESRI ® Technical Paper • September 2004



Copyright © 2004 ESRIAll rights reserved.Printed in the United States of America.

The information contained in this document is the exclusive property of ESRI. This work is protectedunder 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 asexpressly permitted in writing by ESRI. All requests should be sent to Attention: Contracts Manager,ESRI, 380 New York Street, Redlands, CA 92373-8100, USA.

The information contained in this document is subject to change without notice.

U.S. GOVERNMENT RESTRICTED/LIMITED RIGHTS

Any software, documentation, and/or data delivered hereunder is subject to the terms of the LicenseAgreement. In no event shall the U.S. Government acquire greater than RESTRICTED/LIMITEDRIGHTS. At a minimum, use, duplication, or disclosure by the U.S. Government is subject to restrictionsas set forth in FAR §52.227-14 Alternates I, II, and III (JUN 1987); FAR §52.227-19 (JUN 1987) and/orFAR §12.211/12.212 (Commercial technical Data/Computer Software); and DFARS §252.227-7015 (NOV1995) (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 andproducts mentioned herein are trademarks or registered trademarks of their respective trademark owners.



J-9137

ESRI Technical Paper i

ArcGIS Pipeline Data Model

An ESRI Technical Paper

Contents Page

Introduction...........................................................................................1

What Is the APDM?..............................................................................1

APDM and Other Pipeline Data Models ..............................................2Why 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).............................8Hierarchy.........................................................................................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 .................................................................................12LineLoop.........................................................................................13

Conceptual Feature Classes ............................................................13

Pipe Segment ............................................................................13

Online Point Features................................................................13

Online Linear Features..............................................................13

Offline Point Features...............................................................14




J-9137

January 2004 ii

Offline Linear Features.............................................................14

Offline Polygon Features ..........................................................14Topology.........................................................................................15

Centerline........................................................................................15

APDM Geodatabase..............................................................................15

Structure..........................................................................................16

Domains..........................................................................................16

Inheritance.......................................................................................16

Object........................................................................................17

Auditing ....................................................................................17

Feature.......................................................................................18

Point ..........................................................................................18

Fitting........................................................................................18Online 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) ..............................................................22ExternalDocument (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) ....................26Anomaly (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




J-9137

ESRI Technical Paper iii

CPGroundBed (Offline Point Feature Class)............................30

CPRectifier (Offline Point Feature Class) ................................31CPTestStation (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) ..............................36HighConsequenceArea (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) .................41PiggingStructure (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) ....................................48StationSeries (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




J-9137

January 2004 iv

Valve (Online Point Feature Class, Fitting)..............................53

Vessel (Online Point Feature Class) .........................................54Implementation 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



J-9137

ESRI Technical Paper

ArcGIS Pipeline Data ModelIntroduction This technical paper explains the ArcGIS Pipeline Data Model (APDM)

and is written for those interested in implementing a transmission pipelinegeodatabase using ESRI® ArcGIS® software. The document is written forpipeline company managers, developers, and graphic operators. Itprovides a detailed description of the objects in the model, how the modelis organized, and suggestions of how the model can be implementedwithin an organization. The document assumes that the reader has aworking knowledge of common pipeline terminology, such as stationing,centerline, station series, and control points, and a working knowledge of ESRI linear referencing technology.

What Is the APDM? The ArcGIS Pipeline Data Model is designed for storing information pertaining tofeatures found in gathering and transmission pipelines, particularly gas and liquidsystems. The APDM was expressly designed for implementation as an ESRIgeodatabase for use with ESRI's ArcGIS and ArcSDE® products. A geodatabase is anobject-relational construct for storing and managing geographic data as features within anindustry-standard relational database management system (RDBMS). The model andsupporting documentation can be downloaded by any member of the ESRI PipelineInterest Group (PIG) from ESRI's Web site at www.esri.com/pipeline or by the public atESRI'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 bymembers of the ESRI Pipeline Interest Group steering and technical committees, underthe guidance of ESRI. The technical committee includes representatives from pipelineand 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 toinclude 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 APDMis not designed to be a comprehensive or all encompassing model. Rather, the APDMwas designed to be a template from which a pipeline company would start with the coreelements of the model and modify the model by adding features or refining existingfeatures. 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 theAPDM 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 toprescribe a rigorous methodology or standard approach to modeling pipeline systems. Itwas the intent of the model to provide a set of core objects and attributes that describeand 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




J-9137

January 2004 2

of features is to provide pipeline vendor companies with a consistent framework fordeveloping applications against the model and for data transfer between existingdatabases. 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 bybusiness needs. The core elements of the model remain a small subset of the featuresfound in the model, and any new features added must fall into one of the conceptualAPDM categories: referenced features or nonreferenced features, online features oroffline features. Another focus of the APDM was to develop a model that end userscould implement and add data to without the need for custom code or developmentefforts. This is achieved by using core ESRI technology that allows any pipelinecompany to develop a custom data model that meets its business needs.

APDM and OtherPipeline Data

Models

The APDM was derived in part from established pipeline data models: Integrated SpatialAnalysis Technology (ISAT), Pipeline Open Data Standard (PODS), and IndustryStandard Pipeline Data Management (ISPDM). These three models are designed for

industry-standard relational database management systems. The APDM is designed tofully exploit ESRI geodatabase technology. The feature classes in the APDM werederived from the tables contained in the ISPDM, ISAT, and PODS models. The salientattributes found in the feature classes of the APDM can be found in the attributes of thetables in the PODS, ISAT, and ISPDM models. The geodatabase, and thus the APDMincorporates a relational database engine to store an object-relational model that extendsthe standard RDBMS technology. The APDM is an object-relational databasemanagement system and, therefore, cannot be accessed using standard Structured QueryLanguage (SQL) or other data access technologies (e.g., Open Database Connectivity[ODBC] or Microsoft ActiveX Data Objects [ADO]). The primary method forcustomizing and accessing the data stored in the APDM is through the core ESRI ArcGIStechnology and its underlying component model, ArcObjects™. Although the contentand underlying technology of the PODS, ISAT, and ISPDM models and the APDM aresimilar, the access methods used to manipulate the structure and content of these models

are very different.

Why Use theAPDM?

The prime consideration for using the APDM over a standard relational database modelis: Do the benefits of the extended geographic information system (GIS)—analytical,cartographic, and editing functionality—override the need to integrate the database withother industry-standard applications and data access technologies? Other considerationsfor 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 attributedata. Editing operations in the RDBMS world require application logic to drive

updates of feature geometry and attributes or attributes then feature geometry. Thisis a dilemma in the relational model where feature geometries are typically snapshotsof the database; each time the database is modified, then the feature geometries arepotentially dated and must be rebuilt.

The geodatabase seamlessly enforces the linkage between feature geometry andattribute data; in addition, it allows the construction of more complex relationshipsthat simplify and streamline editing operations.




J-9137

ESRI Technical Paper 3

The geodatabase (and the APDM) offers less expensive data maintenance of interrelatedspatial 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. Utilizinga geodatabase for storage of GIS data provides end user access to all the powerful ESRIGIS analytical technology. Other compelling technology included in the geodatabaseincludes multi-user, long transaction versioned editing; coincident feature editing viatopology; 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 locatingfeatures 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 differentiatesthe APDM from the standard ESRI Gas Distribution Model. The model was developed

for ESRI enterprise software ArcGIS/ArcSDE technology, which is entirely predicatedon the geodatabase. The APDM was developed by a committee of pipeline companyoperators and vendors. The intellectual property of the APDM is owned by ESRI (theworld's leading GIS software vendor) who, in conjunction with pipeline companies andvendors, 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 betteranalysis of that data, all important to a highly regulated and important industry such astransmission pipelines.

History of theAPDM

The APDM was developed jointly by the ESRI Pipeline Interest Group steering andtechnical committees. The technical committee was responsible for developing thestructure, content, and technological aspects of the model. The steering committee wasresponsible for the organizational/promotional aspects of the model. Ultimately bothcommittees 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. Everyattempt was made to make the APDM open to data transfer between each model. Thesteering and technical committees strove to balance the interests of each pipeline modelgroup, the pipeline companies, and the pipeline vendor community. Participation in bothcommittees was divided between operational (client) and vendor communities andISAT/PODS data model members. Below is a brief chronology of the model'sdevelopment.

March 2002—M.J. Harden, starts the initial work on the model.

July 2002—The model is presented at the ESRI User Conference in San Diego,California. An open invitation to participate in the design of the model is extendedto the pipeline community.

August 2002—The initial meeting of interested member groups occurs at ESRI,Redlands, California.

October 2002—The steering and technical committees are officially formed at theESRI Electric/Gas Utility User Group Conference (EGUG), Coeur d'Alene, Idaho.

December 2002–June 2003—Monthly technical and steering committee meetings atvarious member organizations. Development of intellectual property agreement,




J-9137

January 2004 4

steering committee charter, technical committee mandate, operational procedures,and APDM content and structure.

March 2003—The APDM is released for public comment at the ESRI (PetroleumUsers Group )PUG meeting, Houston, Texas.

July 2003—Version 1 of the APDM is officially released at the ESRI InternationalUser Conference, San Diego, California.

October 2003—Model reviewed and version 2 proposed by the APDM technicalcommittee 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 committeeterms 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 UserConference and the ESRI EGUG and PUG meetings. The following persons andagencies participated in the original steering and technical committees (as of August2003).

APDM SteeringCommittee

A ten (10) person committee charged with setting the organizational direction of theAPDM within the context of the pipeline industry. The Steering COmmittee meets onceper month via phone conference on the second Wednesday of the month. Greg McCool([email protected]) is the current chairperson of the APDM Steering Committee.

APDM Technical committee

A ten (10) person committee charged with developing the technical content of the APDMmodel. The technical committee meets three times per year during the ESRI PetroleumUser Group Conference (PUG) in February/March, the annual ESRI User Conference

held in July/August and the GITA Oil & Gas Conference (September). Technicalcommittee meetings are open the anyone interested in furthering the model however onlythe technical committee members are allowed to vote on changes to the APDM. PeterVeenstra ([email protected]) is the current chairperson of the APDM TechnicalCommittee.

Difference Betweena Standard and a

Template

The APDM is intended to be a template, not a standard. There is no governingorganization that has officially approved the APDM as a standard. The features andrelationships in the model were determined to be critical or common to 80 percent of allpipeline companies' typical implementations of geographic information systemtechnology. 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 modelwas never to create a database standard but rather to create a database template fromwhich 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 bemaintained in order to preserve a standard for data transfer, application development, andconversion efforts between APDM implementations.

Design Rationale The APDM is a geodatabase model that was developed for implementing transmission(gas and liquid) pipelines. This section will outline the design rationale considered atevery stage of developing the APDM. These justifications served as guidelines forensuring the model met the needs of the pipeline industry. Each justification describes




J-9137


some of the considerations and background material that were measured and weighed todetermine the final model.

This section is divided into the following parts, each of which describes the drivingforces behind how the APDM was developed.

Core ElementsStationing and Station EquationsThe Centerline (Routes, Measures, and Events)HierarchyCoincident GeometryEvents Versus FeaturesManaging 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 everythingfor all organizations. Realizing the variation in how data is modeled between differentpipeline companies, the technical committee developed the APDM according to fourguiding principles.

The APDM is designed to provide a set of core elements that will remain consistent forany APDM implementation. The core elements are designed to ease data transferbetween existing pipeline data models and for the development of portable APDMapplications by third party vendors.

The APDM will provide a mechanism for locating features on or along the pipelinecenterline by both absolute positioning and by linear referencing (commonly referred toas stationing). It is not the purpose of the APDM to prescribe the approach toimplementation 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 orobjects) will be included in the APDM if they are required by 80 percent of all pipelinecompanies and are required by United States government regulatory agencies.

1The

APDM can be implemented and maintained within a geodatabase without the need forcustom application code.

Core Elements The prime object of the technical committee was to keep a small, well-defined set of coreobjects with required attributes. These core elements would provide the mechanismfor linear referencing to locate events as geometric features or dynamic events. Thesealso 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 coreelements remain intact and immutable. The core elements are required for maintenanceof 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 theremainder 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

_______________________________________________________1 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 regulat ions 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

January 2004 6

most common features rather than being an all-inclusive description of every possiblefeature found on or along a pipeline system. The purpose of the APDM is to allowpipeline companies to build geodatabases to suit their business needs. The core elementsof the model provide a standard set of features—the rest is up to the end users to pick andchoose 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 generalizedfeature classes. The APDM does not restrict or require inclusion of these features. Otherthan the core elements of the model, it is up to the user to determine what is or is notincluded in the model.

The amount of data that pipeline companies are able to access has exponentiallyincreased within the last decade. In the historical paper world it was conceivable to

manage thousands of features. With the advent of faster computers, better integrationbetween disparate systems, and the proliferation of readily available digital data in a widevariety 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 coreof required elements, the APDM is very open and flexible to integration with largercorporate or enterprise data systems. In this manner, the APDM can be implemented asthe 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 onlythe 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 stationseries and station value. A station series is a linear path representing a portion of thecenterline of the pipeline or the route that the pipeline follows across the surface of theearth. 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 eventscould be located along a station series representing the location of a feature or the start orend 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 serieslinear feature. Each station series is thus composed of two or more known points of stationing. Stationing monotonically increases or decreases without gaps from a beginpoint to an endpoint of a station series. Once stationing is assigned to the centerline, thestationing values for known points along the centerline do not change. When the pipelineis first built, the stationing measurements were uninterrupted and continuous along thelength of the entire pipeline. When a pipeline is rerouted (i.e., the path of the centerlineis altered), discontinuities are introduced into the stationing. The points of the breaks instationing 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 reroutedwith the addition of a new station series.

Any event occurring between two control points will have a station value calculated bythe 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 absolutecoordinates for each vertex of the feature. Using stationing (linear referencing or relativepositioning), a dynamic method for determining the location of a feature (or event) isavailable. The ESRI geodatabase supports both of these methods. Once the location of a




J-9137


feature is determined using either absolute or relative positioning, then the otherpositioning values can be determined (provided an underlying centerline of station seriesfeatures is available). It is important to realize that the ArcGIS Pipeline Data Model putsmore emphasis on absolute rather than relative positioning. If the underlying controlpoint and station series network is highly representative of the underlying terrain withaccurate positioning in sufficient density, then the calculation of relative position is easilyobtained once the station values of known control points are determined and quantified.However, performance of large numbers of event or relative positioned features hasperformance 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 surveyorwould delineate the centerline of the pipeline using a distance (measured by chains) andangle from the last collected point of the centerline. The angle and distance calculationsestablished 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 positioning—with the advent of theglobal positioning system (GPS) in conjunction with highly accurate digital rectifiedorthophotography—become mainstream for creating the known points of the centerline.

Stationing is based on traditional field survey and drafting methodology and is thehistorical method of conducting business for a pipeline. Stationing is the primary methodfor historical record keeping that pipeline companies are required to maintain forregulatory 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 NorthAmerica are required to locate all facilities on or along the pipeline. Stationing is used tolocate 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 thethree-dimensional distance of the earth's surface, rather than the two-dimensionaldistance 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 vectordistance).

Horizontal—The 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).

Continuous—Stationing starts at a set value and continuously and cumulativelymeasures either slack or horizontal distance from the start to the end of a centerlinealong all station series.




J-9137

January 2004 8

Arbitrary

(PseudodistanceBased)

Mile Posting—Posts or other markers are placed in or on the ground at arbitraryintervals and are used as reference points for locating features.

Offset Based—Measurements are taken as offset values from known points along thecenterline (e.g., valve section—the feature is located 100 feet downstream from themainline valve).

The Centerline(Routes, Measures,

and Events)

The centerline of a pipeline system is composed of a station series, which in turn iscomposed of control points. The station series concept allows each and every stationvalue (e.g., a point location) along the pipeline centerline route to be uniquely located at aspecific geographic coordinate even when duplicate station values exist on a singlepipeline. Duplicate station values usually occur after a section of an original line isrelocated or rerouted, resulting in the creation of a station equation to compensate for theadditional installed pipe length. It is also possible to have duplicate station values fordifferent 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 beginningand end station value and belongs to a line loop.

Control points are points along the pipeline centerline with known geographic positioncoordinates and a known station value. When a group of control points is assigned to aspecific station series, then the centerline of the pipeline can be graphically represented inits real-world geographic location based on the selected coordinate system and mapprojection. 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 anoffline point event with known geographic coordinates (i.e., a section corner), or at anypipeline centerline location with known geographic coordinates such as GPS surveypoints.

Conceptually, station series and control points are directly analogous to ESRI linearreferencing route and measures. A station series feature is an M (measure) Awarepolyline feature called a route. The measures of the route are defined at each vertexincluding the endpoints. Since control points are used to form the vertices of the stationseries feature, the measure value in the vertex is also the station value assigned to thecontrol point. Events are point or line entities or objects that occur on, along, or besidethe centerline. Each point event on, beside, or along the centerline will have an absoluteposition and a relative position (or absolute/relative start and end position if a linearfeature). The absolute position of an event is measured by the x,y coordinates of thefeature once the relative position of the event has been determined. The relative positionof 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 throughthe known control points (that act as vertices of the station series) to the point where theevent 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 thestation series relative to the station values of the bordering control points and the stationvalue of the event. Point events are located on a single route feature. Currently, ESRIlinear referencing technology dictates that linear events must also start and end on thesame route.

Station series features are modeled as M Aware or Z (elevation) Aware polyline featuresin the APDM. Control points are modeled as M Aware or Z Aware point features in the




J-9137


APDM. Both station series and control points are considered core elements of theAPDM.

Hierarchy Pipeline companies often organize or group features according to a hierarchy. Typicallyhierarchy is based on where particular station series features are located. A typicalhierarchy will place a station series feature belonging to a single line. Each line willbelong to a single pipeline system. Many pipeline systems will belong to a pipelinecompany. Even a simple hierarchy can be broken down into more complexorganizational structures such as discharge subsystems, valve sections, branches, andmain lines. There is no standard hierarchy structure that pipeline companies adhere toother than some kind of hierarchy present in most pipeline systems.

The most ubiquitous form of hierarchy in pipeline systems is the line loop. The APDMaccounts for hierarchy by assigning each and every station series to one or more lineloops. 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 borderstations to distribution centers or refineries). A line loop might be a mainlinetransmission pipe or a branch from a gathering field. Often several line loops will runparallel to each other. A line loop may have gaps along the entire pipeline as pipes areoften 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 lineloops. The APDM does not account for any logical network or connectivity of stationseries features. Each station series feature is uniquely identified in the model. The lineloop construct is used at the simplest level to organize station series features into ahierarchy.

Line loop is modeled as an object class in the APDM and is considered to be one of thecore 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 pointand line features in a transmission pipeline. Any feature that is located by relativeposition is coincident or offset from the centerline. Any change in the geometry and/orthe underlying station (measures) of the centerline route system has ramifications on thegeometric location of features or events whose positions are dependent on the appliedmeasures and position of the centerline. Linear features, such as coating and pressuretests, are child features dependent on the presence of parent linear features such as pipesegments. The relationship between these features dictates that if the parent is removedor altered (partially removed, vertex position changed) then the child must be similarlyaltered. 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 orstation (measure) attributes. Relationship classes can be used to maintain the station

(measure) relationships between the centerline and dependent child features. Topology isthe recommended solution for handling the geometric relationships between coincidentgeometries from different feature classes.

Events Versus Features

The APDM can be implemented with features stored in feature classes (geometry isstored with x,y coordinates), event tables (geometry is dynamically generated fromRoute-ID and measure values), or a combination of both. Each implementation approachhas costs and benefits. The benefit to using geometry is that performance is excellent, thefeatures can be displayed quickly through the Internet via ArcIMS, and the features can




J-9137

January 2004 10

be edited directly in ArcMap™. The dilemma that arises when using geometry is that thefeature does not automatically recalculate the feature geometry when the underlyingRoute-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 areupdated, then the geometry can be quickly refreshed. If an error occurs when the eventgeometry is being created, then an error message can be appended to the row containingthe feature. The dilemma when using events is that each feature does not have permanentgeometry and, thus, performance is poor and the features are not available in real timethrough the Internet. Large volumes (more than 10,000 events) of data cannot beexpected to perform in a timely manner given the current state of the technology. Theideal 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 isaltered. Currently, the only way to obtain this behavior from the geodatabase is viacustom 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 ConceptualModel

All the features in the APDM can be organized into one of three categories: coreelements (centerline features and stationing attributes), referenced features (online andoffline features), and non-referenced features (land base and support features). Eachcategory of features is described relative to the APDM.

Core Elements Core elements are standard objects or items (e.g., feature classes, object classes, andattributes) within the geodatabase that define the model as APDM-compliant. Coreelements 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 theattributes that are required to locate features that are located by linear referencing(stationing): referenced features. The core elements of the model are described later inthis document.

Online Features Online features represent a classification of features that are found as events on thecenterline. Online features can be located by the x,y values in the coordinatesof 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). Onlinefeatures can only be point or line features. Online features must be geometricallycoincident and geometrically constrained to the centerline features (station series) of thepipeline. Features that are geometrically coincident are point or linear features that sharethe same edge as the station series features that comprise the centerline. Features that aregeometrically constrained are linear features that share not only the edge of the centerlinebut 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 (stationseries) on which the feature will be located. Online point features must also have ameasure value (station) along the specified route. Online linear features must have abegin measure attribute (station) and an end measure attribute (station) along thespecified 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 astation series ID attribute, a measure attribute, an offset distance attribute, and an offset




J-9137


angle attribute. An offline point feature is located by the offset distance and angle fromthe online point location feature on the centerline. The offset angle is the angle of theline drawn from the point on the centerline to the offline point feature. The offset angleis measured from the centerline, looking toward the increased station values. Onlinelinear features can act as online locations for both offline polyline and offline polygonfeatures. For the former, the online polyline location feature might represent theeasement to either side of where the offline linear feature intersects the centerline; for thelatter, the online polyline location feature represents the overlap of the polygon on thecenterline or the range of intersection of the centerline by the polygon.

Offline Features Offline features are located by geographic coordinates only. Offline features compriseany feature that is ancillary to the operations and description of the pipeline system andthe underlying geography. There are no core offline feature classes. Feature classes inthis 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.

APDM Core FeatureClasses and Objects

The APDM is designed to allow end users to modify the content of the model to meetGIS, organizational, and business requirements. The model has several core elementsthat must remain consistent for each implementation of the APDM. The core elementsare required to maintain the centerline and the framework for applying and using linearreferencing along the centerline. The core elements consist of several feature and objectclasses and attributes for describing centerline and referenced features. Online featureclasses (such as online points and online polylines) are conceptual feature classes andcontain 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. Endusers are free to remove, add, or modify any of the suggested feature classes andattributes except the core elements to build a model that meets their business needs. Thenames for core elements in the model are suggested names. ArcObjects provides a

construct for naming objects in a geodatabase using model names. The APDM acceptsobject names and model names as the same. The core elements must be named usingeither 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.

EventID All feature classes and object classes must have an attribute named EventID. Thisattribute 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 uniquelyidentifying each feature or object in the geodatabase independent of the feature or objectclass to which it belongs. EventID is specified as a GUID format (38 character string) tomake each object in any class globally unique from all other features. Using GUIDS forunique 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 ObjectID does not ensure global uniqueness or the preservation of a unique ID value assigned toeach feature on export and import. Note that the term "event" in EventID does not denotethat this attribute pertains to event tables or events only. EventID was chosen torepresent a global ID for any event that occurred on or along a pipeline system, be it anonline or offline feature. EventID could have as easily been replaced by a term such as"Feature ID" or "GeoEntity ID".




J-9137

January 2004 12

Station Series Station Series is an M Aware (optionally Z Aware) polyline feature class that describesthe centerline. The geometry of a station series feature must be simple. Many of the coreESRI linear referencing tools do not work with multipart geometry. Each station seriesostensibly represents a set of monotonically increasing or decreasing stationing withoutany 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 thefollowing attributes:

BeginStation (double, 15, 2)—The station value assigned to the beginning of thestation series.

EndStation (double, 15, 2)—The station value assigned to the end of the stationseries.

SubTypeCD (long integer, 9)—The subtype field. Each subtype denotes a new typeof stationing measurement.

EventID (string, 38)—Globally unique identifier.

FromSeriesEventID (string, 38)—The foreign key of the Station Series feature that isconnected up station of the station series feature. Connectivity between station seriesfeatures provides the basis of a logical network along the centerline.

ToSeriesEventID (string, 38)—The foreign key of the Station Series feature that isconnected down station of the station series feature.

SeriesOrder (long integer, 9)—An arbitrary number assigned to a station series forthe purposes of sorting queries and creating connectivity between station seriesfeatures.

The Station Series feature class must have at least one subtype. The default subtype forthe station series will be considered the primary measurement system (or primaryreference mode) for the pipeline system. Each subtype represents a unique method of stationing. The Control Points and Station Series feature classes must share the samesubtypes. All other attributes in the Station Series feature class are optional and can bedeleted, added, or modified as required.

Control Points Control Points is an M Aware and Z Aware point feature class that describes thecenterline. Each control point represents a known point of stationing including eachvertex and the endpoints of the station series feature. Each control point represents apoint of inflection (bend), a known point of stationed position, a monument, or a linecrossing along the station series. Control points contain the station information for thestation 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 featureclass denoting the station series to which the control point belongs.

SubTypeCD (long integer, 9)—The subtype field. Each subtype denotes a new typeof stationing measurement.

EventID (long integer, 9)—Globally unique identifier.




J-9137


The Control Points feature class must have at least one subtype. The default subtype forcontrol points will be considered the primary measurement system for the pipelinesystem. Each subtype represents a unique method of stationing. The Control Points andStation Series feature classes must share the same subtypes. All other attributes in theControl Points feature class are optional and can be deleted, added, or modified asrequired.

LineLoop LineLoop is an object class designed to store information describing a line in the pipelinesystem. One line loop object may have one or more station series features that comprisethe line. A single line loop may have one or more line loops that comprise the line. TheLineLoop object class must have the EventID attribute (string, 38), which uniquelyidentifies the line loop within the geodatabase. All other attributes in the LineLoopobject class are optional and can be deleted, added, or modified as required.

Pipe Segment Pipe Segment is the only feature class (other than Station Series and Control Points) thatis considered core to the APDM. The features in the Pipe Segment feature class areM Aware online polyline features. Pipe segment features are geometrically constrainedand 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 ubiquitousfeature 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 segmentgeometry is altered, the alteration affects many other features. Most colinear features inthe model are dependent on the Pipe Segment feature class.

Conceptual FeatureClasses

The conceptual feature class descriptions are provided as templates. Any referencedfeature 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 featureclasses 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 Online point features are stored in an M Aware (optionally Z Aware) point feature classthat is geometrically coincident with the centerline. Online point features are located bylinear referencing using a Route-ID and a Measure field. Online point features can beused to model concrete features that occur along the centerline or as online locations foroffline point or offline polyline features. Online Point feature classes must have thefollowing attributes:

BeginOffsetDistance (double, 15,2)—(optional) The distance of the point featurefrom a point referenced on the centerline. Only used if the online point feature isacting as an online location for an offline point or offline linear feature.

BeginOffsetAngle (double, 15,2)—The angle of the vector from the referenced pointon the centerline to the offline point. The angle is measured from the upstreamvector of the centerline. Only used if the online point feature is acting as an onlinelocation for an offline point or offline linear feature.

BeginStation (double, 15, 2)—A station value (measure) along a station series usedto position and locate the point feature.




J-9137

January 2004 14

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

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

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

All other attributes in the Online Point conceptual feature class are optional and can bedeleted, added, or modified as required.

Online Linear Features Online linear features are stored in an M Aware (optionally Z Aware) polyline featureclass that is geometrically constrained and coincident with the centerline. Online linearfeatures 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 featureclasses must have the following attributes:

BeginStation (double, 15,2)—A station value (measure) along a station series used toposition 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 toposition and locate the end of the linear feature.


All other attributes in the Online Linear conceptual feature class are optional and can bedeleted, added, or modified as required.

Offline Point Features Offline point features are stored in an M Aware (optionally Z Aware) point feature classthat is located off the centerline. Offline features may be referenced against a location onthe 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 conceptualfeature 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 andthus have one or more online point location features as referenced locations. Onlinelinear features must have the following attribute:


All other attributes in the Online Linear conceptual feature class are optional and can bedeleted, added, or modified as required.




J-9137


Offline PolygonFeatures

Offline Polygon features are stored in a polygon feature class. Offline polygons representfeatures that are not located by stationing or linear referencing. The centerline may passthrough or by an offline polygon. It is optional to store an online linear featureas an online location for an offline polygon where the linear feature represents theintersection and overlap of the centerline by the polygon.

Topology The APDM is designed to incorporate topology rather than the geometric network as amechanism 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 thatparticipate with the topology be present in the same feature data set. The centerlinefeature classes—Control Points and Station Series—are the core of the topology.Therefore, all referencing feature classes must participate in the topology as well. TheAPDM stores all feature classes in the model in the Transmission feature data set.

Centerline This section outlines some of the rules or assumptions about the APDMcenterline features.

Control points represent the vertices of station series linear features.

Control points and the vertices of station series features share the same measurevalues (if the control point and the station series features share the same subtypevalue).

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 controlpoints 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 avalid station value.

Station series of subtypes other than the default subtype only need control points atthe 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 stationseries 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 samesubtype but different StationSeriesEventID.




J-9137

January 2004 16

Stationing must increase or decrease in value from one end of a station series to theother 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 thestation series feature on which they are located.

APDM Geodatabase The following subsections describe the content of the APDM including descriptions of structure, domains, inheritance, abstract classes, object classes, and feature classes.

Structure 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 themost effective method for managing data integrity and consistency. If topology isimplemented for the APDM, then all feature classes that will participate in the topologymust be stored in the same feature data set. At present, all core and suggested featureclasses are located in the Transmission feature data set.

Domains The domains that are provided with the model are designed to contain common valuesfound in most pipeline systems. The purpose of these domains is to provide commonvalues that are representative of the attributes they are populating. The provided domainvalues 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 denotesthe organizational category to which the domain belongs: gn (generic—domains thatcould be applied to object classes and many different feature classes across the model),

cp (cathodic protection domains), op (domains applied to feature classes pertaining topipeline operations), en (domains applied to feature classes pertaining to feature classesmodeling encroachments to the pipeline), fc (domains applied to facility feature classes),cl (domains applied to centerline feature and object classes), and in (domains applied toinspection feature classes).

Inheritance The APDM is depicted in a Universal Modeling Language (UML) diagram contained in aVisio 2002 drawing file. UML provides a mechanism for modeling the objects, classes,relationships, domains, and subtypes of a geodatabase in a diagram. The UML diagramscontaining the depiction of the APDM are called static structure diagrams. Staticstructure diagrams are particularly useful for documenting the relationships betweenvarious objects in the geodatabase, especially the concept of inheritance. Inheritance isdefined in object-oriented terminology as "the facility by which child objects may use amethod 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 asabstract classes, particularly in static structure diagrams specifically built for ESRIgeodatabases. 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 specializedversions of the parent inherit the methods and attributes and add to them as required.Depicting ESRI geodatabases in static structure UML diagrams relies heavily oninheritance to pass attributes from parents to children objects; the APDM is no exceptionto this.




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 theconceptual diagrams and object descriptions will differ somewhat from the way thoseobjects are depicted in the UML diagrams. This incongruity is a limitation of UML andthe inherent nature of relationships within the geodatabase. The prime example of thisbehavior is the attribute EventID, which should be located in the abstract class Auditingin the UML model. However, since EventID is used for relationships between object andfeature classes, it must be present as an attribute of the actual class rather than beinginherited from an abstract class, or an error will occur in the UML model. In theconceptual and logical diagrams of the APDM, the attribute EventID will appear as partof the parental abstract classes. In the static structure UML diagram that is used togenerate the geodatabase schema, EventID will be located in the bottom-most childfeature and object classes. This point is only being made to alleviate any confusion thatmight 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 FeatureAuditing Feature Point Fitting Online Point Feature ClassObject FeatureAuditing Feature Polyline Online Polyline Feature ClassObject FeatureAuditing Feature Point Online Point Feature ClassObject FeatureAuditing Feature (Offline) Feature ClassObject Auditing Object Class

Object The Object class is the highest object in the hierarchy of inheritance. A standard ESRIobject provides an ObjectID (OID, long integer attribute). ObjectID is the internal,ArcSDE software-assigned unique identifier/primary key for the feature or object classinheriting from Object.

Auditing 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 asphysical classes in the generated geodatabase schema. However, all the attributes of these classes are passed on to any child objects underneath them in the inheritancehierarchy. 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 thepipeline

GroupEventID (long integer)—Used to aggregate or generalize two or more featurestogether

OriginEventID (long integer)—The EventID of a parent object2

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




J-9137

January 2004 18

ProcessFlag (string, 10) – A catch-all field for application developers used fortemporarily storing values, tags, and codes required for application processing. Thefield is not meant to store information on a permanent basis and should be clearedafter 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 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).

Point The Point abstract class is an APDM class. The Point abstract class contains the singleattribute SymbolRotation (double, 15,2), which is used to store a value from 0–360 (theangle rotation of the symbol for a point feature class inheriting this object).

Fitting The Fitting abstract class is an APDM object and is used to group a set of attributes formanufactured 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 onthe centerline at a stationed position using the default measurement type.

StationSeriesEventID (long integer)—Foreign key to station series feature this pointis located on




J-9137


BeginStation (double, 15,2)—Measure or station value at which the point feature islocated along a Station Series feature (or route)

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

OffsetDistance (double, 15,2)—(optional) The distance of the point feature from apoint referenced on the centerline. Only used if the online point feature is acting asan online location for an offline point or offline linear feature.

OffsetAngle (double, 15,2)—The angle of the vector from the referenced point onthe centerline to the offline point. The angle is measured from the upstream vectorof the centerline. Only used if the online point feature is acting as an online locationfor an offline point or offline l inear feature.

Online Polyline This APDM object contains the Route-ID and Measure values for locating the end of alinear feature on the centerline. The begin Route-ID and Measure values are inheritedfrom 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 endson 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 mustbe located in each individual feature and object class since it is used as a primary key andforeign key in every ESRI relationship class that is used in the APDM. The currentimplementation of the APDM calls for EventID to store a GUID as a 38 character string.

Object and FeatureClasses

The following subsections describe the core and proposed feature/object classes in themodel. The object and feature classes presented in this section comprise both core andsuggested elements of the APDM. Core elements are denoted with Core. Suggestedelements (object/feature classes) are described normally. Each feature/object class isdescribed 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, adescription of the relationships between the class and any other classes in the model, adescription of class subtypes, and a description of the attributes describing the class. Anyattributes inherited from any of the parent objects are not included in the specific classdescriptions listed below.

Object Classes

Activity (Object Class) The rows in the Activity object class store information pertaining to activities that areconducted on the pipeline that affect one or more events or features on or along thepipeline. 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 thatone activity can have one or more events (of different types) that were affected by orparticipated in the activity. Activity has a many-to-many relationship withExternalDocuments, whereas many documents might provide source material to theactivity. Activity has a one-to-many relationship with InspectionRange indicating that a




J-9137

January 2004 20

given activity could occur over many linear areas of the pipeline. The Activity objectclass also has an attribute named ActivityParentEventID that can be used as a self-relatefield to group a set of activities underneath a parent activity. The Activity object class isdesigned to be implemented in systems in which it is important to track regular pipelineactivities 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 toestablish a hierarchy of activities

EventID (string, 38)—Globally unique identifier

<classname>ActivityEvent (Object Class)

The <classname>ActivityEvent object class - provides a table for storing historicalcomments about a feature including an optional relationship between a feature and anActivity. A <classname>Activity table can be created for any other feature class orobject class within the geodatabase. The premise is that a given feature <a> will haveone-or-more <a>ActivityEvents such as comments, field notes, and/or activities. Therelationship from Activity to <classname>ActivityEvent is a one-to-many relationshipand is optional. An optional one-to-many relationship from <classname>ActivityEvent toExternalDocuments may also exist.

<ClassName>EventID (srting, 38)—Foreign key to a given feature/object classspecified by <classname>

ActivityEventID (string, 38)—(optional) Foreign key to Activity object class

Remarks (string)—May contain historical notes, comments, inspection results, andother 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 addressinformation pertains to encroaching structures, company addresses, and individualmailing addresses. The Address object class is related to the Contact and Companyobject classes using many-to-many relationship classes named ContactAddress andCompanyAddress respectively. The Address object class is also related to the Structureand RightOfWay feature classes via many-to-many relationship classes. The Addressobject class was designed to maintain a list of commonly required addresses pertaining togeographic and organizational features in the model that might be contacted via surfacemailing.

Note: The Address object class can be supplanted by a separate customer/contactinformation system (CIS) database.

City (string)—City name

County (string)—County name

Country (string)—Country name




J-9137



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 allmeasurement systems for Online Point and Online Polyline feature classes. The Stationattribute in Online Point feature classes, and the BeginStation and EndStation attributesin Online Polyline feature classes, store stationing values for the primary measurement

system only. AltRefMeasure provides a means for storing stationing values foralternative measurement systems, as well as for the primary measurement system.

Online Polyline features must be split into multiple features if they cross one or morestation equations (two or more Station Series features). The GroupEventID attribute canbe used to aggregate the split features. AltRefMeasure can be used to store the begin andend station values for the aggregate feature, if desired. In this case, one row inAltRefMeasure is related many features.

AltRefMeasure is subtyped in the same fashion as ControlPoint and StationSeries; eachsubtype denotes a different measurement system. AltRefMeasure is related to eachOnline Point and Online Polyline feature class via a many-to-many relationship class.AltRefMeasure inherits from the Audit abstract class and contains the followingadditional attributes:


StationSeriesEventID (string, 38)—The foreign key to the Station Series featureassociated with the begin station value.

BeginStation (double, 15, 2)—The station value for the beginning of an OnlinePolyline feature, or the station value of an Online Point feature.

EndStation (double, 15, 2)—The station value for the end of an Online Polylinefeature. For Online Point features, the value for this attribute is the same as that forBeginStation.

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 OnlinePolyline feature. For split Online Polyline features, the aggregate length.

Company (ObjectClass)

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 onor along the pipeline system. The Company object class has many-to-many




J-9137

January 2004 22

relationship classes with the Address and Contact object classes. These relationshipsreflect that many people work for many companies, and many companies can have manyaddresses. The Company object class also has a many-to-many relationship with theLineCrossing feature class reflecting ownership of the line. The Company object classhas a one-to-many relationship with the OwnerOperatorShip object class reflecting thepercentage ownership of the actual line loops of a pipeline system.

Note: The Company Object Class can be supplanted by a separate customer/CISdatabase.

CompanyLabel (string)—Additional label, acronym, or designation used for thecompany

CompanyName (string)—Company name

CompanyType (string)—Describes the services the company provides (pipeline,contractors, etc.)


Contact (Object Class) The Contact object class contains the contact information for communicating with anyperson who has contact with or works for a pipeline company and its contractors.Examples of contacts include right-of-way property owners, structure owners, cathodicprotection inspectors, emergency contacts, contractors, and company employees(managers, field crews, GIS operators, etc.). The Contact object class has many-to-manyrelationships with the Reading and Company object classes and with theInspectionRange, LineCrossing, OperatingPressure and RightOfWay, and Structurefeature classes. These relationships model the person conducting a reading at a facilityfeature, inspection, or pressure test. The relationships between Contact and

LineCrossing, RightOfWay, and Structure reflect ownership or primary contactinformation.

Note: The Company object class can be supplanted by a separate customer/CIS database.

CompanyEventID (long integer)—Foreign key relationship to the company thecontact works for

ContactType (domain)—Brief job description/organizational position of contactperson

Email (string)—E-mail address


Fax (string)—Fax number

FirstName (string)—First name

LastName (string)—Last name

Mobile (string)—Mobile/Cell phone number




J-9137


Pager (string)—Pager phone number

Phone (string)—Phone number

ExternalDocument(Object Class)

The ExternalDocument object class stores information describing the location andcontent of a file object stored on an external disk drive. The purpose of theExternalDocument object class is to link features and events with external documentationusing a similar method as the ArcMap Hyperlink tool but storing the information withinthe underlying database table so that external applications might be able to access theinformation. Using this design, multiple documents can be related to multiple features.The ExternalDocument object class has a one-to-many relationship with theGeoMetaData object class, which models the fact that external documents containmetadata pertaining to the origin/provenance of features described in the GeoMetaDataobject class. The ExternalDocument object class has a many-to-many relationship withthe DocumentPoint feature class, allowing one point feature to display one or more

documents that might describe additional point features or other locations. (SeeDocumentPoint feature class description.) ExternalDocument has a many-to-manyrelationship with Activity indicating that many documents provide information aboutmany specific activities. The same kind of relationship exists betweenExternalDocument and <classname>ActivityEvents object classes.

DocumentType (domain)—Describes type of external document (e.g., CADdrawing, document, map)


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 (ObjectClass)

The GeoMetaData object class describes the geographic provenance of point features inthe model, namely ControlPoint and FieldNote whose geographic coordinates areabsolute and known. The GeoMetaData allows the database to store highly accuratecoordinate information derived from the field for points whose current position has beendegraded to suit a projection/precision limitation or has been moved to conflate thecurrent feature to an existing background or control layer (e.g., land base ororthophotography). The GeoMetaData object class is used to maintain a historic tie tothe original geographic location of these features in the event that this information isrequired for more accurate or detailed analysis. The GeoMetaData object class hasrelationships 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 conflatedto another position. A relationship is also created with ExternalDocument to record theprovenance 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 originalcoordinates were collected in




J-9137

January 2004 24


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

Instrument Parameter(Object Class)

The InstrumentParameter object class stores information about Instruments. A singleinstrument 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 forInstrumentParameter 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 Instrumentrecord. InstrumentParameter contains the following attributes:


InstrumentEventID (string, 38)—Foreign key to the parent Instrument feature

SubTypeCD (long integer)—Defines the instrument subtype (must match thesubtype 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 storedas string)

LineLoop (ObjectClass, Core)

The LineLoop object class is designed to store the information describing pipelines andline loops used to classify pipes into continuous or logical groupings. Most pipelinecompanies group continuous sections of pipes with common diameters and otherattributes that stretch for tens, hundreds, or thousands of miles as a single line or linenumber. Each station series feature may belong to one or more LineLoop objects. Asingle line loop may be the parent to one or more children line loops. The LineLoopobject class has many-to-many relationships with the StationSeries feature class and theSubSystem and OwnerOperatorShip object classes. The relationship between LineLoopand SubSystem provides a mechanism where parts of LineLoops can be broken down or

classified as belonging within different subsystems, areas, or districts. The relationshipbetween LineLoop and OwnerOperatorShip models the percentage owner/operatorship of each LineLoop in the pipeline system. The relationship to StationSeries indicates thatmany station series can belong to one or more line loops. LineLoop has a one-to-manyrelationship with LineLoopHierarchy, which models a hierarchy between parent andchildren LineLoops. A relationship exists between LineLoop and RightOfWay, whichmodels that each RightOfWay linear feature falls on one and only one LineLoop and isused as a source of identification.




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 childLineLoops and is used to establish hierarchy of LineLoops. The LineLoop hierarchygroups LineLoops as sets of LineLoops belonging to higher sets of LineLoops. AllLineLoops 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-onerelationships with the LineLoop object class.


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/oroperatorship for a LineLoop. The OwnerOperatorShip object class has a many-to-manyrelationship with LineLoop reflecting that many owners/operators can own/operate manyLineLoops. The OwnerOperatorShip object class has a many-to-one relationship with theCompany 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 (0–100%) 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 typicallyfluctuating 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 relationshipsmodel that at any of these features zero or more readings may be taken over time. Therelationships that the cathodic protection feature classes reflect are continuous corrosioncontrol efforts. The readings taken at valves, meters, and pipe segments model flowconditions typically recorded for SCADA systems. The Reading object class has a many-to-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




J-9137

January 2004 26

object class provide an example of three typical readings taken at features along apipeline system: SCADA, Corrosion, and Close Interval Survey.


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 (subtype—long integer)—The subtype of the reading

SubSystem (ObjectClass)

The SubSystem object class is used to categorize, organize, and group LineLoop recordsinto 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 LineLoopmodeling, and many LineLoop features can belong to many different nonexclusive, oftenoverlapping, systems or districts. The subsystem object class also has two many-to-onerelationships with the SubSystemHierarchy object class modeling in that SubSystems canbe ordered into hierarchical groupings within the SubSystem object class. It is possiblefor a relationship to exist between a polygon feature class and the SubSystem objectclass. Each polygon would represent the spatial extent of a SubSystem. It is also possibleto store the actual polygon geometry with the SubSystem record itself – converting theSubSystem from an object class to a feature class.


SubSystemName (string)—The name or label that identifies the subsystem

SubSystemHierarchy(Object Class)

The SubSystemHierarchy object class models the hierarchy between different subsystemfeatures in the model. It is common to have organizational groupings or areas containsubareas that, in turn, could contain other subareas. The SubSystemHierarchy objectclass has two one-to-many relationships with the SubSystem object class modeling parentto child relationships between subsystem objects.

EventID (string, 38)—Globally unique identifierParentSubSystemEventID (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 printablegeographic map portion of an alignment sheet generated along a reach or section of thepipeline system. The attributes of the AlignmentSheet feature class were purposefullydesigned to store only generic information due to the high variance of alignment sheet




J-9137


requirements between different pipeline companies. Only the broadest attributes thatdescribe alignment sheets in the most generic terms were included in the model.


SheetName (string)—An organizational name or code that identifies the alignmentsheet

SheetNumber (string)—An organizational name, code, or alias that identifies thealignment sheet

SheetType (domain)—The type of alignment sheet (e.g., engineering, newconstruction)

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 includecorrosion, geometric distortions, and/or material defects such as gouges or dents. TheAnomaly feature class participates in a many-to-one relationship with theAnomalyCluster feature class. This relationship models that each anomaly point could bea member of a cluster of like anomalies.

The Anomaly feature class is subtyped into four generic types of anomalies: externalcorrosion, internal corrosion, gouges, and dents. These subtypes are considered to beexamples of a range of possible anomaly types. Typically, anomalies are classifiedaccording to what kind of inline PIG inspection is conducted on the pipe segments of apipeline system. The Anomaly feature class has a many-to-many relationship with theInspectionRange feature class. This relationship models the fact that an anomaly locationcan be determined by many different inspections.

AnomalyClusterEventID (string, 38)—Foreign key relationship with cluster theanomaly is part of

BPRCalculated (double, 15,2)—Calculated burst pressure ratio

BPRPig (double, 15,2)—Burst pressure ratio recorded based on values retrieved byan 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


InspectionRangeEventID (string, 38)—Foreign key to the inspection range used tolocate the anomaly

Length (double, 15,2)—The length of the anomaly

MaximumDiameter (double, 15,2)—The maximum diameter of the pipe segment atthe anomaly




J-9137

January 2004 28

MinimumDiameter (double, 15,2)—The minimum diameter of the pipe segment atthe 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 eachfeature

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 anomalypoint features. One feature in the AnomalyCluster feature class represents a set of anomalies stored as a multipoint shape. The purpose behind the AnomalyCluster featureclass is to allow analysis of clustered anomalies, of similar types, which were discoveredduring 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 pressureratio

AveBPRVariance (double, 15,2)—Calculated average variance between calculatedand 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 maximumdiameter

AveMinimumDiameter (double, 15,2)—Calculated average anomaly minimumdiameter




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

AveRPRPig (double, 15,2)—Calculated average recorded anomaly rupture pressureratio

AveRPRVariance (double, 15,2)—Calculated average variance between calculatedand recorded anomaly burst pressure ratios

AveWidth (double, 15,2)—Calculated average anomaly width


Appurtenance (OnlinePoint Feature Class)

The Appurtenance feature class is used to store ad hoc, nonpressurized point features thatare found on and along a pipeline system. The Appurtenance feature class can be used asa catchall for referenced online point features that do not fit into any other APDMfeature class and for which a minimum common set of attributes must be recorded.Typical appurtenances include anchor rods, hold-down blocks, river weights, and thrustblocks.

AppurtenanceType (domain)—The appurtenance type (e.g., anchor rod, riverweight)


InServiceDate (date)—The date the appurtenance was placed in service


CPAnode (OfflinePoint Feature Class)

The CPAnode feature class stores sacrificial anodes. Anodes receive electrical currentand are sacrificed to reduce the probability of pipeline corrosion. The weight of theanode and the size of the pipeline are factors determining how anodes are placed andmanaged along a pipeline. The CPAnode feature class has a many-to-one relationshipwith CPGroundBed modeling the fact that one or more anodes are located within a singleground bed. CPAnode feature class has a many-to-many relationship with theCPOnlineLocation feature class showing that each anode may have one or more onlinelocations.

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 fieldof the GroundBed feature class




J-9137

January 2004 30


InServiceDate (date)—The date anode was placed into service


CPBond (Offline PointFeature Class)

The CPBond feature class stores information describing cathodic protection bonds thatlink one or more bond wires together. Bonds are often placed where nonmetallic fittingsor valves join pipe segments together as a means of carrying over (or stopping) electriccurrent from one set of pipes to another. CPBond feature class has a many-to-manyrelationship with the CPOnlineLocation feature class showing that each bond may haveone 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


InServiceDate (date)—The date the bond was placed into service


CPCable (OfflinePolyline Feature Class)

The CPCable feature class stores information about the cathodic protection cables thatcarry current to/from different cathodic protection devices and the pipe segments of thepipeline. CPCables provide a physical connection between cathodic protection pointfeatures and pipe segment features. CPCable has a many-to-many relationship with

CPOnlineLocation indicating that each cable may have one or more online pointlocations.

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)


InServiceDate (date)—The date the cable was put in service

NumberOfCables (domain)—The number of cables in the CPCable feature (1–4)

CPGroundBed (OfflinePoint Feature Class)

The CPGroundBed feature class is the location on or off the centerline where one or moreanodes are placed. Anodes within a ground bed are used to reduce corrosion caused bythe flow of direct current from one part of the metal pipeline to another. TheCPGroundBed feature class has a one-to-many relationship with the CPAnode feature




J-9137


class. The CPGroundBed feature class has a many-to-one relationship with theCPRectifier feature class. These relationships model the configuration that typically oneCPRectifier feature will have one or more CPGroundBeds, each containing one or moreCPAnodes. The CPGroundBed feature also maintains a NumberOfAnodes attribute thatmay be used in lieu of its association to CPAnode. CPGroundBed also has a one-to-many relationship with the Reading object class in which each CPGroundBed can haveone or more readings over time. CPGroundBed feature class has a many-to-manyrelationship with the CPOnlineLocation feature class showing that each ground bed mayhave one or more online locations.

AnodeSpacing (domain)—The measured spacing between each anode in the groundbed

BackfillMaterial (domain)—The ground material used to backfill the ground bed

CPRectifierEventID (string, 38)—A foreign key relationship with the EventID of therelated CPRectifier


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 (OfflinePoint Feature Class)

The CPRectifier feature class stores information about a rectifier. A rectifier is acathodic protection device that manages the power conversion from AC (alternatingcurrent) to DC (direct current) before it is passed on to a pipeline. A CPCable feature canbe used to provide connectivity between a rectifier and a pipe segment. The CPRectifierfeature class has a one-to-many relationship with the CPGroundBed feature class. Thisrelationship models that zero or more ground beds serve one rectifier. CPRectifierfeature class has a many-to-many relationship with the CPOnlineLocation feature classshowing that each rectifier may have one or more online locations.


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 (1–4)

NumberOfAnodes (integer)—The number of anodes serving the rectifier




J-9137

January 2004 32

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., siliconbridge, silicon diode)

ReplaceByDate (date)—The date by which the rectifier must be replaced


CPTestStation (OfflinePoint Feature Class)

The CPTestStation feature class stores the information describing a cathodic protectiontest station. Test stations are located at strategic points along a pipeline and are used totake readings and measurements of the cathodic protection system. The CPTestStationfeature class has a one-to-many relationship with the Reading object class. Thisrelationship models that many readings are taken for a particular test station over time.CPTestStation feature class has a many-to-many relationship with the CPOnlineLocationfeature class showing that each test station may have one or more online locations.


InServiceDate (date)—Date the test station was put in service

TestStationType (domain)—The type of test station (e.g., anode, single wire,bonded)


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 featureclass has a many-to-many relationship from those five feature classes, allowing acommon location table for all corrosion features. CPOnlineLocations are calculated foreach 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.


LinkedFeatureEventID (string, 38) – The identifier for the feature that the onlinepoint location is representing. The class containing the feature is indicated by theSubTypeCD description value for the class.

OffsetDistance (double, 15,2)—(optional) The distance from the online location tothe offline point feature




J-9137


OffsetAngle (double, 15,2)—The angle of the vector from the online location to theoffline point feature (angle measured from upstream centerline direction)

SubTypeCD (long integer)— Indicates the class for which the online point locationis calculated for.


Casing (Online PolylineFeature Class)

The Casing feature class represents a protective structural device surrounding a pipesegment. Casings are used to protect pipelines from the weight, pressure, and vibrationcaused 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)


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 PointFeature Class, Fitting)

The Closure feature class represents the terminus or endpoint of a pipeline. A closure isdesigned to interrupt (and typically contain) pressurized flow at the end of a pipesegment. Closure inherits attributes from the Fitting Abstract Class.

ClosureType (domain)—The type of closure (e.g., blind flange, hinged, plug)


Coating (OnlinePolyline Feature Class)

The Coating feature class represents the materials that are spread over a set of pipesegments and fittings to preserve the metal from corrosion and exposure to environmentalconditions. Coating can be applied to the internal and/or external surfaces of pipesegments. It is also common for coating features to overlap other coating features. A




J-9137

January 2004 34

pipe segment can potentially have zero or more internal and zero or more externalapplications 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)


InServiceDate (date)—The date the coating was put into service

InternalCoating (domain)—Indicates if coating was applied to inside of pipe(Yes/No)

ControlPoint (PointFeatureClass, Core)

The ControlPoint feature class contains points of known x,y position and known stationvalue (measure) along a pipeline. Each control point feature is also a point representationof 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 astation 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. Thisrelationship models the provenance of the control point feature. GeoMetaData storesoriginal coordinate information and metadata describing how the control point featurewas initially obtained in the field. The ControlPoint feature class has a many-to-onerelationship with the StationSeries feature class. This relationship models the fact thateach station series feature is composed of two or more control point features and thateach control point is a vertex (including endpoints) of the station series feature.

The subtypes of the ControlPoint feature class represent different types of linearreferencing measurement systems that are used for stationing along a pipeline. TheAPDM 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 methodbecome, in effect, the centerline for the pipeline system in the APDM. Other controlpoint subtypes, or measurement systems, present in the model are considered secondarymeasurement systems. All secondary measurement systems must be geometricallycoincident and geometrically constrained to the primary measurement system controlpoints and station series features. Station series features used to demarcate secondarymeasurement systems are only required to have control points located at the start and endpoints of the station series feature. A typical primary measurement system is Horizontal




J-9137


Slack Chain. The Continuous and Unspecified measurement systems are also coreelements 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)


PIDirection (long integer)—The direction of the horizontal at the control point fromthe 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 stationseries at the control point location

StationSeriesEventID (string, 38)—Foreign key relationship with StationSeriesEventID

SubTypeCD (long integer)—The subtype (measurement system) of the control point


DocumentPoint(Offline Point Feature

Class)

The DocumentPoint feature class contains points that are used to link to one or moreexternal 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 asite 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 referto documents pertaining to specific points within the site area polygon. TheDocumentPoint feature class has a many-to-many relationship with theExternalDocument object class. This relationship models that many document pointfeatures can display the same external document and that many external documents canbe displayed by one or more document points.

DPName (string)—A name, alias, or other identifier for the document point



Elbow (Online PointFeature Class, Fitting)

The Elbow feature class describes manufactured elbow fittings. An elbow featuretypically represents a bend in the pipeline at a specific angle. An elbow is typicallymanufactured in angle increments of 15 degrees. Elbow features are designed to carrypressurized product.

ElbowAngle (double, 15,2)—The angle the elbow bends the pipeline (e.g., 30°, 45°)




J-9137

January 2004 36

ElbowRadius (double, 15,2)—The radius of the elbow from one endpoint of theelbow to the other endpoint


ElevationPoint (OnlinePoint Feature Class)

The ElevationPoint feature class is designed to store elevations taken at specific pointsalong the pipeline centerline. Anytime that a section of pipe is excavated (or initiallyplaced in the ground) the depths of the pipeline features from the ground surface arerecorded. The ElevationPoint feature class is also useful for storing the depth of offshorefeatures that are under water.


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


WaterElevation (double, 15, 2)—Depth of a pipeline feature below water surface

FieldNote (OfflinePoint Feature Class)

The FieldNote feature class is designed to store data collected during preliminary routingof pipeline, engineering, environmental, or cultural field surveys. Field notes serve asplaceholders for information pertaining to proposed features or survey notes. Field notesalso serve as memos or notations that provide additional comments, descriptions, orannotation 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. TheGeoMetaData for a field note stores the provenance of the field note's original positionand 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.


FieldNoteType (domain)—The type of field note (e.g., structure location, routingangle) 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 (OnlinePolyline Feature Class)

The HCAClass feature class (or High Consequence Area Class) denotes the Departmentof 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 othersignificant high consequence areas that encroach into the boundary of the DOT Class




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


HighConsequenceArea(Offline Polygon

Feature Class)

The HighConsequenceArea feature class denotes the boundary of high consequence areasthat encroach upon the DOT Class Corridor of the pipeline center and effectively drive upthe HCA class rating of segments of the pipeline. High consequence areas are navigable

waterways, ecological reserves, drinking water recharge zones, and densely populatedareas.

AreaType (domain)—The type of area (e.g., navigable waterway, populated area)

ClassArea (domain)—The automatic rating assigned to the reach of pipeline that thisarea affects


InspectionRange(Online PolyLine

Feature Class)

The InspectionRange feature class represents the length or range of an inline PIG run, thelinear extents of an Activity or another type of inspection along a pipeline. Currentlythere is no published standard format for most of this data. Most of the data returnedfrom 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 amechanism to relate this information to a geometric feature in the geodatabase. TheInspectionRange feature class has many-to-many relationships with the Anomaly featureclass and the Contact object class. These relationships model the occurrence of manydiscovered anomalies for an inline run and list a contact person for the contractor whoconducted the inline run. Inspection Range also has a many-to-many relationship withActivity (many linear ranges represent the spatial extent of one or more recurringactivities).

InspectionRange models other types of inspections that span a reach of the pipeline; theseare modeled as subtypes and include smart PIG runs, cleaning PIG runs, geometry PIGruns, leak surveys, close interval surveys, visual surveys, aerial surveys, and excavations.


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.




J-9137

January 2004 38

Instrument

(Online Point FeatureClass)

The Instrument feature class stores information about facilities and equipment typicallyfound on a Process and Instrumentation Diagram (P&ID). Examples of these types of equipment include pressure and temperature sensors, pressure and temperaturetransmitters, pressure regulators, level indicators, level controllers, valve positionindicators, valve positioners, gas samplers, gas chromatographs, flow computers, E/Rprobes, etc. The instrument feature class is subtyped by instrument type, so newinstrument 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 orpump station. For this reason, not all records in the Instrument feature class will have ashape, a Station value and a StationSeriesEventID value. Instrument maintains a many-to-one relationship with SiteBoundary, so Instrument features not related to a StationSeries may still be related to a Site Boundary (compressor, valve, or pumping station). Inaddition, 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-to-one. 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 theInstrumentParameter object class (table). The InstrumentParameter table storeinformation about instruments.

Instrument inherits from the FeatureAudit abstract class and contains the followingadditional attributes:


SubTypeCD (long integer)—The instrument subtype (e.g., Pressure Switch, SolarPanel, 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 instrumenttype)

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&IDdiagram (the reference to the actual diagram can be stored in the ExternalDocumenttable)

LinkedFeatureEventID (string, 38)—Foreign key to a record in Tap, Tee, Meter orVessel




J-9137


SiteBoundaryEventID (string, 38)—Foreign key to a record in SiteBoundary

Leak (Online PointFeature Class)

The Leak feature class stores information about leaks, ruptures, and unexpecteddeliveries 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


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, thirdparty)

RepairType (domain)—Type of repair (permanent or temporary)


LineCrossing (OfflinePolyline 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 safetyregulations. The LineCrossing feature class has no inherent referential position but relieson the LineCrossingLocation (online point) and LineCrossingEasement (online polyline)to store referenced location information about the line crossing. The LineCrossingfeature class has a one-to-many relationship with LineCrossingLocation andLineCrossingEasement feature classes. The LineCrossing feature class also has many-to-many relationships with the Contact and Company object classes. These relationshipsmodel the line crossing owner/operator and first contact information for the line crossing.The LineCrossing feature class has the following subtypes: geographic (navigablewaterways, drainage, hydrology), cultural/transportation (roads, fences, politicalboundaries), and utility (foreign pipelines, electric wires).

Clearance (double, 15,2)—The distance of the line crossing above or below thepipeline at the point of crossing

CrossingType (domain)—The type of line crossing based on the line crossingsubtype (e.g., road, river)

EasementWidth (double, 15,2)—The total easement width where the LineCrossingintersects the centerline





J-9137

January 2004 40

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 pipelinecenterline, or do so only sporadically. In the situation where digitization of crossingfeatures 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 toimplement LineCrossing as an object class (table), rather than as a feature class.

LineCrossingEasement(Online PolylineFeature Class)

The LineCrossingEasement feature class stores the online location of the easement toeither side of a LineCrossing feature when it intersects the centerline. A LineCrossingfeature may contain one or more easements.


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 LineCrossingfeature intersects the centerline. Each LineCrossing feature may have zero or moreLineCrossingLocations.


LineCrossingEventID (string, 38)—The foreign key relationship to the LineCrossingfeature

Orientation (domain)—The orientation of the line crossing compared to the pipeline


Marker (Offline PointFeature Class)

The Marker feature class stores information about monuments, aerial markers, mileposts,and other offline features that determine position along a pipeline. Marker features arenot control points since they do not explicitly mark the route of a centerline. Markers areplaced at regular intervals or at points of known locations along the pipeline and serve asreference points. Markers may serve as calibration points for station series features foralternate measurement systems. The Marker feature class has the following subtypes:milepost, aerial marker, monument, survey point, and PIG signal (above ground marker).


InServiceDate (date)—Date marker put into service

MarkerNumber (string)—An organizational name, code, or number identifying themarker

SubTypeCD (long integer)—The marker subtypes





J-9137


Meter (Online PointFeature Class, Fitting)

The Meter feature class contains information describing manufactured, pressurizedfittings that are used to monitor flow, pressure, and composition of product as it istransported along a pipeline. The Meter feature class inherits additional attributes fromthe Fitting abstract class.


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, positivedisplacement)

RemoteNetworked (domain)—Indicates if the meter can be operated via remotenetwork (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 notreferenced along the pipeline centerline. Nonstationed pipe can be the internal workingsof a compressor station that is located along the pipeline, or it can be feeder lines betweenmain lines, meters, or wells and pumps. Nonstationed pipes might also be used asinvisible connectors to maintain connectivity within a network of mainline pipes foranalytical purposes.

Diameter (domain)—The outside diameter of the pipe


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 sharingcommon attribute values. When lengthy linear features span station series, these featuresmust be segmented into lengths no longer than the underlying station series features. TheGroupEventID attribute inherited from the Audit abstract class can be used to aggregatemany separate operating pressure features, with equal attributes, into a single groupedelement. The OperatingPressure feature class has a many-to-many relationship with the




J-9137

January 2004 42

Contact object class. This relationship establishes the person responsible for verifyingthe attributes of an operating pressure feature.

ActualPressure (integer)—The recorded or established pressure for a reach along apipeline

AgreedToPressure (integer)—The agreed-to pressure between client and customerfor a reach of a pipeline

CalculatedPressure (integer)—The calculated pressure for a reach of pipeline basedon physical and operational characteristics of the pipeline


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 launchand receive inline inspection PIGs. Inline inspection PIGs are used to detect corrosionand geometric anomalies in a reach of pipeline using pressurized flow to propel the PIGthrough the pipe. Launchers and receivers are often fabricated in situ by a pipelinecompany. Some pipeline companies station or locate pigging structures via stationing;other companies consider these features to be non-referenced. The APDM does notmandate whether pigging structure features are to be referenced or not. Referencedpigging structure features can optionally be stored as a subtype of the PipeSegmentfeature 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 israted

BarrelWallThickness (domain)—The wall thickness of the structure barrel or pipe


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 thestructure

StructureLength (double, 15,2)—The actual length of the structure

PressureRating (domain)—The pressure rating of the structure




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 beexplicitly recorded. A pipe segment feature in a pipeline system is a generalized featurethat is composed of many pipes sharing the same attribute values. When attribute valueschange between pipe segments, then a pipe join method feature (typically a weld) isplaced in between the pipe segments. Other features that are used to link two connectedpipe segments can be stored in the PipeJoinMethod feature class. The PipeJoinMethodfeature class is divided into the following subtypes: weld, coupling, flange, screw, andelectro stop. These features share a common set of attributes and can be divided intoseparate feature classes as required. Some join method features are manufactured(flanges) and others are constructed or applied in the field (e.g., welds, couplings).


InServiceDate (date)—Date the join method was put into service

Insulated (domain)—Indicates if the join method is insulated (used to delineatecathodic projection zones) (Yes/No)

JoinType (domain)—Description of the join method type depending on the featuresubtype

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


PipeSegment (OnlinePolyline Feature

Class, Core)

The PipeSegment feature class is used to model the primary conduit of pressurizedproduct flow of a pipeline system: pipes. The typical size of a pipe used in transmissionpipelines is 40 feet. Pipe segment features aggregate many of these pipes into a singlefeature with common attribute values. Traditionally it is common implementationpractice 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 valuesbetween the pipes were equal. Where the attribute values changed from pipe segment topipe segment, a pipe join feature was placed. The PipeSegment feature class has thefollowing subtypes: pipe, bend, and transition. Pipes represent straight pipe features. Abend 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 aspecified distance. The PipeSegment feature class is considered a core element of theAPDM. The rationale for including PipeSegment as a core element is twofold: first, alltransmission pipeline systems model pipe segments at some level; second, transmissionpipeline 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. Whena pipe segment feature is altered, removed, or abandoned, then a cascade of data




J-9137

January 2004 44

maintenance must occur to maintain concurrency between the pipe segment feature andthe dependent features.

BendRadius (domain)—The radius from a centerpoint to the ends of the pipesegment

DateManufactured (date)—The date the pipe segment was originally manufactured


GirthWeld (domain)—The type of weld used to link the pipes that form the pipesegment

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 pipesthat 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 pipesegment were manufactured

MillTestPressure (long integer)—The recorded test pressure when the pipe wasmilled

OutsideDiameter (domain)—The diameter of the outer wall of the pipes that formthe 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




J-9137


PressureTest (Online

Polyline Feature Class)

The PressureTest feature class is designed to store features describing pressure testsconducted along parts of the pipeline. Pressure test features can potentially stretch overlong 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 seriesfeatures. The GroupEventID attribute inherited from the Audit abstract class can be usedto aggregate many separate pressure test features, with equal attributes, into a singlegrouped element.


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 orincreased by the reducer. Reducers are manufactured fittings designed to carrypressurized product. The Fitting abstract class contains attribute definitions for inletconnection type, diameter, and wall thickness. The Reducer feature class inherits fromthe 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


ReducerSize (domain)—The size of both input and output pipe diameters connectedto the reducer (e.g., 4x12, 6x8)

ReducerType (domain)—The type of reducer (e.g., concentric weld, full open,swage)




J-9137

January 2004 46

RemovedLine (Online


The RemovedLine feature class is a container for polyline features that belong to otherfeature classes in which features have been deleted, removed from the ground, orabandoned in place. Removed lines capture the stationing information that was last usedto locate the feature by linear referencing. The attribute names and values are appendedinto a single string separated by colons and semicolons respectively. These name/valuepairs are stored in the Attributes field. The projection information of the originalfeature's coordinates is also stored for each feature.

Attributes (string)—The concatenated name/value pairs of the removed featuresattributes


EventType (domain)—Original feature class name of the removed feature

ProjectionID (string)—The ESRI projection string unique identifier of the originalfeature

RemovedDate (date)—The data the original feature was deleted, removed, orabandoned

RemovedPoint(Online Point Feature

Class)

The RemovedPoint feature class is a container for point features that belong to otherfeature classes in which features have been deleted, removed from the ground, orabandoned in place. Removed points capture the stationing information that was lastused to locate the feature by linear referencing. The attribute names and values areappended into a single string separated by colons and semicolons respectively. Thesename/value pairs are stored in the Attributes field. The projection information of theoriginal feature's coordinates is also stored for each feature.

Attributes (string)—The concatenated name/value pairs of the removed features

attributes


EventType (domain)—Original feature class name of the removed feature

ProjectionID (string)—The ESRI projection string unique identifier of the originalfeature

RemovedDate (date)—The date the original feature was deleted, removed, orabandoned

RightOfWay (Online


The RightOfWay feature class stores information describing easements and right-of-wayinformation of the pipeline as it passes through polygonal boundaries such as property

parcels, operating districts, and municipal/political boundaries. Right-of-way polylinefeatures are used to indicate the starting position of the pipeline as it enters and exits anarea 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 modelownership and address information for the section of the pipeline that passes througheach right-of-way. The line loop relationship provides a mechanism for quickly relating




J-9137


the right-of-way to an element in the pipeline hierarchy. This relationship is particularlyuseful 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 theright-of-way feature


ParcelNumber (string)—Records the parcel identification number the right-of-wayfeature passes through and can be used to link the right-of-way to a propertyinformation system

ROWType (domain)—Describes the arrangement between the land owner and thepipeline (e.g., easement, fee, license).

TraverseLength (double, 15,2)—The measured length of the right-of-way feature.

RiskAnalysis (OnlinePolyline Feature Class)

The RiskAnalysis feature class stores polylines representing the results of a risk analysisalong a reach of the pipeline. Potential risk (probability of failure, rupture, or unplannedrelease) along the pipeline is calculated based on the structural ability of the pipeline tocarry product under pressure. Parameters used for risk analysis might include pipesegment wall thickness, anomaly frequency, soil and other environmental conditions, andcoating condition. Risk analysis also entails some quantification of the consequences of apipeline rupture on property, the environment, and human life. The RiskAnalysis featureclass was designed to be customizable and includes suggested attributes.

ConsequenceEconomic (double, 15,2)—An assigned/calculated economicconsequence rating

ConsequenceEnvironmental (double, 15,2)—An assigned/calculated loss-of-environmental consequence rating

ConsequenceLife (double, 15,2)—An assigned/calculated loss-of-life consequencerating

ConsequenceProperty (double, 15,2)—An assigned/calculated loss-of-propertyconsequence rating

ConsequenceThroughput (double, 15,2)—An assigned/calculated loss-of-throughputconsequence


POFConstruction (double, 15,2)—Probability of failure due to construction defects

POFInternalCorrosion (double, 15,2)—Probability of failure due to internalcorrosion

POFMaterials (double, 15,2)—Probability of failure due to material defects

POFOutsideForce (double, 15,2)—Probability of failure due to an outside force




J-9137

January 2004 48

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 (OfflinePolygon Feature Class)

The SiteBoundary feature class was designed to store the polygonal boundaries of thevarious stations and other property owned by a pipeline company. Site boundary featuresmight 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 todemarcate the limit of stationed pipes and nonstationed pipes. One site boundary featuremay 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.


SiteName (string)—The organizational site name

SiteType (domain)—The type of site contained within the boundary (e.g., meterstation, compressor station)

Sleeve (Online PolylineFeature Class)

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


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 (PolylineFeature Class, Core)

The StationSeries feature class is a polyline M Aware feature class used to store theroutes by which all referenced features in the APDM are located as events. Each stationseries 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) valueassigned to it. Point and linear events are located along the station series route byassigning the Route-ID and a measure value as attributes of the feature (begin and end




J-9137


measure values for linear events). Linear events must start and end on the same stationseries (route).

4

The APDM UML model has a relationship between each referenced feature class and theStationSeries feature class. It is optional whether these relationships remain explicit orimplicit. The StationSeries feature class also has a one-to-many relationship with theControlPoint feature class. These relationships model the fact that two or more controlpoints act as point representations of the vertices of the station series feature and that thecontrol 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 requiresthat one subtype be chosen as the primary stationing or referencing method (the defaultsubtype). Slack Chain stationing is typically the default stationing method in mostpipeline 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 eventfeatures that span the traditionally segmented smaller slack chain station series features.Unspecified measurement type allows some flexibility for importing control points thathave no assigned or calculated stationing that might be the case for preliminary pipelinerouting, new construction, or proposed pipeline reroutes.

By accommodating many different methods of stationing, the APDM remains veryflexible and open to the varying needs of many pipeline companies importing data fromother pipeline models. The position of events and features on or along the centerline canbe easily determined by matching the position of these features along station seriesstoring different station values. Core ESRI geodatabase tools allow for simplecomparison and calibration of different reference systems' station values. The primarystationing 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 stationseries feature.

EndStation (double, 15,2)—The station value assigned to the end of the station seriesfeature.


FromSeriesEventID (string, 38)—the EventID of the StationSeries feature connectedto 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 featuresfor 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.




J-9137

January 2004 50

SubTypeCD (long integer)—The subtype of the station series representing a uniqueform of linear referencing or stationing.

ToSeriesEventID (string, 38)—The EventID of the StationSeries feature connectedto the current down station feature.

Structure (Offline PointFeature Class)

The Structure feature class stores information pertaining to any structure located within660 feet of either side of the pipeline centerline (class corridor). The Federal Departmentof 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 formore 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


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 usagebased 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 thegeodatabase records

StructureLocation(Online Point Feature

Class)

The StructureLocation feature class contains the online point locations for a structure thatfalls within a certain distance (usually 660 or 1,000 feet) of the centerline. A many-to-one relationship exists between the StructureLocation feature class and the Structurefeature class. This relationship models that many online locations reference an offlinestructure on the centerline.

BeginOffsetDistance (double, 15,2)—(optional) The distance of the point featurefrom a point referenced on the centerline. Only used if the online point feature is




J-9137


acting as an online location for an offline point or offline linear feature. (Inheritedfrom OnlinePoint).

BeginOffsetAngle (double, 15,2)—The angle of the vector from the referenced pointon the centerline to the offline point. The angle is measured from the upstreamvector of the centerline. Only used if the online point feature is acting as an onlinelocation for an offline point or offline linear feature. (Inherited from OnlinePoint).

DimensionTie1 (string)—Notation describing location information of the structurecompared to the location of other known points.

DimensionTie2 (string)—Secondary notation describing location information of thestructure.


StructureEventID (long integer)—Foreign key relate to EventID attribute in theStructure feature class.

StructureOutline(Offline Polygon

Feature Class)

The StructureOutline feature class contains the polygon outlines of structures. A many-to-one relationship exists between the StructureOutline feature class and the Structurefeature class. This relationship models that many buildings are associated with a singlestructure point that is referenced by a point on the centerline.

StructureEventID (long integer)—Foreign key relate to EventID attribute in theStructure feature class


Tap (Online PointFeature Class)

The Tap feature class stores information describing both manufactured tap fittings andtap fabrication (hot taps) located on a pipeline system. The APDM considers a tap to bethe joining of two or more pipes at a junction for the purpose of releasing product in acontrolled fashion. A tap is usually found in conjunction with a shutoff, check, or releasevalve.

5The Tap feature class has the following subtypes: tap fitting and tap fabrication.

BranchConnectionType (domain)—Description of a reinforcing structure around thetap (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)


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




J-9137

January 2004 52

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


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, thread-o-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 PointFeature Class, Fitting)

The Tee feature class contains information describing manufactured branch or tee fittingsdesigned 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 Teefeature class contains the following subtypes: full on tee, tapping tee, split tee, and wideopen tee.

BranchConnectionType (domain)—The element used to connect the branch to themain 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)




J-9137


Valve (Online Point

Feature Class, Fitting)

The Valve feature class contains information describing manufactured, pressurizedfittings used to control or impede flow of product through a pipeline system. Valvesprovide the control structure for the pipeline system and are often connected to theSCADA monitoring system for a pipeline. Valve features are often part of a generalizedpipeline network used for capacity, flow, and hydraulic analyses. Valves describe theinlet and outlet connection and diameter and wall thickness information of the connectioninput and output pipe features. The pipes that run along a single, unaltered (no stationequations) station series contain starting and ending values. The Valve feature class has arelationship with the Reading object class, which models that zero or more readings maybe taken at a single valve feature. The valve feature class contains the followingsubtypes, 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 incertain circumstances (Yes/No)


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


ValveFunction (domain)—The function that the valve performs (e.g., check, release,main line)

ValveNumber (string, 15)—An organizational number assigned to the valve




J-9137

January 2004 54

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.


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

VesselType (domain)—The type of vessel (e.g., odorizer, filter, scrubber, storagetank)


ImplementationIssues

The following section describes some issues that will need to be addressed by anorganization planning to implement the APDM as a geodatabase. The technicalcommittee strove to provide a data model that can be implemented out of the box usingthe tools found in version 8.3 of ArcToolbox™, ArcCatalog™, and ArcMap. However,some implementation decisions will require the use of custom code to achieve desiredbehavior of objects and classes within the model. Every effort was made to mitigate theneed for custom code. The APDM is a data model not an object model and thus can onlyprovide a construct for storing and organizing data rather than provide mechanisms thatdefine object behavior. The choices of how the APDM is to be implemented willdetermine 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 implementationconsiderations 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. Eventslayers/tables are considered "dynamic feature classes." The position of each event in anevent table can be recalculated dynamically when the Route-ID and/or Measure value forthe event are updated in the underlying event table. The advantage of this approach isthat the geometry of features is updated when the underlying linear referencinginformation is changed. The disadvantage of the event model is that performance canbecome untenable for events layers with tens of thousands of features and not all theanalytical functionality of ArcGIS can be applied to event layers. Another approach toimplementing the APDM is to use feature classes rather than event tables to store thegeometry. Using feature classes allows access to all the analytical functionality of ArcGIS; however, there is no dynamic response that rebuilds the geometry of the featureswhen the linear referencing information is altered. Custom code is required to implement"features as events" behavior.

Topology and theGeometric Network

Transmission pipelines have many coincident features whose position is derived from thecenterline—in effect, features are essentially dynamic events. These features aregeometrically coincident with the underlying centerline. This is the basis fortransmission pipeline—everything is located via stationing. A mechanism to identifydependent features that must also be updated when edits to the features and/or centerlineoccur is topology.




J-9137


Topology is a set of rules that define where geometry should be in space in relation toeach other. The rules define the permissible geometric relationships between features.The underlying reason for using topology in the transmission pipeline environment is thatsome 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 thecenterline for positioning, but features are also dependent on other features for existence(coating and pressure tests require that pipe segments be present). When the sourcefeature is removed, the dependent features must also be removed. Topology, at thecurrent time, provides the best tools for managing data integrity. The rules of topologydefine how these features' geometries relate to each other. Ranks can be set for eachfeature class participating in the topology to determine which features are salient andwhich can be altered to maintain integrity. "Dirty areas" appear for points, lines, andpolygons when topological rules are broken. Dirty areas are used to identify exceptionsto 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 asanother feature layer in ArcCatalog and ArcMap.

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

Annotation, dimension, and geometric network features are complex features andcannot 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 aline). Linear features consist of one or more feature segments.

The number of rules has relatively little effect on performance, but inappropriately oroverly defined rules will hurt performance since each error that is generated for atopology is an error that is written into the geodatabase.

Using subtypes will increase performance since less cursors are generated duringprocessing.

There is no recommended upper limit to the number of feature classes that mayparticipate 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 linearfeatures. A geometric network only allows one linear feature to participate in thenetwork at one location in space. Since stationing is such an integral part of pipelineoperations, the benefits of the geometric network do not outweigh those of topology froma data editing and maintenance standpoint. However, the geometric network is a versatiletool 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




J-9137

January 2004 56

geodatabase and that the results of the analysis be loaded back into the enterprisegeodatabase.

EventID,OriginEventID,

GroupEventID and LinkedFeatureID

The EventID attribute is used to globally identify each feature in the geodatabaseindependently of the feature or object class to which the object belongs. EventID can bestored as a long integer (approximately two billion unique identifiers) or a 16 characterstring containing a GUID (potentially unlimited range of unique values). In the case thatthe long integer format is used for EventID, then the last used EventID value must bemaintained in an object class or another storage construct. It is possible to apply andmaintain the last used EventID value manually, but this is a tedious process. At somepoint, an organization will see the need to maintain this value programmatically or via theunderlying RDBMS (identifiers, sequences, etc.).

The OriginEventID and GroupEventID attributes are provided for historical trackingpurposes and for grouping a set of referenced linear or point features together as a "super-

feature." The typical application of GroupEventID is to maintain connectivity betweensections 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 thathas been split or broken into separate child features. In this case, the child feature wouldstore the original EventID in the OriginEventID field.

The naming convention for foreign keys in the data model is <foreign classname>EventID. In some classes, a foreign key named LinkedFeatureEventID can befound. LinkedFeatureEventID stores the foreign key to one of several feature classes.LinkedFeatureEventID is used when a feature may be related to only one of severaldifferent feature classes. Examples of feature classes implementingLinkedFeatureEventID include CPOnlineLocation and Instrument. Some feature classesuse 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 willwork on most, if not every, properly implemented APDM. It is suggested thatapplication developers write applications that respond to the core attributes and featureclasses in the model according to the specifications recorded in this document.Applications should be responsible to the variations in other feature classes andattributes. The APDM was designed to provide a core set of objects that would remainconstant from model to model. The remaining objects in the APDM are suggestionsonly, based on common implementation of many pipeline companies' standard features.Applications written for the APDM will need to respond dynamically to objects that aredefined within the APDM beyond the core elements.

Conversion To/From PODS and ISAT

The recommended conversion of PODS and ISAT data to the APDM is as follows:

Convert PODS/ISAT control points to APDM control points.

Convert PODS/ISAT station series to APDM station series.

Convert PODS routes as APDM "continuous" station series.

Convert each feature/event table to an APDM event table/feature class, making noteto delineate the begin/end station series EventID attribute, begin/end station attribute,




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, andan ID field that could be used to group the control points.

Digitize station series features from the control points using the station value to orderthe control points sequentially. Calibrate the measure values of the station seriesfeatures using the station values of the control point features.

Import the ID field used to group the control points into the station series feature toestablish the relationship between control points and station series.

Update the begin/end station values of each station series feature from the measuredvalue contained in the from/to points of the station series feature.

Import event tables containing features. Event tables must have a field that containsa Route-ID value found in the EventID of a station series feature. Point event tablesmust have an attribute named BeginStation containing valid station values along astation 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. Thecontent and structure of the model is determined by the Pipeline Special Interest Group

steering and technical committees. The positions on the APDM steering and technicalcommittees are elected. Contact Andrew Zolnai (ESRI petroleum market manager) [email protected] for more information on serving on the APDM technical or steeringCommittees.

The APDM technical committee will meet three times a year, at the following venues, todiscuss 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) [email protected] (Steering CommitteeChairperson)

Peter Veenstra (GE Energy) [email protected] (Technical Committee

APDM_WhitePaper_v3

Documents

Transcript of APDM_WhitePaper_v3