4 Modifying Extending PODS 7 Modifying Extending PODS

4 Modifying & Extending PODS 7

Modifying & Extending PODS 7 Unit 4 – Customizing PODS 7 to Your Organization

Intended Audience • GIS/IT professionals • New to pipeline industry • Little or no exposure to PODS Training – both PODS Basics and PODS Advanced – create a better understanding of PODS Standards and PODS implementations through geospatial and relational database applications.

4 Modifying & Extending PODS 7 A training in PODS 7 Implementation and Customization Answering the Question: Where does my data go?

Webinar Series Overview • Unit 1 – Introduction to PODS 7 • Unit 2 – Unwrapping PODS 7, Part 1 • Unit 3 - Unwrapping PODS 7, Part 2 • Unit 4 – Modifying & Extending PODS • Unit 5 – Introduction to Utility Network • Unit 6 - Information and Analysis – Risk and Reports

Introduction

Conceptual Model

4 Modifying & Extending PODS 7 • • • Implementing and Extending PODS 7 PODS Design Flexibility Populating PODS 7 with creation scripts and your data Extending PODS 7 with Modules Where does my data go?

Our Goals for this Unit 1. Gain exposure to PODS 7 Logical and Physical models. 2. Understand how PODS 7 can be implemented and extended in your organization. 3. In PODS implementation, know where your data goes and how it gets there.

PODS 7 Conceptual Model

PODS 7 Organization Conceptual Model Logical Model Physical Model Documentation Enterprise Architect Shape. Change • These are the ‘parts’ that make up the PODS 7. 0 model • It is a little more complex than just a model • It is good to know the terms that are being used Metadata

Conceptual Model Concepts, entities and relationships between them Helps in understanding and teaching the problem domain (concepts, things) • Organize thoughts into concepts • Identify entities and establishes relationships between them • Helps in documenting and understanding the problem space without • Focuses on the important concepts (things) • Non-intelligent Graphic Drawing (VISIO) • Conceptual/Logical Model Poster

Logical Model Geographic Mark-up Language (GML) Standard Provides a framework or foundation that can be used for documentation and extending the model (standard, agnostic) • All objects in logical model stored as Open GIS Consortium (OCG) Geographic Mark-up Language (GML) objects • Translates concepts into geographic, mark-up language objects (abstract classes, code-look ups, tables, relationships) • Manages model elements and all documentation in a single repository (not different for different RDBMS or spatial geo-data models) • Uses industry standard Sparx System Enterprise Architect software

Physical Model Physical Logical Model AGeographic physical schema Mark-up in a Language physical (GML) database Standard Allows Provides users a framework to implement or foundation the schema that in acan database be used platform for documentation of their choice and extending the model • Actual database in industry standard relational database management system software (Oracle, MS SQL Server, Postgre. Sql) • Tables, relationships, constraints, indexes • Spatial data as attribute or published to separate ‘layers’ • Can use the ESRI Geodatabase or not (specific (standard, RDBMS/GIS) agnostic) • XML/PY = Geodatabase, SQL for RDBMS

Documentation Logical Model Documentation Geographic Mark-up DDL/XML Scripts Language (GML) Standard Metadata Records Provides a framework or Data Dictionaries foundation that can be used Models for documentation and Technical Issues extending the model Executive Summary (standard, agnostic) • Document the data model and all the artifacts in the release • Executive Summary • Technical Documentation/Issues • Document how to deploy the model • Document the scripts to implement the model • Data Dictionary including data governance and structure rules

Enterprise Architect Logical Model Enterprise Geographic Mark-up Architect Language (GML) Standard Provides a framework or Cool stuff about thisused foundation that can be software and for documentation extending the model (standard, agnostic) • Ultimate modeling and design tool suite • www. sparxsystems. com • Allows PODS to have ‘one-model’ • Supported by wide-user base • Supports RDBMS (SQL) and ESRI Arc. GIS Implementations (ESRI XML Workspace) • Supports OGC GML

Shape. Change Logical Model Shape. Change Geographic Mark-up Language (GML) Standard Provides a framework or Translates one EA file to foundation that. EA can be used another FIle for documentation and extending the model (standard, agnostic) • Open source software for translating from one EA model to another • https: //shapechange. net/ • Allows translation from OGC GML Logical Model to Oracle SQL, SQL Server SQL, Post. Gre. SQL, ESRI Arc. GIS XML EA Models • Allows translation to support ESRI Arc. GIS Geodatabase for APR and ESRI Arc. GIS for non-APR • One file will translate all formats • Support potentially available for my. SQL and SQLite (Spatia. Lite) and Geo. Package formats

Meta. Data Logical Model Meta. Data Geographic Mark-up Language (GML) Standard Table. Meta. Data Attribute. Meta. Data Provides a framework or Code. Lookup. Domain foundation that can be used Code. Lookup. Values for documentation and Code. Lookup. Cross. Ref extending the model (standard, agnostic) • Contains the metadata describing the base-level installation of modules • Loads the table listing, attribute listing, code-lookup listing, Type 1 domain/code look up enumerations and cross. Reference between attributes and assigned domains • Designed for software vendors to be able to access information about the data model as implemented

PODS 7 is extendable and adaptable PODS 7. 0 is an extendable and adaptable model that can be used to generate several physical implementations and data exchange specification schemas.

Structuring PODS Content • Classes and attributes • Enumerations • Code Lists

What is a Code List? There are 3 Types of Code Lists: 1. Enumerators 2. Managed Code Lists 3. Unmanaged Code Lists

Why are Code Lists Important? • Enforces Data Integrity • Data Standardization • Data Entry

PODS CODE LIST TYPES Enumerations All possible values are permanently fixed at the time of standardization.

Enumerator Example

PODS CODE LIST TYPES Managed Code Lists Most possible values are permanently fixed at the time of standardization.

Managed Code List Example

PODS CODE LIST TYPES Unmanaged Code Lists Values in the list are examples and not managed by PODS.

Unmanaged Code List Example

Documenting PODS 7 • Data dictionaries – 3 types of data dictionaries can be generated from logical and physical model implementations: • Logical Model • Arc. GIS • SQL • Metadata scripts

PODS Design is… • Flexible • Extensible

Populating the Model • Creation Scripts • Not usually 1 -to-1 data mapping • Likely to be a combination of data loading and extending the model

PODS Creation Scripts • Generated from Schema diagram by Shape Change app • Different sets of scripts for different implementations • PODS-7 -0 -USER DOCUMENTS. zip • PODS-7 -0 -LOGICAL MODEL FILES. zip • PODS-7 -0 -GEODATABASE FILES. zip • PODS-7 -0 -SCRIPTS AND DATA DICTIONARIES-ALL. zip

For example…PODS 7 Site Structure Gathering System Pipeline (Record) Pipe. Segments Wells Branch. Connect Gathering systems located by XY, no linear referencing – can be Site Record with PODS Lite implemented 1. 1/7. 0 Distribution System Transmission System Site. Boundaries Pipeline (Record) Site. Centroids Site. Layouts Site. Pipeline. Locations Pipe. Segments (XY) Misc. Fitting (XY) Site Record Network Route (XYZM) Pipe. Segments (M) NR Valves (M) NR Branch. Connect (M) NR Transmission systems, typically located with XYZM for routes, features are events (measure) – can be implemented with PODS Lite 1. 1/7. 0 Distribution systems (as gathering, but with utility network) – can be Site 1. 1/7. 0 Record implemented with PODS Lite

Compare with PODS 6 – Site Table

Extending the Model - Modules - primary mechanism for extending PODS • Create a module package • Extend the model by adding attributes, classes, creating/modifying code lists and/or enumerations new data associations to the base POD model.

Extending the Model Documentation • Documentation is KEY. • Guidance, step-by-step instructions, and rules for creating/modifying modules • Ensures model and data quality as well as alignment with the PODS 7 standards.

Extending the Model Validatation • Model validation step ensures that all the rules have been correctly implemented. Validating a Module: Step 1 - Select the application schema package containing the module that you want to validate. Step 2 - Right-click, navigate to and select the Validate. Module script (under Specialize→Scripts in EA 14. 1).

Where does my data go? Into the existing PODS model Or Into modules you create and integrate with PODS 7.

End of Unit 4 Any questions?

Resource for PODS Association web site This Unit https: //www. pods. org