In the last post we loaded the APDM 5 / PODS ESRI Spatial 5 LineLoop table. Prior to that we loaded StationSeries. One task remains to complete the pipeline centerline; we’ll finish by loading ControlPoint.

In the last post we unveiled a free tool to load centerline features (LineLoop, StationSeries and ControlPoint) in a PODS ESRI Spatial 5.0 or APDM 5.0 geodatabase and wrapped up the topic of centerline loading. It’s almost time to actually load features (facilities data, etc.) into the geodatabase. But first, a few words on event-based and feature-based APDM implementations…

Both PODS ESRI Spatial and the APDM are based on ESRI linear referencing concepts; features can be located on the pipeline centerline via measure (or station) values. ArcMap can actually render spatial features on-the-fly using just tabular information containing route (line) and measure (station) information. This mechanism is referred to as route event layers.

The APDM provides options for storing online features as feature classes, or as object classes which can then be used to create route event layers in ArcMap. These are referred to as the feature-based and event-based implementation options, respectively. Each has its own pros and cons:

Feature-based pros:

• Fast display performance – ArcMap is simply reading the shapes and displaying them, rather than building them (as is the case in an event-based implementation).

• All online features have their own shapes – Shapes can be used independently of ArcMap and are accessible for other uses (particularly if you use an OGC-compliant storage mechanism in ArcSDE).

Feature-based cons:

• Editing is complicated – Every time a centerline edit is made, all affected online features have to be updated, too. This is not a problem if you are using nifty software like Eagle’s PDMT suite, but manual editing can be painful.

• Pipeline reroute operations are time consuming – In our simple example we have no station equations, so this is not a problem. But someday, you’re going to have to perform a reroute. This will insert a station equation, introduce a new engineering station series feature on the line, and most importantly, alter the measure length of the line. Since the online features store measures in their shapes, all online features ‘downstream’ of the reroute must have their shape measure values updated. Updating shape measure values is considerably more time consuming than updating measure value attributes, and increases the compute time for the reroute operation.

Event-based pros:

• Ease of manual editing – Shapes for route event layers are derived from the centerline; when the centerline is edited, all events automatically move with the centerline. If you implement a geometric network based on StationSeries and ControlPoint, then the centerline features move together during edits, making centerline edits nearly painless. (More on geometric networks in future posts.)

• Pipeline reroute operations are less time consuming – Since there are no persisted shapes to monkey around with, the performance issues affecting feature-based reroute operations do not apply.

Event-based cons:

• Slow display performance – ArcMap renders event layer shapes on-the-fly and stores them in memory, so first-time draws of route event layers can be slow. Slow display performance can be mitigated to some extent by carefully managing display scales, caching, etc.

• Event layer features are available only within ArcMap – The source object classes do not contain a Shape column, so shape information is not accessible to external applications.

• Event editing can be problematic – The only way to alter an event’s location is to modify its measure/station value(s).

• Support for the CLEditResponse domain is limited – More on this below.

CLEditResponse is a subtle, but potentially important bit of metadata for online features. It describes how the location of a feature is defined, and what happens to a feature’s location when the centerline is edited. CLEditResponse has three values: RelativeProportional, and Absolute.

The Relative domain value indicates that a feature’s location is determined solely by its measure/station information; this is how route event layers work by definition:

The Proportional domain value indicates the feature’s position is determined by its percentage distance along the segment bounded by the surrounding control points. If the measure/station value of a surrounding control point changes, the position of the feature relative to the control point does not change. Rather, its measure/station value changes:

The Proportional CLEditResponse domain value is problematic for an event-based implementation. (Although it is workable with additional code logic.)

Finally, the Absolute domain value indicates a feature’s position is determined solely by its X/Y value. Needless to say, this is not possible with an event-based implementation:

If you are just starting out with the APDM, and don’t have any third-party software tools, an event-based implementation is easier to maintain manually. And, it’s relatively easy to convert to a feature-based implementation at a later date, should you desire. However, the PODS Association currently defines only a feature-based implementation for PODS ESRI Spatial. If you want an event-based implementation of PODS ESRI Spatial, contact PODS and suggest the enhancement.