In the previous post we examined PODS at a high level; here we examine the ArcGIS Pipeline Data Model (APDM) and compare and contrast it with the Pipeline Open Data Standard (PODS).
The APDM differs from PODS in important ways. First and foremost, as its name implies, the APDM is dependent on ESRI ArcGIS technology. Unlike PODS, the APDM works only with ArcGIS. If your company does not currently use, or is not at least considering the use of ArcGIS, then the APDM is not the right fit for your organization.
The APDM is an ESRI Geodatabase model. In an enterprise-level installation the geodatabase is implemented within a Relational Database Management System (RDBMS) such as Oracle or Microsoft SQL Server, as shown below.
Geodatabase technology is fundamentally object-relational technology. Even though the geodatabase is contained within the RDBMS, it is not purely a relational database. This leads to several interesting differences with respect to a relational database:
- Under most circumstances, Structured Query Language (SQL) cannot be reliably used to access or manipulate the data in a versioned geodatabase
- Although the geodatabase implements relationship classes and utilizes code domains, relational integrity is not strictly enforced
On the other hand, ESRI geodatabase technology provides functionality that is not available out-of-the-box in an RDBMS:
- Long transaction capability is built-in to the geodatabase via versioning
- History tracking is built-in via archiving
- Complex topology management is built-in via geometric networks and topologies
- And most importantly, the geodatabase is spatially enabled out-of-the-box
By virtue of its underlying object-relational framework, the APDM takes advantage of a data modeling concept known as inheritance. Inheritance facilitates the creation of a class hierarchy; classes at the end of the inheritance tree automatically inherit the content and behaviors of their ancestors. (The ancestors are referred to as abstract classes.) All feature classes and tables in the APDM are categorized according to their abstract class inheritance. Pipeline-specific abstract classes include, for example, categories such as online facility features. Mainline valves are classified as online point facility features.
As a result of the use of abstract class data categories, the APDM is a template-based data model. This affords the APDM a much higher degree of flexibility than a standards-based model such as PODS. As long as the abstract class hierarchy is adhered to, the APDM can be readily customized to suit your company’s particular needs. A software vendor (or in-house developer) that designs applications to work with the APDM abstract class framework can easily support wide variation in data model content without resorting to software modifications.
Although SQL data access is not a strong point of ESRI geodatabase technology, there have been recent improvements on this front. Be aware, however, that taking advantage of these improvements tends to compromise some of the long transaction functionality of the geodatabase. A better way to interact with the geodatabase at a low level is by employing Service Oriented Architecture (SOA) technologies. Web services are the primary components of an SOA; ESRI’s ArcGIS Server technology platform provides a robust mechanism for implementing web services for use with the APDM.
The APDM might be a good fit for your organization if:
- Your company already makes use of ESRI geodatabase technology
- Your company is willing to maintain relational data integrity via application logic
- Your company is already making use of SOA technology
- Your company views data model flexibility as important
- Your company is committed to ArcGIS as the GIS technology of choice
- Your company views the ability to incorporate a wide variety of ESRI-based, third-party tools as important
For the latest on the APDM, check out What's New in APDM Version 5.
Next, we'll take a look at the newest of the pipeline data models, PODS Spatial.