Architectural Principles Coordinates

This section defines a consistent method for positioning all objects from the database in multi-dimensional space. The horizontal components of those coordinates typically are treated together as a pair of values, while the vertical coordinate is treated independently.

Horizontal coordinates include northing, easting or x, y values (referred to as Grid coordinates) and latitude, longitude pairs (referred to as Geographic coordinates). Vertical coordinates usually refer to height, elevation or depth.

Contents 1 Objectives 2 Guidelines 2.1 Spatial tables 2.2 Coordinate Values 2.3 Guidelines 2.3.1 General 2.3.2 Versions 2.3.3 Key structure 2.3.4 Groups of positions 2.3.5 Polygons 2.4 Elevations and Depths 2.4.1 Regional Vertical Datums 2.4.2 Local Vertical Datums 2.4.3 Depth Reference 3 Back to Architectural Principles Index

Objectives

1. Provide consistent positional information for objects.
2. Allow multiple versions of positional information.
3. Support a "selected" row of data that contains the preferred version.
4. Provide sufficient geodetic information including geodetic datum and coordinate projection to identify the positional data.
5. Provide sufficient acquisition information to identify the acquisition method and estimated accuracy of the positional information.
6. Support the display of positional information with high-speed response.

Guidelines

Spatial tables

1. Spatial coordinate information is stored in the tables named SP_%, except for well and seismic locations. For these two location types, in PPDM 3.8 you may use either the module specific location tables or the Spatial tables. Note that this use will be integrated into a single method in PPDM 3.9
2. A link between spatial information in the SP_% tables and the business table must be captured in SP_COMPONENT. If you fail to populate this relationship, the spatial information will not contain proper contextual references to its parent business object.

Coordinate Values

1. Maintain horizontal coordinate values everywhere as Geographic values (latitude, longitude). Wherever possible, only the Geographic values should be kept; by keeping only one set of horizontal values, data integrity issues are minimized (you don’t have to keep two sets of coordinates in synch with each other).
2. Also maintain as Grid values (northing, easting) where these represent the original units of measure, or where a compelling business case exists to store them (seismic processing often uses local coordinates, for example).

Note: metes & bounds form an additional set of horizontal coordinate values that are handled in Legal Survey Area. Data integrity concerns need to be handled procedurally.

1. Coordinate values must include either a grid projection code or a geodetic datum to describe or qualify the coordinate value.
   1. Latitude, Longitude values must be referenced to a coordinate system. The coordinate system references datum, spheroid and ellipsoid information, and shows relationships (transformations) between geodetic datums.
   2. Northing, Easting values will be qualified by including an appropriate grid projection (Called MAP_PROJECTION) code. The grid projection points to a reference table that includes projection parameters and is associated with the appropriate projected coordinate system.
2. Coordinate values may also include acquisition activities that will demonstrate the method and estimated accuracy of coordinate capture. This information is captured in COORDINATE_ACQUISITION_METHOD

Guidelines

General

Generally keep individual coordinate values in a point table that defines the abstract notion of the object position and the "selected" or "preferred" value of the coordinate location. Nodes are permanent positions having long term significance. Survey points along the drill bore or seismic points are not nodes.

Versions

Keep versions of coordinate data in a %_version table. These data versions reflect different vintage, units, sources, methods of calculation, and/or methods of acquisition.

Key structure

The node and %_version table should contain either a natural key or a secondary natural identifier sufficient to uniquely identify the row.

Groups of positions

Where coordinate values are naturally grouped together (such as seismic lines, pipelines, land polygons...) keep the versioning information such as datum, source and acquisition data at the group level.

Polygons

All objects that have polygonal spatial representations should use the SPATIAL module to describe those locations. Provide a FK from the business object into the table SPATIAL DESCRIPTION.

Elevations and Depths

Regional Vertical Datums

All elevations are defined by a reference to a vertical datum, whether directly or by convention. Keep vertical datum information at the Meta table level.

Local Vertical Datums

Currently elevation datums are not kept but understood to be a reference to a local vertical datum (i.e. NAVD29 relative to mean sea level), with few obvious problems. Where vertical datums are mixed then vertical datum information needs to be kept at the row level. Note that international requirements have increasingly driven this information to the table level.

Depth Reference

Maintain reference measurement point for depths. All depths are defined relative to some reference point. (i.e. measured depths in a wellbore are defined relative to a surface reference point such as the Kelly bushing) Keep depth reference point at the row level in the WELL table. For seismic information, keep with the seismic tables.

Back to Architectural Principles Index