Home > About > Why PODS?

Why PODS?

There are many reasons that pipeline operators and service providers have chosen to become members of the PODS Association, implement databases and write PODS applications. These include the following:

  • Many Pipeline operators begin with the Pipeline Integrity Management requirements and the need to improve operations and data management. Integrity Management is one of the leading businesss drivers for using PODS.
  • The PODS Association, started in 2000, has a strong membership base and a solid reputation in the industry. It is member driven and business need driven.
  • PODS is widely accepted in the pipeline industry and has a proven track record with many successful implementations.
  • The PODS model has a large number of service and software providers that understand and support the model. This helps avoid custom software development and avoids "reinventing the wheel."
  • PODS may be implemented with the ESRI Geodatabase and other GIS platforms, providing a high degree of integration with GIS desktop and web-based applications.
  • The PODS model is a vendor-neutral data model and is not proprietary to a vendor. The PODS I.P. is owned by the PODS Association, Inc.
  • The PODS data model supports most of the data needs of pipeline operators for pipeline integrity management. This includes Physical pipe and fittings, Inline Inspections, Regulatory, Physical Inspections, Cathodic Protection and many others.

Considering Migrating?

If you are using PODS, there is a good chance that you need to need to migrate data into PODS when you acquire new pipeline assets. Pipeline operators considering a move to PODS should consider the following items too.

Paper Drawings to PODS

Many PODS member service providers offer data conversion services to take paper and CAD-based alignment sheets, detail drawings, spreadsheets, maps and other records into a PODS data model. This process includes converting pipeline data, survey notes, the pipe centerline location and off-line features. Keep in mind that it is not necessary to populate all of the PODS tables. Often pipeline operators convert the most critical data first, staging their conversion to meet integrity, mapping and other business needs.

Legacy Database to PODS

Many PODS member service providers also offer migration of data from existing legacy databases into a PODS database. These databases may include Access, mainframe or proprietary third-party databases. Before migration begins, a data mapping process from the legacy system to the PODS model is performed. This helps identify any database tables or fields the may need to be added to PODS. It also helps ensure that "no data is left behind."

ISAT to PODS

Since PODS originated from ISAT (Integrated Spatial Analysis Techniques), pipeline operators that have migrated from ISAT implementations have discovered that the migration is fairly straight-forward. This heritage can be seen in some of the common table names and in the general approach to data model design. Because of the common use of the Station_Series table between ISAT and PODS, this has helped ease the migration effort as opposed to migration from some legacy systems. The primary tasks when migrating from ISAT to PODS include:

  • Population of PODS domain tables - PODS has separate domain (lookup) tables as opposed to one primary LIST_DOMAIN table
  • Domain Values - In most cases, PODS uses actual data values (text and numeric) for foreign key values, whereas ISAT uses token numeric keys. For example, ISAT may store a value of 1305 for the pipeline diameter foreign key for 30" pipe. In PODS, a numeric value of 30 is used to represent 30" pipe.
  • Creation of Routes - PODS allows linear featurs to span Station Series and therefore multiple contiguous ISAT Station Series segments are combined into a PODS Route and Series.
  • Core Tables - Data in the Point_Connection and Series_Connection tables are used when migrating to PODS, although these tables are not explicitly in PODS.
  • Event Id's - New PODS Event_IDs and other token primary keys must be created when loading data into PODS.

APDM to PODS

APDM is similar in many respects to the ISAT structure and therefore data migration is similar to an ISAT migration. Operators migrating from APDM to PODS may want to consider an ESRI Geodatabase implementation of PODS. Primary tasks to consider when migrating from APDM to PODS include:

  • Domains - Converting Geodatabase numeric domains into PODS text and numeric domains, storing actual values in PODS.
  • Creation of Routes - PODS allows linear featurs to span Station Series and therefore multiple contiguous APDM Station Series segments are combined into a PODS Route and Series.
  • Variations in APDM implementations - As a template, variations may exist in implementations by different service providers, especially in non-core tables.

PODS and APDM are working together to develop an ESRI Geodatabase spatial implementation that will be called the PODS ESRI Geodatabase.