PODS Lite. Technical Overview and Guide

Transcription

1 PODS Lite Technical Overview and Guide Introduction Since 1998, the Pipeline Open Data Standard (PODS) Association has been focused on providing a comprehensive, open, vendor-neutral, highly scalable, and proven enterprise database architecture focused on increasing the safety and integrity of pipelines worldwide. The PODS Association announces the release PODS Lite, an abbreviated version of the full PODS Pipeline Data Model allowing pipeline industry professionals to explore how implementation of this recognized and established data model may improve their pipeline data management, integrity and risk management, operational and regulatory reporting activities. Pipeline operators and other interested parties not yet using the full PODS Pipeline Data Model, along with Association members not yet familiar with the PODS data standards, are encouraged to use PODS Lite to evaluate the PODS Pipeline Data Model capabilities and value. For existing Association members and users of the full PODS Pipeline Data Model, PODS Lite provides an opportunity to preview the Associations Next Generation Data Model. The PODS Association is offering the PODS Lite Data Model free of charge to anyone wishing to evaluate and understand how the PODS Pipeline Data Model can support their needs.

2 PAGE 2 Intended Audience This document provides a technical overview of the PODS Lite Data Model architecture and new PODS data modeling processes and methods. This document is a companion to the Data Dictionaries describing the contents of the PODS Pipeline Data Model. This document is intended for individuals deploying, configuring and extending the PODS Lite data model and for individuals wishing to understand new procedures being used by the PODS Association to manage and maintain PODS Lite and the large PODS Pipeline Data Model. A technical user of the PODS Pipeline Data Model should be able to understand how the model is designed and how it can be implemented after reading this section. What Is PODS Lite? PODS Lite is a subset of the full PODS Pipeline Data Model including many of the core tables of the full Data Model. The specific list of core tables provided with PODS Lite is described in more detail below. The PODS Association is currently developing a new PODS Data Model Version 7.0. This new version will be a transformational not an incremental change from the current Data Model Version 6.0. PODS Lite Overview Free for Use by All PODS Lite is available to both PODS Association members and nonmembers. Both are encouraged to use PODS Lite to understand how the PODS Pipeline Data Model works and what value it provides. Subset of the Full Data Model PODS Lite is a subset of the full PODS Pipeline Data Model. A set of core tables is provided, allowing users to preview the PODS Core linear referencing, asset and operational tables. Preview of PODS Version 7.0 PODS Lite is a preview of PODS Pipeline Data Model Version 7.0, scheduled for initial release in 2017 and full release in Preview of Modernized PODS Standards PODS Lite reflects a major re-design and modernization of the PODS Pipeline Data Standard taking place as part of PODS Next Generation initiative. Available for Multiple Platforms While PODS Lite is being made available initially in Esri geodatabase format for use in Esri s ArcGIS for Pipeline Referencing (APR) extension, PODS Lite will also be available for other GIS and RDBMS platforms in early This transformation of the PODS Data Model is being conducted under the PODS Association s Next Generation initiative. As such, PODS Lite also operates as a preview of the new PODS Pipeline Data Model Version 7.0, being developed as part of the PODS Next Generation initiative. This release of PODS Lite is being made available in the Esri geodatabase format. This version, referred to as PODS Lite Geodatabase for APR, will work with Esri s ArcGIS for Pipeline Referencing, or APR, extension. This is possible because the Esri APR linear referencing extension will work with any data model that meets certain requirements; the PODS Pipeline Data Model Version 7.0 and PODS Lite meet these requirements. The PODS Association and Esri have worked collaboratively on the development of PODS Lite for APR. PODS Lite allows pipeline operators to take advantage of both Esri s APR and the PODS Pipeline Data Model. Pipeline operators will realize significant value when using APR s linear referencing and data management tools along with the PODS Lite Data Model. PODS Lite, though, is not specific to Esri or the Esri APR extension to the ArcGIS Platform. The next rollout of PODS Lite will support implementation in additional relational database management system (RDBMS) and geographic information system (GIS) environments, scheduled for release in early 2017.

3 PODS Next Generation The PODS Association s Next Generation, or Next Gen, initiative is focused on a complete re-design and modernization of the PODS Pipeline Data Model. The re-design of the PODS Pipeline Data Model is driven by PODS Association Strategy objectives as defined in its Strategic Plan, as well as from nearly 20 years of PODS Pipeline Data Model implementation experience and lessons learned. The Next Gen initiative will result in a new data model the PODS Pipeline Data Model Version 7.0 as well as a Data Exchange Specification and migration and implementation guidance and instructions. The Next Gen Data Exchange Specification will facilitate data translations between the PODS Next Generation Design Principles PAGE 3 Design for the Future The next PODS Pipeline Data Model will be transformational not an incremental update to the existing standard. A Solid Core Coupled with Agility and Flexibility The Data Model will allow for independent extension of the model in a flexible fashion yet in alignment with core modeling and design principles. Support Time and History The Data Model will support time-based events and track asset lifecycle history. Support Location and Spatial Representation The Data Model will provide flexibility to include or exclude spatial representation of assets and events. Support Interoperability The Data Model will support data exchanges between systems and work streams within an organization as well as data exchanges between organizations. Easy to Understand The Data Model will be easy to understand, implement, extend and use. PODS Pipeline Data Model Versions 7.0 and earlier as well as other data models and will also enable system integration via service-oriented approaches. The re-designed Data Model will standardize and modernize data management and reporting across the pipeline industry. The Next Gen initiative is scheduled for completion in The PODS Association will be providing incremental releases of the full PODS Pipeline Data Model starting in 2017 with the release of Version 7.0. As a subset of Version 7.0, PODS Lite offers current and potential future Association members the opportunity to preview the re-designed data model. More information on the Next Gen initiative and outcomes can be found on the PODS web site at What s included in PODS Lite? As a subset of the PODS Pipeline Data Model Version 7.0, PODS Lite provides a data model allowing users to collect and manage data for: Pipeline Hierarchy Defining the pipelines in a system and how they are organized, as well as the ability to define sites and stations and where they are located in space. Linear Referencing Enabling referencing of assets, events and conditions along a pipeline via measures and/or stationing. Linear referencing tables provided in PODS Lite include centerline, centerline sequence, continuous measure network, engineering stationing network and calibration points. It is these tables that enable use of Esri ArcGIS for Pipeline Referencing (APR) extension and toolset. Use of linear referencing tables (and APR) is optional when using PODS Lite. Should users elect to not use the PODS Lite linear referencing tables, location can be collected and managed via XYZ coordinate positions. Assets Installed and in-service product transport or containment devices, when connected end-toend form a pipeline in the ground. Assets may be located by a measured position along a pipeline or

4 PAGE 4 alternately by an XYZ coordinate position. A subset of assets provided in PODS Lite includes pipe segments, coatings, valves, pipe bends, girth welds and pigging launchers and receivers. Conditions Representing the state or condition of a pipeline and representing the results of activities including inspection or analysis (population class study, high consequence area analysis). A subset of condition and operational tables provided in PODS Lite includes inspection range, class, operating pressure (to manage maximum allowable operating pressure or MAOP and maximum operating pressure or MOP), test pressure, consequence segment, pipeline operating condition, pipe jurisdiction and crossings including online, pipeline, utility, hydrology and transportation. PODS Pipeline Data Model Architecture What s Different from Prior Versions of the PODS Data Model The PODS Pipeline Data Model Version 7.0 resulting from the Next Gen Initiative represents a significant departure from prior versions of the PODS Pipeline Data Model. The PODS Pipeline Data Model Version 7.0, and therefore PODS Lite as well, reflect the following fundamental changes from prior versions of the Data Model include the following: Re-Designed Core Data Model A set of core data tables, entirely re-designed, revised and streamlined from prior versions of the Data Model. PODS Lite is a subset of these new core tables. The two most significant changes are that location information are contained in the business tables and the location model supports both event (linear referencing) and feature-based representation of pipeline features. New Approach for Modules Modules are bundles of additional data tables that when used can extend the core tables to store and manage information for specific business processes such as inline inspections (ILI) and reporting requirements. The PODS Pipeline Data Model Version 7.0 will employ new approaches for generation and use of modules. New Data Exchange Specification The data exchange specification will be an XML schema that specifies the format of data exchange XML documents, similar in concept to an Esri XML Workspace. The data exchange specification will allow for the exchange of data that conforms to the PODS Pipeline Data Model. The data exchange specification will also allow for the storage of data that can be transferred between systems, users, software and databases. Improved and Extended Documentation Provided to more guide implementation and use of the new Data Model and to ensure common usage of the data model across all end-user organization implementations. Single Data Model Supporting Multiple Implementation Patterns The PODS Pipeline Data Model Version 7.0 uses a design pattern that is reusable, i.e. can be implemented, in different technology environments. The PODS Pipeline Data Model Version 7.0 can be instantiated (i.e., used in) the following technology environments as shown in Figure 1. Each of the following are referred to as implementation patterns. Implementation patterns describe the underlying physical database software, the mechanism for storing spatial geometry or features within the database, and how spatial data are managed within the database. The core tables, attributes, domains in the data model are considered standard but how they are implemented as physical data bases is dependent on the needs and selected technology environments of the end-user

5 PAGE 5 organization The PODS Pipeline Data Model Version 7.0 will at a minimum support the following four implementation patterns (Figure 1): Figure 1: PODS Pipeline Data Model Implementation Patterns PODS Lite will be available for all four implementation patterns in As of January 2017, PODS Lite is available for the Esri geodatabase implementation pattern only. This is referred to as PODS Lite for APR. What s Common and Different between Implementation Patterns? Common Logical Model The logical model includes the core classes, including attributes, code lists, and relationships that are common across all implementation patterns. The PODS Association maintains a single master logical data model as part of the PODS Pipeline Data Model Version 7.0. Different Physical Database Models and Data Types for Each Implementation Pattern Each implementation pattern is used for a different technology environment including relational database system (RDBMS) or GIS environment (Esri). As a result, the specific physical data models and templates will differ between implementation patterns, While the logical model is always common, the following may be used depending on the implementation pattern chosen by the user: Relational Database Management System software (RDBMS) or technology Examples include Oracle, Microsoft SQL Server, open source databases such as SQLite, MySQL and POSTGIS, Spatial Data Types used to store the geometry of spatial or geographic features within the model examples include Esri s SDE BINARY, spatial data types such as ST_GEOMETRY, native RDBMS geometry types, and the Open GIS Consortium (OGC) Well Known Text (WKT) representation of geometry, Approach for Storing, Editing and Managing Spatial Data within the deployment of the physical model. This may involve the use of versioning or separate layers or tables that contain the feature geometry from tables that include the attribute data describing features in the model. The Common PODS Pipeline Logical Data Model A key objective of the Next Gen initiative is to standardize on and maintain a single logical data model supporting the implementation of multiple physical database implementations. In prior versions of the Data Model (preceding Version 7.0, resulting from the Next Gen initiative), the PODS Association managed multiple logical data model in support of the PODS Relational (including different schemas for different RDBMS platforms) and the PODS Esri Spatial data models. For PODS Pipeline Data Model Version 7.0, resulting from the Next Gen initiative, a single logical data model is maintained. This model includes logical definitions for:

6 PAGE 6 Pipeline Hierarchy used to define the pipelines in a system and how they are organized schematically and located spatially, Linear Referencing (LRS) Location Model describing how elements are located on or along a pipeline using a measured distance along a route, Assets installed and in-service product transportation or containment devices that are regularly inspected and maintained, Conditions representing the state or condition of the pipeline and associated assets, Abstract Classes tables that represent properties and/or behaviors that apply to various other data model elements. For instance, the PODS Pipeline Data Model Version 7.0 Core will include nearly two dozen different asset types including valves, meters, elbows, launcher/receivers, etc. A single Asset abstract class table will define a set of properties common across all asset types including installed date, in-service date, associated site ID, etc. When creating physical data model templates for a given implementation pattern (e.g., PODS Lite for APR, resulting in an Esri geodatabase ready for use in the Esri ArcGIS Platform), all the asset tables in the geodatabase inherit the properties from the single asset abstract class table. Use of abstract classes is a modern best practice approach for managing properties and behaviors in a logical data model. Abstract classes are now used for the first time in the PODS Pipeline Data Model version 7.0, and therefore in PODS Lite as well. Metadata tables used to store supporting documents and notes associated with other data tables and elements in the data model. Data Modeling Approach for PODS Lite The PODS Pipeline Data Model Version 7.0 and PODS Lite logical model is a Unified Modeling Language (UML) application schema conforming to International Standards Organization (ISO) 19109:2005 (Geographic Information - Rules for Application Schema) and ISO/TS (Geographic Information - Conceptual Schema Language). The application schema also conforms to ISO 19136:2007 (Geographic Information - Geography Markup Language (GML) Annex E, section of 19136:2007, which defines a valid input to a standard set of UML to GML encoding rules also defined in Annex E. This standards baseline is being followed for the PODS Pipeline Data Model starting in Version 7.0 and allows for the transformation of the application schema into other models (such as a model conforming to UML profiles for ArcGIS) and physical representations such as XML schema or SQL data definition language (DDL). Additionally, the following high level design principals were also employed to guide the development of the PODS Pipeline Data Model logical model: Shape or Geometry Columns are included in any table representing a geographic feature (in PODS Lite for APR the typical geodatabase Shape column is used). Linear Referencing System Architecture The PODS Pipeline Data Model Version 7.0 and PODS Lite will utilize the Esri ArcGIS for Pipeline Referencing (APR) core tables as a basis for managing linear referencing systems (LRS). These tables form the basis of the APR software but also allow for the storage and management of nearly every conceivable method for storing and managing linear referenced networks and

7 PAGE 7 features. The PODS Lite model adds some additional fields to these tables but they are, in essence, unchanged from the core tables of the APR LRS model. The LRS tables included in PODS Lite can be instantiated for use in other non-esri implementation patterns. The APR LRS tables provide enough flexibility to manage any linear referencing mode or implementation scenario. Use of Different Location Methods in a Single Database The PipelineFeature abstract class is designed to support features that are located by coordinate position and linear referencing or to support the implementation of a NULL geometry. This allows the new logical model to be used to manage a list of pipeline assets, conditions and activities without storing geometry. A benefit of this approach is it provides flexibility for storing (or not storing) the geometry of an entity at the row level, i.e., for individual features or records in the database. Using this approach an entire pipeline system could be managed using coordinates only (akin to a geometric network found in gathering and distribution systems) or the pipeline could be managed exclusively with linear referencing (commonly found in transmission pipeline systems) or most importantly, as a combination of both methods. The PODS Lite data model supports this flexibility for geospatial data management. This is a significant departure from the stationing only design of previous PODS data models. Simplified Class and Attribute Names Class and attribute names were simplified and reduced to the most salient and commonly found descriptors found based on the experiences of the PODS Next Gen Working Group. Classes sharing identical schema have been merged together. The LayerMetaData class can be utilized to define the editing and validation behaviors for merged schemas using definition queries or filters to specify particular data types within a merged table. CamelCase format is used to describe these in the logical model, however, tools used by PODS to create physical database schemas and templates for specific implementation patterns will support an implementation option of using upper case letters and _ underbars in table and attribute names within the physical implementation of the model, when required. Code Lists to Store Valid Values Code lists are maintained in the PODS Pipeline Data Model logical model. When creating physical database schemas and templates for specific implementation patterns, these code lists are instantiated using approaches unique to that pattern. For example, when creating PODS Lite for APR templates (i.e., an Esri geodatabase), the code lists are mapped to Esri geodatabase domains. Later releases of PODS Lite will support both domains (for geodatabase implementations), code lookup tables (for SQL DDL implementations), and code lists (for the XML Schema Data Exchange Specification). Code list values and descriptions are (typically) synonymous. At this publication, the standard definitions for character based domains are 50 characters for the code values, and 255 characters for the descriptions. All attempts were made to keep codes and descriptions in sync and to remove magic numbers or abbreviated code values. PODS Lite as a Subset of the Full Data Model The PODS Pipeline Data Model Version 7.0 contains a more extensive set of tables than what is released in PODS Lite. The subset of tables included in PODS Lite is the minimum set of tables that a pipeline operator would need to implement in order to identify the location of and safely manage the operation of a pipeline. PODS Lite for APR and Esri Relationship Classes The geodatabase implementation of PODS Lite does not contain explicit relationship classes. Since this release of PODS Lite is an Esri geodatabase version and the accepted standard is the removal of relationship classes, this version of PODS Lite will adhere to that policy. Subsequent RDBMS releases of PODS Lite will enforce relationships and referential integrity.

8 PAGE 8 Data Modeling Tools The following software tools and resources are used to author, manage, maintain and document the PODS Pipeline Data Model Version 7.0 logical data model and to create physical database schemas and templates for implementation patterns including PODS Lite for APR: Enterprise Architect Sparx Systems Enterprise Architect is a visually-based modeling and design tool. Enterprise Architect supports robust conceptual and local data modeling activities, generation of artifacts and documentation and supports a broad range of standards and specifications used by the PODS Pipeline Data Model including but not limited to XML, UML, XSD and others. The PODS Pipeline Data Model logical data model, common to all implementation patterns, is managed in Enterprise Architect. ShapeChange ShapeChange is an open source application designed to transform application schemas into a target output. ShapeChange can connect directly to logical models in Sparx Systems Enterprise Architect and automate the process of generating physical database schemas and templates. ShapeChange is used to generate schemas and templates for the Esri geodatabase implementation pattern, including PODS Lite for APR. ShapeChange will also be used to generate an SQL DDL file for RDBMS implementation patterns (DDLs are executed in RDBMS to create an empty database template). ShapeChange is also used to generate XML schemas in accordance with the PODS Pipeline Data Model data exchange specification. Additional Tools Additional software tools are used for generating usable templates for specific implementation patterns, as described below. Data Modeling Processes The following diagrams illustrate and summarize how usable PODS Lite physical database schemas and templates are created from the common PODS Pipeline Data Model. Three processes are summarized; the process to create a PODS Lite for APR geodatabase, the process to create a PODS Lite database template for RDBMS and the process to create a XML schema for PODS Lite using the new PODS Pipeline Data Model data exchange specification Generating PODS Lite for APR Geodatabase Figure 2 depicts how the ShapeChange application is used to generate the PODS Lite for APR logical model from the PODS Pipeline Data Model. PODS Lite for APR is a flattened, subset of the full PODS Pipeline Data Model. The PODS Association makes use of tags in the full PODS Pipeline Data Model, in Enterprise Architect, to flag the subset of model elements to be included in PODS Lite. This approach can be used to quickly create subset profiles of the full Data Model, including PODS Lite and others, quickly and from a single master Data Model. The full PODS Pipeline Data Model is also flattened such that all attributes in a class hierarchy are assigned to the leaf classes. Finally, a logical model is generated as the target by converting the logical model to a model that conforms to the Sparx Systems ArcGIS UML profile this process added Esri-specific attribution. This process converts the classes in the PODS Pipeline Data Model into feature and object classes, the attributes into fields, and the code lists into domains.

9 PAGE 9 Figure 2 - Generating PODS Lite for APR from the Master PODS Pipeline Data Model PODS Lite for APR is available as either an Esri geodatabase (GDB) or an Esri XML workspace document. The following steps are used to generate the PODS Lite for APR templates from the master PODS Pipeline logical data model: Figure 3 - Generating PODS Lite for APR geodatabase 1. Author and maintain the common, master PODS Pipeline Data Model using Enterprise Architect. This includes tagging database classes, attributes and code lists for inclusion in PODS Lite. 2. Transform the master PODS Pipeline Data Model to create a subset logical model of only those elements tagged for inclusion in PODS Lite and to flatten the logical model hierarchy, using ShapeChange. This results in a new logical model stored in Enterprise Architect with only PODS Lite database elements as a model conforming to the ArcGIS UML profile called the PODS Lite for APR Data Model. 3. Generate an Esri XML workspace document from the PODS Lite for APR Data Model, using Enterprise Architect. 4. The XML Workspace document generated from Enterprise Architect is not yet fully ready for use in Esri ArcGIS software. This is the result of a bug within the Enterprise Architecture software (Version 13) that

10 PAGE 10 results in the elements defining a domain being out of order within XML workspace documents. A custom XML style sheet (XSL), prepared by PODS Association, is applied to the Esri XML Workspace document in order to make necessary formatting corrections (placing the elements within the XML file in the correct order) before the XML workspace document is ready to import as a geodatabase utilizing the Esri ArcGIS software. PODS Association uses OxygenXML, a commercially-available XML editing tool, to apply the PODS Lite XSL file to the XML workspace document. Any XML editor tool capable of performing an XSL transformation, commercial or open source, can be used to perform this function. This step will be eliminated once Sparx Systems corrects the bug within their Enterprise Architecture software (Sparx Systems is aware of the bug and are working to resolve). 5. The XML workspace document can then be imported into Esri ArcGIS software (ArcGIS Desktop Standard or Advanced) and a geodatabase (GDB) template generated. This GDB template is now immediately available for use in Esri s ArcGIS for Pipeline Referencing (APR) software. The PODS Association is making PODS Lite for APR available in both GDB and XML workspace formats. Users of PODS Lite will download one of these templates for use, once PODS Association has completed Step #5. 6. An additional set of configuration steps are necessary in Esri s APR software. Instructions to configure the APR software to use the PODS Lite templates can be found in the following document included in this PODS Lite.zip package: PODS Lite Geodatabase Configuration for APR_Final_v1.pdf Generating PODS Lite for RDBMS The PODS Pipeline Data Model Version 7.0, and therefore PODS Lite, can be implemented using multiple implementation patterns, as described above. Implementation patterns for Oracle and MS SQL Server and other RDBMS platforms is illustrated in Figure 4. The focus of the first release of PODS Lite is support for Esri s APR within a geodatabase environment, in order to align PODS with the Esri APR release and to provide an alternative to transmission pipeline operators with pipeline GIS data models that were primarily driven or utilize measure and stationing for locating events along the pipeline centerlines. Future PODS Lite releases will support other RDBMS formats, spatial data types and other physical implementation patterns. Figure 4 illustrates the steps to create a PODS Lite database in RDBMS systems.

11 PAGE 11 Figure 4 - Generating PODS Lite for RDBMS 1. Author and maintain the common, master PODS Pipeline Data Model using Enterprise Architect. This includes tagging database classes, attributes and code lists for inclusion in PODS Lite. 2. Filter the master PODS Pipeline Data Model to create a subset data model of only those elements tagged for inclusion in PODS Lite, using ShapeChange. This results in a DDL file that can then be used to generate database templates in the user s selected RDBMS software (Oracle, SQL Server, other). Users of PODS Lite will download the DDL for use, once PODS Association has completed Step #2. 3. Open the RDBMS Administrative/Management console software for the RDBMS platform, import and execute (run) the DDL file. This will execute standard query language (SQL) CREATE statements to generate tables and other database elements included in the PODS Lite schema. Generating PODS Lite XML Schema for Data Exchange PODS Lite users can also utilize the new XML-based data exchange specification to import, export and transform data to and from the PODS Lite (and PODS Pipeline Data Model Version 7.0) schema. At this time, users will be responsible for developing the automation routines, software or services to read/write to the data exchange specification. In time, it is expected that a set of software tools will be developed by service providers that will enable use of the data exchange specification. However, for early adopters and interested parties, the data exchange specification will be available for evaluation. Figure 5 illustrates the steps used to create the data exchange specification.

12 PAGE 12 Figure 5 - Generating PODS Lite XML Schema for Data Exchange 1. Author and maintain the common, master PODS Pipeline Data Model using Enterprise Architect. This includes tagging classes, attributes and code lists for inclusion in PODS Lite. 2. Filter the master PODS Pipeline Data Model to create a subset data model of only those elements tagged for inclusion in PODS Lite, using ShapeChange. This results in an XML schema document (XSD) structured using the PODS Lite logical model (i.e., includes tags that allow for storage of data organized by the PODS Lite schema). Users of PODS Lite will download the XSD for use, once PODS Association has completed Step #2. PODS Lite Package (PODS Lite.zip) PODS Lite is free and available to all. Several of these resources are specific to PODS Lite Geodatabase for APR (i.e., use of PODS Lite in an Esri geodatabase format) these are noted below. This list will be updated as PODS Lite is released for other RDBMS and GIS platforms. The following PODS Lite resources can be found and downloaded from Filename Title and Description 1 PODS Lite README List of Documents.pdf PODS Lite README List of Documents A comprehensive list of all of the documents contained within the PODS Lite.zip file, with brief descriptions, titles and filenames (note the content of this doc is the same as the Readme.txt document, only prettier.) 2 PODS Lite Executive Summary_Final_V1.pdf PODS Lite Executive Summary (this document) A big-picture overview of PODS Lite, Next Generation and the PODS Association read this document first.

13 PAGE 13 Filename 3 PODS Lite Technical Overview and Guide_Final_V1.pdf Title and Description PODS Lite Technical Overview and Guide (this document) A comprehensive technical overview of PODS Lite and its relationship to the PODS Pipeline Data Model. The document is intended for individuals deploying, configuring and extending the PODS Lite data model and for individuals wishing to understand new procedures being used by the PODS Association to manage and maintain PODS Lite and the large PODS Pipeline Data Model. A technical user of the PODS Pipeline Data Model should be able to understand how the model is designed and how it can be implemented after reading this document. 4 PODS Lite Conceptual Model Diagram_Final_V1.pdf 5 PODS Lite Logical Model and Data Dictionary_Final_V1.pdf 6 PODS Lite Geodatabase Data Dictionary_Final_V1.pdf PODS Lite Conceptual Model Diagram A poster-sized diagram showing and describing the conceptual design for the PODS Lite Data Model. The Diagram shows and describes the classes, attributes, relationships between the classes and the pre-defined code lists contained in the model. The Conceptual Model Diagram is a recommended starting point to help users of PODS Lite understand what is included and how the data model is structured. PODS Lite Logical Model and Data Dictionary The global PODS Lite Logical Data Model and Dictionary (applies to all physical implementations regardless of target database - APR, Geodatabase, Oracle, PostGres). This document is intended to be a guide on describing how data are stored in each class in the model and presents a first pass at data governance for how data are created, retrieved, updated and deleted to and from these tables. PODS Lite Geodatabase Data Dictionary A data dictionary of the physical PODS Lite Model implemented in an Esri Geodatabase. It contains a complete listing of feature and object classes, fields, and domains of the physical model in a geodatabase. As such, it does not contain the full documentation of abstract classes and data types found in the PODS Lite Logical Model and Data Dictionary. Therefore, the two data dictionaries should be used together to fully understand and implement PODS Lite for APR.

14 PAGE 14 Filename 7 PODS Lite XML Workspace with CRS Not Defined_Final_V1.xml Title and Description PODS Lite XML Workspace Document with Coordinate Reference System (CRS) Not Defined An Esri XML Workspace document for the purpose of creating a PODS Lite geodatabase using Esri ArcDesktop ArcCatalog software. Use the PODS Lite Geodatabase Configuration Toolbox.tbx document provided in this package to set the coordinate reference system and all appropriate coordinate tolerances. 8 PODS Lite Geodatabase EA Physical UML_Final_V1.eap PODS Lite Geodatabase Enterprise Architect (EA) Physical UML A PODS Lite Geodatabase physical model in Enterprise Architect format. From this model, an Esri XML workspace document is generated for the purpose of creating a geodatabase using Esri ArcGIS Desktop ArcCatalog. Fully supports ESRI APR. 9 PODS Lite Configuring a CRS in EA_Final_V1.pdf PODS Lite Configuring A Coordinate Reference System in Enterprise Architect (EA) A guide for how to define a coordinate reference system (CRS) in the PODS Lite Geodatabase Enterprise Architect (EA) physical data model. 10 PODS Lite Geodatabase Configuration for APR _Final_V1.pdf PODS Lite Geodatabase Configuration for Use With ArcGIS for Pipeline Referencing (APR) A full listing of the steps to download, install and configure a PODS Lite geodatabase for use with APR. Note: this is not intended to replace full documentation for APR as provided by Esri. 11 PODS Lite Geodatabase Configuration Toolbox.tbx PODS Lite Geodatabase Configuration Toolbox A toolbox containing two Python scripts, presented as ArcToolbox tools. The first tool uses the PODS Lite XML Workspace with Undefined CRS_Final_V1.xml document (described above) to create a geodatabase automatically. The second tool allows the user to browse for their own XML workspace document in order to create a geodatabase. Both tools allow the user to set up the CRS of their choice. 12 Readme.txt Readme An unformatted version of the PODS LITE README List of Documents_Final_v1.pdf.