Transcript PPTX - APDM.net

APDM 6.0
ArcGIS Pipeline Data Model
Peter Veenstra
APDM Standing Committee
Abstract
• The purpose of this workshop is to review the final release of the ArcGIS
Pipeline Data Model (APDM) version 6.0.
• Changes include;
– simplification of the data model structure,
– a focus on supporting gathering systems
– full support for both geometric/feature-based and event-table based
implementation of the model.
• An overview of the resources available for the APDM 6.0 implementation
will be provided including a preview of the latest APDM.net website.
• An overview of how the model has been implemented in Sparx System
Enterprise Architect UML Modeling software will be provided.
• Lastly, the current state of data models and best practices available to
pipeline operators and GIS practitioners will be outlined as an aid to
helping pipeline operators understand the options available for managing
pipeline data within a GIS.
Introductions
•
APDM Standing Committee Co-Chairs
– Tom Coolidge – ESRI Pipeline Industry Manager
– Peter Veenstra – Willbros Engineering
•
APDM Standing Committee
–
–
–
–
–
–
–
–
•
•
•
Justin Anderson – Enbridge Houston
Jeff Allen – Coler and Colantonio
Patrick Baes – Global Information Systems
Ron Brush – New Century Software
Eric James – Colonial Pipeline
John Linehan – JP Kenny
Tracy Thorleifson – Eagle Information Management
1 open position
www.apdm.net
www.esri.com/industries/pipeline/community/datamodel
https://www.linkedin.com/groups/APDM-ArcGIS-Pipeline-Data-Model155824/about
Overview
•
•
•
•
Part 1 - Changes in APDM 6.0
Part 2 - ArcGIS Pipeline Data Model (APDM)
Part 3 – APDM 6.0 in Enterprise Architect
Part 4 - State of Data Models
– ArcGIS Pipeline Data Model (APDM)
– PODS Relational
– PODS ESRI Spatial
• Part 5 - Thoughts on Pipeline Data Models
Part 1 - Changes in APDM
• Why do we do this?
• High level changes (Change Log)(Logical)(Physical)
–
–
–
–
–
–
–
–
Metadata Tables
Corrections
New Abstract Classes (more refined)
Relationship to LineLoop for ‘online’ features
Less ‘example’ classes
Activity and Document CrossRef
Better Site Location Tables
EventOffset Attribute
Part 1
1 of 11
Changes in APDM 6.0
• APDM is a Template – it has always been a starting point
from which more comprehensive data models can be
developed
• Contrary to popular belief APDM was never intended to be
a ‘be-all-end-all’ repository of pipeline data
• It has always been a design specification for how pipeline
data is created, edited, and how that data responds to
alterations/modifications to the pipeline centerline
• Optional classes have been reduced to keep the model inline with being template
• Changes to the core have been additive rather than
deleting, merging, splitting classes and elements
Part 1
2 of 11
APDM 6.0 – Why change?
• Represents changes to the core elements of the
data model
• Maintain compatibility with changes in core ESRI
technology – guiding principle
• Stay in sync with PODS ESRI Spatial Data Model
• Get in-step with ESRI message towards data
models and GIS as a service
– location, services, data exchange, integration
– simpler template to start with
– helps smaller operators and gathering companies
Part 1
3 of 11
The ArcGIS Pipeline Data Model (APDM v6.0)
APDMObject
GlobalID
EventID (pk)
PipelineID
TagID
[Object]
Abstract &
Metadata Classes
[Object]
OBJECTID
ActivityHierarchy
LineLoopHierarchy
SubSystemHierarchy
[ObjectArchive]
Catalog View
Object
OBJECTID
APDM_GeoDatabase
[Feature]
Transmission (FeatureDataset)
Shape
Activity
Bend
ReferenceMode
RefMode <d>
RefModeMeasureRootName
RefModeBasis <d>
RedModeType <d>
RefModeUnits <d>
IsPRM <d>
ParentRefMode (fk)
RefModeRootName
APDMFeature
This section describes the ‘APDM Abstract Classes’ and ‘APDM Metadata’ tables. This diagram shows the inheritance of attributes and
relationships from the top-most classes down to the lower classes. Inheritance means that a concrete feature or object class inherits the
attributes, relationships and potential geometry types from all the classes above it (following the lines and the arrow heads pointing
upwards). All classes are shown with ‘light yellow’ header boxes with the exception of the ‘Audit’ classes which are shown in ‘light green’.
Standard ESRI classes are shown with ‘white’ attribute boxes and ‘APDM Abstract Classes’ are shown with ‘light blue’ attribute boxes. The
‘gray’ boxes show feature and object classes that inherit directly from the specified parent ‘APDM Class’. [Square Brackets] around the title
of a class means that no concrete feature/object class can inherit directly from this class. Note that for a class to belong to APDM it must
inherit from one of the specified ‘APDM Abstract Classes’ otherwise it is considered to be only an ESRI class with no significance or
relevance to the APDM. The feature class and object class icons denote which geometry type concrete ‘child’ classes may implement.
CreatedBy
CreatedDate
EffectiveFromDate
EffectiveToDate
HistoricalState <d>
LastModified
ModifiedBy
OriginEventID
ProcessFlag
Remarks
Metadata
OBJECTID
GlobalID
EventID (pk)
PipelineID
TagID
ClassMetaData
ClassEventID (pk)
ClassName
ClassType <d>
RequiresGeometry
AllowGap <d>
AllowOverlap <d>
ArchivingActivated
ServerName
SchemaOwner
OnlineLocationClass
RelationshipMetaData
OriginClassEventID (fk)
OnlineLocationClassEventID (fk)
OnlineLocationMechanism <d>
OriginClassName (fk) <d>
OriginClassEventID
OriginPrimaryKey
OriginForeignKey
OriginLabel
DestinationClassName (fk) <d>
DestinationClassEventID
DestinationPrimaryKey
DestinationForeignKey
DestinationLabel
RelationshipCardinality <d>
RelationshipModeStatus <d>
FeatureArchive
CreatedBy
CreatedDate
EffectiveFromDate
EffectiveToDate
HistoricalState <d>
LastModified
ModifiedBy
OriginEventID
ProcessFlag
Remarks
The metadata classes represent a set of object classes that are used to hold information about the reference modes, information about
each concrete class inheriting from an ‘APDM Abstract Class’ and information about which ‘offline’ APDM classes have related ‘online’
polyline or ‘online’ point classes.
DomainList
DomainMetaData
DomainName
DomainValue
DomainDescription
ValueOrder
DomainClass
DomainName
DomainGroup
OriginClassName <d>
AttributeName
ClassName <d>
DomainName
ActivityCrossRef
Branch
ActivityDocumentCrossRef
CPRectifier
ActivityHierarchy
CPRectifierLocation
ActivityMetaData
Coating
Company
Contact
ConditionOrAnomaly
Crossing
ControlPoint
StationSeries
CrossingEasement
DocumentCrossRef
CrossingFeature
ExternalDocument
CrossingLocation
Lineloop
FacilityPoint
LineloopHierarchy
Inspection
Site
JoinMethod
SiteContact
LineOperationalUse
Subsystem
OfflineMarker
OutsideArea
OwnerOperator
PipeSegment
Pressure
ProductRange
RegulatorySegment
RepairFeature
CenterlineObject
NonFacilityObject
OperationalStatus <d>
Status <d>
LineLoop
SubSystem
Site
FacilityObject
InServiceDate
InstallationDate
OperationalStatus <d>
SiteEventID (fk)
Activity
Company
ExternalDocument
OwnerOperator
SiteContact
OnlineEvent
CLEditResponse <d>
CLValidityTolerance <d>
EventOffset
LineLoopEventID (fk)
RouteEventID (fk)
SiteLayout
SiteLocation
SitePoint
StationSeries
CenterlinePolyline
LineLoop
BeginMeasure
EndMeasure
BeginStation
EndStation
OperationalStatus <d>
ValveOperator
Site
OnlineFacilityEvent
AuditObject
ActivityCrossRef
ActivityExtension
ActivityEventID (fk)
ActivityEventID (fk)
ActivityDate
InServiceDate
InstallationDate
OperationalStatus <d>
SiteEventID (fk)
OnlinePointFacilityEvent
Measure
SeriesEventID
Station
Point_X
Point_Y
Point_Z
SymbolRotation
Activity
OnlinePointEvent
Measure
SeriesEventID
Station
Poiint_X
Point_Y
Point_Z
Status <d>
SymbolRotation
Site
OnlinePolylineEvent
BeginMeasure
EndMeasure
BeginSeriesEventID
BeginStation
EndSeriesEventID
EndStation
Status <d>
StationSeries
CenterlinePolylineEvent
RouteEventID (fk)
BeginSeriesEventID
EndSeriesEventID
CLEditResponse <d>
CLValidityTolerance <d>
CenterlinePoint
CLControl <d>
CLStationEditResponse <d>
CLXYEditResponse <d>
CLZEditResponse <d>
OperationalStatus <d>
MeasureValue
Point_X
Point_Y
Point_Z
RouteEventID (fk)
SeriesEventID (fk)
StationValue
SymbolRotation
OfflineFeature
OfflineFacility
Status <d>
InServiceDate
InstallationDate
OperationalStatus <d>
<OnlineFeatureClass>
OnlinePointForOfflineFeatureEvent
OffsetAngle
OffsetDistance
StationLocated <d>
FittingEvent
SitePolygon
CLEditResponse <d>
CLValidityTolerance <d>
RouteEventID (fk)
StationSeries
StationSeries
Structure
Valve
<Online<FC>
ForOfflineClass>
OfflinePoint
OfflinePointFacility
Point_X
Point_Y
Point_Z
SymbolRotation
SiteEventID (fk)
Point_X
Point_Y
Point_Z
SymbolRotation
SitePolygon
SiteLayout
CPRectifier
OnlinePolyline
OfflineNonPointFacility
SiteEventID (fk)
OfflineMarker
ControlPoint
OnlinePoint
LineLoop
BeginMeasure
EndMeasure
BeginSeriesEventID
BeginStation
EndSeriesEventID
EndStation
Status <d>
LineOperationalUse
RegulatorySegment
Inspection
OwnerOperator
ProductRange
StationSeries
LineLoop
OnlineFacility
Measure
SeriesEventID
Station
Status <d>
SymbolRotation
Poiint_X
Point_Y
Point_Z
StationSeries
<OnlineFeatureClass>
Site
SubSystemRange
OnlinePolylineForOfflineFeatureEvent
NOTE: The Catalog View
does not show any
relationship classes Only
feature and object classes
are shown.
StructureLocation
SubsystemRange
CrossingFeature
Structure
OnlinePolylineFacilityEvent
BeginMeasure
EndMeasure
BeginSeriesEventID
BeginStation
EndSeriesEventID
EndStation
OnlineFeature
InServiceDate
InstallationDate
OperationalStatus <d>
SiteEventID (fk)
OnlinePointFacility
OnlinePolylineForOfflineFeature
OffsetAngle
OffsetDistance
StationLocated <d>
BeginOffsetAngle
BeginOffsetDistance
EndOffsetAngle
EndOffsetDistance
StationLocated <d>
OnlinePolylineFacility
Bend
RepairFeature
JoinMethod
SiteLocation
Measure
SeriesEventID
Station
Point_X
Point_Y
Point_Z
SymbolRotation
StructureLocation
ConditionOrAnomaly
OnlinePointForOfflineFeature
BeginOffsetAngle
BeginOffsetDistance
EndOffsetAngle
EndOffsetDistance
StationLocated <d>
Site
BeginMeasure
EndMeasure
BeginSeriesEventID
BeginStation
EndSeriesEventID
EndStation
Casing
Coating
PipeSegment
Sleeve
StationSeries
CrossingEasement
LineLoop
<OfflineFeatureClass>
Fitting
DateManufactured
Grade <d>
InletConnectionType <d>
InletDiameter <d>
InletWallThickness <d>
Manufacturer <d>
Material <d>
PressureRating <d>
<OfflineFeatureClass>
FacilityPoint
Valve
Branch
APDM Core Classes
APDMObject
DateManufactured
Grade <d>
InletConnectionType <d>
InletDiameter <d>
InletWallThickness <d>
Manufacturer <d>
Material <d>
PressureRating <d>
Additional Classes
NonFacilityObject
AuditObject
Structures/Buildings/Identified Sites
CenterlinePoint
CenterlinePolyline
CenterlineObject
APDMObject
ControlPoint
StationSeries
ControlPointAngle
ControlPointType <d>
PIDirection <d>
LineLoopEventID (fk)
ParentStationSeriesEventID (fk)
FromStationSeriesEventID (fk)
FromConnectionStationValue
ToStationSeriesEventID (fk)
ToConnectionStationValue
RefMode <d>
StationSeriesName
SeriesOrder
LineLoop
ClassName (fk) <d>
FeatureEventID
Comments
CommentBy
CommentDate
LineLoopHierarchy
LineName
LineFunction <d>
LineJurisdiction <d>
ParentLineLoopEventID (fk)
ChildLineLoopEventID (fk)
Foreign Line Crossings
OfflineFeature
OnlinePoint
ActivityCrossRef
OfflineFeature
Offline Feature
NonFacilityObject
OnlinePointForOfflineFeature
OfflinePoint
OnlinePolylineEventForOfflineFeature
ActivityHierarchy
ParentActivityEventID (fk)
ChildActivityEventID (fk)
ActivityDocumentCrossRef
ExternalDocumentEventID (fk)
OutsideArea
StructureLocation
AreaName
IdentifiedSite <d>
StructureEventID (fk)
StructureType <d>
StructureEventID (fk)
Activity
ActivityDate
ActivityDescription
ActivityName
ActivityType <d>
ReferenceMode
Bend
ExternalDocument
DocumentDescription
DocumentType <d>
FileName
FilePath
FileServer
Hyperlink
AltHyperlink
CrossingFeature
Structure
CrossingLocation
CrossingEventID (fk)
Name
IFHO <d>
StructureName
StructureType <d>
Crossing
Clearance
CrossingEventID (fk)
CrossingFeatureEventID (fk)
EasementWidth
CrossingEasement
CrossingName
AlternateName
CrossingType <d>
OfflineMarker
CrossingEventID (fk)
Name
EasementWidth
MarkerID
MarkerType <d>
MarkerNumber
DocumentCrossRef
ClassName (fk) <d>
FeatureEventID
FeatureAttributeName
ExternalDocumentEventID (fk)
ExternalDocumentReference
Branch
Coating
CPRectifierLocation
Generic Tables
Operational and Regulatory Segments
NonFacilityObject
CrossingEasement
ActivityExtension
OnlinePolyline
CrossingLocation
Bend
FacilityPoint
Branch
Inspection
Company
Company
JoinMethod
Contact
CompanyAddress
CompanyLabel
CompanyName
CompanyType <d>
OperatorID
Coating
LineOperationalUse
ControlPoint
Pressure
ConditionOrAnomaly
OwnerOperator
Name
Email
Mobile
Phone
UserID
CPRectifier
PipeSegment
CPRectifierLocation
ProductRange
Activity
Crossing
RegulatorySegment
CrossingEasement
ActivityMetaData
AcceptanceDate
AFENumber
CompanyName
ContactEmail
DateFinish
DateStart
JobNumber
ProjectName
ProjectNumber
ReasonForSurvey
SurveyNumber
WONumber
LineOperationalUse
RegulatorySegment
DesignCode
HistoricLineName
LineType <d>
LineFunction <d>
LineJurisdiction <d>
OperatingArea
Inspection
DeterminationDate
DeterminationMethod
RegulatorySegmentType <d>
OwnerOperator
InspectionDate
InspectionType <d>
BaselineAssessment
InspectionResult
InspectionCompany (fk)
InspectionBy (fk)
ProductRange
CompanyEventID (fk)
OwnerPercentage
OwnerType <d>
Product <d>
Company
Contact
RepairFeature
CrossingFeature
SubsystemRange
CrossingLocation
StructureLocation
FacilityPoint
Operational and Facility Point Features
Valve
Inspection
CenterlineObject
JoinMethod
OnlinePointFacility
Lineloop
Fitting
OnlinePointFacility
OnlinePoint
OfflinePointFacility
OnlinePointForOfflineFeature
LineOperationalUse
OfflineMarker
Site
SiteName
SiteType <d>
SiteLocation
Pressure
ConnectionDescription <d>
ConnectionType <d>
SiteName
OwnerOperator
FacilityPoint
RegulatorySegment
RepairFeature
Coating
Valve
FeatureLength
FacilityPointType <d>
InletDiameter <d>
Insulated <d>
OutletDiameter <d>
PipeSegment
ProductRange
Bend
Branch
Closed <d>
Critical <d>
FeatureLength
Insulated <d>
RemoteControl <d>
Specification <d>
Site
CPRectifier
SiteLayout
FacilityPoint
SiteLocation
JoinMethod
SitePoint
PipeSegment
SitePolygon
RepairFeature
StationSeries
SiteLayout
Branch
Branched <d>
BranchDiameter <d>
BranchType <d>
Closed <d>
FeatureLength
InletDiameter <d>
Insulated <d>
OutletDiameter <d>
Specification <d>
Facility Segments
Bend
BendDirection <d>
BendAngleHorizontal
BendAngleVertical
RepairFeature
RepairDate
RepairFeatureType <d>
JoinMethod
Insulated <d>
JoinMethodType <d>
CoatingType <d>
CoatingMaterial <d>
CoatingThickness <d>
CoatingThicknessUOM <d>
Subsystems
ConditionOrAnomaly
CPRectifier
AnomalyDepth
AnomalyLength
AnomalyOrientation
AnomalyWidth
ConditionAnomalyType <d>
InitialAssessment
InitialAssessmentBy
InitialAssessmentDate
PercentDepth
RectifierIdentifier
RectifierType <d>
CPRectifierLocation
CPRectifierEventID (fk)
NonFacilityObject
Site Location
Structure
SitePoint
SubSystem
SitePolygon
SubsystemRange
Valve
StructureLocation
OnlinePolylineFacility
CenterlinePolylineEvent
CenterlineObject
OnlinePointFacility
OfflineNonPointFacility
Contact
SiteContact
SiteEventID (fk)
ContactEventID (fk)
Valve
PipeSegment
NOTES:
05/09/2013 – Version 6.0
04/23/2010 - Version 5.0
04/01/2006 - Version 4.0
10/05/2004 - Version 3.0
APDM Model is maintained by APDM Technical
Committee on behalf of the ESRI and the ESRI Pipeline
Interest Group (PIG).
Copyright 2002, 2003, 2004, 2005, 2006, 2007, 2008,
2009, 2010, 2013 Environmental Systems Research
Institute, Inc. All Rights Reserved.
EventID  EventID is an arbitrary name assigned to a
globally unique identifier. The use of ‘Event’ in EventID
attribute name DOES NOT denote that features identified
by this attribute are ‘events’ created via linear referencing.
EventID could be replaced by FeatureID, GeoElementID,
or GeoEntityID.
The classes depicted in this model are assumed to be
feature classes and are depicted as such rather than as
‘events’ or ‘event tables’. APDM supports both – feature
classes and events.
Version 6.0
Key
Concrete Class
RegularNormalField
SomethingEventID (FK)
MaybeEventID (FK)
DomainField <d>
Abstract Class
RegularNormalField ...
A concrete class represents a object table or a feature class. Object tables and feature
classes stores rows of data containing attributes & features and attributes respectively.
·
Each field or attribute in the class stores data of a specific type.
·
(FK)  Indicates the field is a foreign-key (fk) containing values found only in the
primary key (pk) of concrete class.
·
<d>  Indicates that the valid values for the field are proscribed by the range of
values contained in a domain
An abstract class contains a set of attributes and possibly relationships that are inherited
by every concrete subclass beneath the abstract class in the inheritance tree. Eventbased abstract classes are ‘Orange’. The icons (point, table, line) indicate if the abstract
class can be inherited from and the type of geometry that the concrete class will inherit.
Lines that indicate relationships between concrete classes. The single line connector
indicates a cardinality of ‘one’ whereas the ‘Crow’s Foot’ connector indicates a cardinality of
‘many’. Cardinality defines a rule indicating how many rows in a concrete class can
participate in a single instance of a specified relationship.
ExternalDocument
Wormholes represent a relationship between two concrete classes which is not specified
diagrammatically by a line connecting the two classes. A pink wormhole indicates a proper
primary key (pk) - foreign key (fk) relationship.
Generalization - Inheritance - A inheritance relationships between a super-class and a
subclass in which the subclass inherits all of the properties of the super-class. Super-classes
represent general behaviors and properties which are inherited by subclasses which, in
turn, add more specific and complex behaviors to those already inherited.
Launcher
Receiver
Organization
A subtype that further classifies a concrete classes into meaningful sub-divisions without
creating additional classes. Allows for additional behavior for each subtype beyond the
standard behavior for features in a particular class. Is particularly useful for assigning
different domains to attributes, applying different splitting/merging rules, applying different
symbology in a map environment, choosing different network connectivity rules per subtype
and allowing for different editing behaviors within the GIS environment.
Organizational label used to sort concrete classes into meaningful operational categories.
Coating
SegmentType <d>
FacilityPointClassType <d>
FacilityPointEventID (fk)
DateManufactured
DesignFactor
DesignPressure <d>
Grade <d>
InstallLocation <d>
LongitudinalWeldType <d>
Manufacturer <d>
Origin <d>
PercentSMYS <d>
SMYS <d>
Specification <d>
WallThickness <d>
AppliedForRepair <d>
CoatingType <d>
CoatingMaterial <d>
CoatingThickness <d>
CoatingThicknessUOM <d>
Internal <d>
Origin <d>
Pressure
MAOP <d>
MAOPEstablishedDate
MOP <d>
MOPEstablishedDate
LatestTestPressure
LatestTestPressureDate
SubsystemRange
SubsystemEventID (fk)
SubSystem
SitePoint
SubsystemName
SubSystemType <d>
ParentSubsystemEventID (fk)
SiteName
SitePolygon
SiteName
SiteLayout
SiteName
Site
Valve
FacilityPoint
ClassMetaData
Part 1
4 of 10
MetaData Tables
• ReferenceMode, ClassMetaData,
OnlineLocationClass – remain the same
• Add RelationshipMetaData, DomainList,
DomainMetaData, DomainClass are new
Metadata
ReferenceMode
RefMode <d>
RefModeMeasureRootName
RefModeBasis <d>
RedModeType <d>
RefModeUnits <d>
IsPRM <d>
ParentRefMode (fk)
RefModeRootName
Object
OBJECTID
ClassMetaData
ClassEventID (pk)
ClassName
ClassType <d>
RequiresGeometry
AllowGap <d>
AllowOverlap <d>
ArchivingActivated
ServerName
SchemaOwner
OnlineLocationClass
RelationshipMetaData
OriginClassEventID (fk)
OnlineLocationClassEventID (fk)
OnlineLocationMechanism <d>
OriginClassName (fk) <d>
OriginClassEventID
OriginPrimaryKey
OriginForeignKey
OriginLabel
DestinationClassName (fk) <d>
DestinationClassEventID
DestinationPrimaryKey
DestinationForeignKey
DestinationLabel
RelationshipCardinality <d>
RelationshipModeStatus <d>
DomainList
DomainName
DomainValue
DomainDescription
ValueOrder
DomainMetaData
DomainName
DomainGroup
OriginClassName <d>
DomainClass
AttributeName
ClassName <d>
DomainName
StationSeries
Part 1
5 of 11
[Object]
OBJECTID
APDMObject
Abstract Classes
OnlineEvent
CLEditResponse <d>
CLValidityTolerance <d>
EventOffset
LineLoopEventID (fk)
RouteEventID (fk)
StationSeries
LineLoop
GlobalID
EventID (pk)
PipelineID
TagID
• APDMFeature and APDMObject
• Event-based Abstract Classes – Tables not
Feature Classes
OnlineFacilityEvent
[ObjectArchive]
CreatedBy
CreatedDate
EffectiveFromDate
EffectiveToDate
HistoricalState <d>
LastModified
ModifiedBy
OriginEventID
ProcessFlag
Remarks
InServiceDate
InstallationDate
OperationalStatus <d>
SiteEventID (fk)
OnlinePointFacilityEvent
Measure
SeriesEventID
Station
Point_X
Point_Y
Point_Z
SymbolRotation
FittingEvent
OnlinePointEvent
Site
Measure
SeriesEventID
Station
Poiint_X
Point_Y
Point_Z
Status <d>
SymbolRotation
OnlinePolylineEvent
BeginMeasure
EndMeasure
BeginSeriesEventID
BeginStation
EndSeriesEventID
EndStation
Status <d>
OnlinePolylineFacilityEvent
BeginMeasure
EndMeasure
BeginSeriesEventID
BeginStation
EndSeriesEventID
EndStation
<OnlineFeatureClass>
OnlinePointForOfflineFeatureEvent
OffsetAngle
OffsetDistance
StationLocated <d>
OnlinePolylineForOfflineFeatureEvent
BeginOffsetAngle
BeginOffsetDistance
EndOffsetAngle
EndOffsetDistance
StationLocated <d>
<OfflineFeatureClass>
DateManufactured
Grade <d>
InletConnectionType <d>
InletDiameter <d>
InletWallThickness <d>
Manufacturer <d>
Material <d>
PressureRating <d>
Part 1
6 of 11
Relate to Lineloop
• Direct relationship from online features to
LineLoop
• Designed to support feature-based gathering
systems with no underlying stationing – have
pipes related directly to a ‘lineloop’ grouping
• Keeps hierarchy without need for stationing
• If you have geometric features representing your
pipes and not stationing then you can place these
features, relate them to a line and be on-yourway.
• Can implement Geometric-Networks OOTB
Part 1 7 of 11
Less Example Classes
• APDM is really a ‘design standard’
• Meets the minimum requirements for handling
transmission and also gathering systems
• Cleaner starting point
• Less documentation to maintain
• It can always be grown
• Simpler and more technology focused
• Example classes are still available in version 4.0
and 5.0 documentation via www.apdm.net
Part 1
8 of 11
Activity CrossRef
APDMObject
NonFacilityObject
AuditObject
• Why do (did) we have audit tables?
• Remove all audit tables from database
• Each feature class and table relates to
ActivityCrossRef
• Intersection or M-N table between Activity and
rest of database
• Less tables, less relationship classes,
• Single source for tying/grouping/querying what
are stored in separate tables or were implicitly
joined by geographic location
ActivityCrossRef
ClassName (fk) <d>
FeatureEventID
Comments
CommentBy
CommentDate
ActivityHierarchy
ParentActivityEventID (fk)
ChildActivityEventID (fk)
ActivityDocumentCrossRef
ExternalDocumentEventID (fk)
Activity
ActivityDate
ActivityDescription
ActivityName
ActivityType <d>
Bend
Branch
Company
Coating
ControlPoint
ConditionOrAnomaly
Etc...
Part 1
9 of 11
NonFacilityObject
AuditObject
Document CrossRef
• Same construct as activities
• Remove all M-N relationships between
ExternalDocument and audit tables from
database
• Each feature class and table relates to
DocumentCrossRef
• Less tables, less relationship classes,
• Single source for tying/grouping/querying what
are stored in separate tables or were implicitly
joined by document
ActivityDocumentCrossRef
ExternalDocumentEventID (fk)
Activity
ExternalDocument
ActivityDate
ActivityDescription
ActivityName
ActivityType <d>
DocumentDescription
DocumentType <d>
FileName
FilePath
FileServer
Hyperlink
AltHyperlink
DocumentCrossRef
ClassName (fk) <d>
FeatureEventID
FeatureAttributeName
ExternalDocumentEventID (fk)
ExternalDocumentReference
Bend
Branch
Company
Coating
ControlPoint
ConditionOrAnomaly
Etc ...
Part 1
10 of 11
Site Location/EventOffset
• Added SitePoint, SiteLayout and SitePolygon
Tables
• Added EventOffset field for all online event
types
– Allows OOTB ArcMap ‘Add Route Event’ tool to
add events but offset from pipeline centerline
– Useful for showing results of inspections over time
or multiple inspections
Part 1
11 of 11
Part II - APDM
• ArcGIS Pipeline Data Model
• Built for ESRI Geodatabase
– Leverage ESR
• Useful starting place
• Describes in detail how pipeline data respond to
centerline edits, location placement, and how
editing can be performed on them
• Standing Committee of 10 operators and vendors
• Meet at PUG, GITA O&G and ESRI UC
• Website – www.apdm.net and www.esri.com
Part 2
1 of 1
Part III - APDM and Case Tools
• Visio and UML and APDM
• Alternative in Enterprise Architect Software
(www.sparxsystems.com)
–
–
–
–
Is a Case Tool
Is ESRI Business Partner
Is ESRI’s preferred choice
Uses XML Workspace Import to build schema – not
additive (need XML schema diff)
– Scripts
• for validation,
• for organization
• to import an existing Visio and XML Workspace into EA
Part 3
1 of 2
Part III – APDM 6.0 in Enterprise Architect
• Base Functionality - toolbar, diagrams, packages,
hyperlinks, documentation
• Import from Visio UML and from ArcGIS XML
WorkspaceOrganization of Model
• Validation of output XML Workspace before
import into ArcCatalog
• Modularization
• Base Line (Documentation, Delta)
• Multiple Inheritance (Abstract Class Hierarchy)
• Script and Query Engine
Part 3
2 of 2
Part IV – State of Pipeline Data Models
•
•
•
•
ArcGIS Pipeline Data Model
PODS Relational
PODS ESRI Spatial
Others (GDI, PODS Open Spatial)
APDM and PODS Committee members talk and
discuss and collaborate often.
Each model serves a purpose and has a place in the
industry.
It is not a competition!!!
Part 4
1 of 12
The Players
• PODS (Pipeline Open Data Standard)
–
–
–
–
–
Relational database model.
Tabular and spatial data are managed as two systems.
SQL driven.
Requires GIS software although by design GIS agnostic, but optimized for ESRI.
Standards organization. Active User Community.
• APDM (ArcGIS Pipeline Data Model)
– ESRI Geodatabase model.
– Tabular and spatial data are managed by one system.
– Geodatabase provides built in versioning (long transactions), replication,
archiving.
– Requires ESRI ArcGIS software. Works with desktop, server, web and mobile
software OOTB.
– Template Model (build as needed). Quasi-active user community.
• PODS ESRI Spatial (Geodatabase version of PODS Relational – optimized
for Geodatabase)
Part 4
2 of 12
PODS Data Model
RDBMS
Oracle or MS SQL Server
PODS Relational
GIS Data
Spatial Enabled
PODS Relational
Part 4
3 of 12
APDM
RDBMS
PODS ESRI
Spatial or APDM
Oracle or MS SQL Server
ArcSDE
Part 4
4 of 12
To decide on a model, ask some
questions
• What GIS are you using?
• Is your organization standards driven?
• Focused on the Model or focused on the
business?
• How do you implement your centerline and/or
pipeline hierarchy?
• Do you have any GIS software in place?
• What are your business processes?
Part 4
5 of 12
What GIS are you using?
• If using ESRI technologies then choice might be
weighted toward a Geodatabase type model …
– PODS ESRI Spatial
– ArcGIS Pipeline Data Model
• If not particular about GIS software then choice
might be …
– PODS Relational
– PODS Open Spatial
– Geodatabase-type model
Part 4
6 of 12
Organization Standards Driven
• If business unit is standards-driven then
choice would lean towards PODS ….
– PODS Relational
– PODS ESRI Spatial
• If business unit demands flexibility and agility
over standards OR do not want weight of the
320+ PODS tables then lean towards …
– APDM
– Modified PODS ESRI Spatial
Part 4
7 of 12
Data Model or Business Focus
• If the choice of a data model drives the business
then choose …
– PODS Relational
– PODS ESRI Spatial
– APDM
• If the need for the data model is driven by the
business … (Integrity Management, Operations,
Engineering)
– APDM
– Modified PODS ESRI Spatial
Part 4
8 of 12
Centerline Hierarchy
• If the pipeline is modeled by line-route-series
and requires continuous measure and
engineering stationing then choose …
– PODS Relational
– PODS ESRI Spatial
• If the pipeline is modeled by only one
‘reference’ mode or no reference mode then
choose …
– APDM
Part 4
9 of 12
Software
• If the company has specific software for PODS
relational or has a team of excellent SQL
developers or excellent DBA support then choose
…
– PODS Relational
• If the company requires OOTB tools to work with
GIS software or as a part of GIS software then
choose …
– APDM
– PODS ESRI Spatial
Part 4
10 of 12
What are your business processes?
• GIS is the system of record for location
Part 4
11 of 12
Decision Matrix
Criteria/Data
Model
PODS Relational
PODS ESRI Spatial
ArcGIS Pipeline
Data Model
Geographic Information
System (ESRI?)
SQL Only. Requires
integration w/ GIS.
Yes
Yes
Require Standard
Yes (Standard out of the
box)
Yes (Standard out of the
box)
No (Template Model –
Framework)
Data Model driven by
Business
Maybe (Is a standard,
can be modified in
additive fashion)
Maybe (Is a standard,
can be modified in
additive fashion)
Yes (Customizable –
requires work but
provides flexibility)
Business driven by Data
Model
Yes (Data model requires
specific workflows to
implement and support.)
Yes (Data model requires
specific workflows to
implement and support.)
No (Template. Data
model is created to suit
business)
Require measure and
stationing
Yes
Yes
No (Does not require but
can support both)
Only one measurement
system
No
No
Yes
Customized Software
Required
Sort of …
No
No
Part 4
12 of 12
Part V – Data Models
• Who needs them?
• How should we use them?
• Is it time to re-think how they are used?
Part 5
1 of 8
The need for data models
•
•
•
•
•
Why do we have them?
Why has so much energy been put to them?
Relational databases are great for OTP
What are noSQL databases bringing to the table?
How do exchange mechanisms affect us?
– JSON, GeoJSON, XML
•
•
•
•
How can we incorporate the use of Tags?
Is everything going to become coordinate-driven?
Distributed Services
Information Exchange Standards
Part 5
2 of 8
Choosing a Data Model
• The business drives the model, not the other
way around.
• Systems are going to be connected
• ESRI platform is focusing in the cloud
• ArcGIS Online is about services and the
consumption of them
• GIS is the system of record for location and
the hub that brings in all the other systems
Part 5
3 of 8
DMS
Documents
Data
WMS
Inspections
Planning
Routing
Tracking
Auditing
Work
Inspections
Tracking
Location Data
Model
LOCATION
is everything!
Engineering
Project LifeCycle
Design
Installation
Fabrication
Life-of-Asset Records
Conditions
Anomalies
Tracking
Analysis
Prediction
Part 5
4 of 8
APDM – last bits and next steps …
• Publish the web site to APDM.NET
• Finish the core document
• Watch and see what ESRI is going to do next
Part 5
5 of 8
APDM Committee Volunteers and
Contributors Through the Years
Jeff Allen, Justin Anderson, Doug Asay, John Alsup, Patrick Baes, Rob Brook, Ron
Brush, Brian Boulmay, Lynn Crouse, Chris Elmer, Dave Frye, Tom Gilmour, Ken Greer,
Benny Guo, Scott Hills, Luke Hutmacher, Eric James, Janette Jenson, Mike Kallas,
Mike King, Theo Lawrence, John Linehan, Maggie Mabrey, Tom Marcotte, Greg
McCool, Rob McElroy, Bill Meehan, Carl Meinke, Todd Murphy, Mary Muse, Buddy
Nagel, David Nemeth, Ted Peay, Lane Powell, Jeff Puuri, Debra Rohrer, Andrew Saje,
Cindy Salas, Rex Shrunk, Colby Smith, Jay Smith, John Spangler, Fred Spickler, Tracy
Thorleifson, Peter Veenstra, Troy Walda, Mark Warner, Pamela West, Ed Wiegele,
Craig Wilder, Danika Yeager, Chad Zamarin, Andrew Zolnai
Part 5
6 of 8
ArcGIS
Pro
ArcMap
A New Application
for Desktop
ArcGIS Pro
Desktop
Files
DBMS
Server
Cloud
•
Improved User Experience
•
Very Fast
•
Combined 2D and 3D
•
Powerful Analysis
•
Multiple Layouts
. . . Tightly Integrated with Web GIS
Part 5
7 of 8
2014 Esri UC Technical Workshop
Part 5
8 of 8
Thank you!
Questions?
[email protected] – www.esri.com
[email protected] – www.apdm.net
https://www.linkedin.com/groups/APDM-ArcGIS-Pipeline-Data-Model-155824/about
That’s all folks!