Skip to end of metadata
Go to start of metadata
Information about coordinate system attributes in the Integrated Observatory

This information consolidates a number of relevant resources and analyzes coordinate systems and transformations that will need to be represented by Integrated Observatory attributes.

Table of Contents


Statements in this discussion are based on (or at least framed by) ISO 19111:2007 unless referenced to another source.


Key Definitions

  • coordinate reference system (CRS): coordinate system + datum; types include geodetic and vertical
  • coordinate system (CS): mathematical rules specifying how coordinates are assigned to points; composed of coordinate system axes; types of interest to use are ellipsoidal (earth shaped, 2D or 3D) and vertical, and the compound type
  • datum: parameters to specify the relationship of a coordinate system to an object (Earth, in all our geospatial cases); defines position of origin, scale, and orientation of the CS (note that [13] references two definitions for datum, we are using ISO [7] for our reference definition)


Recommended Geodetic and Vertical CRS specifications (including CS and datum)

Geodetic (geospatial_geodetic_crs)

For GPS-derived latitude/longitude values, the CRS is ellipsoidal with the datum WGS84/EPSG4326; we will use the datum identifier of

Values derived per the North American standard NAD83 may use the datum identifier

Vertical (geospatial_vertical_crs)

The best vertical CRS available in EPSG is NAVD88 height, but this has the unfortunate characteristic that it is expressed in height, rather than depth. We may have to choose between this option, and the dual specification of NAVD88/EPSG 5103, North American Vertical Datum 1988 (URI: and
the vertical coordinate system of "depth, in meters" (URI:

There is also an inherent conflict opportunity when specifying a vertical CRS, and allowing the user/data to specify any units for vertical coordinates. (Because the vertical CRS already specifies the units.) This is handled in Release 2 by specifying that geospatial_vertical_units takes precedence, but a better solution would be sufficient vertical CRS options to support all possibilities.

The vertical datum of instantaneous sea level is probably the most appropriate for below-sea-level values (and above, if a GPS reference isn't available or a sensor is always at a fixed offset from sea level). Searching on EPSG 5113 finds several examples/discussions of its use in combination with a CRS.



The longitude min/max attributes must be capable of specifying bounding boxes and data sets that straddle the 180th meridian (but not necessarily the prime meridian). The only way it can do that one attribute as: "the most western longitude (if the value is larger than the maximum longitude, the bounds fall on either side of the 180th meridian, and the enclosed area includes that meridian)", and the other as "the most eastern longitude". This should really get the name geospatial_longitude_limit_west, or similar, rather than "minimum" and "maximum". This specification is consistent with ISO 19115, which names westBoundLongitude and eastBoundLongitude as the limits, not minimum and maximum; and consistent with EPSG descriptions [14].

The latitude min/max attributes should follow the longitude case for consistency. (Thus, "the most northern latitude" and "the most southern latitude".)


The following definitions characterize the most typical use of vertical minimum and maximum in current standards.

  • geospatial_vertical_max: specifies the (numerically) maximum vertical position; if the vertical/z axis positive (geospatial_vertical_positive) is down, the maximum value will be closer to earth center than the minimum value
  • geospatial_vertical_min: specifies the (numerically) minimum vertical position; if the vertical/z axis positive (geospatial_vertical_positive) is down, the minimum value will be further away from earth center than the maximum value

Reference this plot for a visual view of this explanation, which covers the "Depth" orientation on the right half of the diagram.

Mounting Position Including Orientation

Often the position and orientation of a device in geospatial terms must be derived from its position and orientation relative to (a chain of) parent devices, with the chain ending with a device that is has known geospatial location and orientation. A classic oceanographic example is a wind sensor mounted on a buoy; the wind sensor reports wind direction relative to its local frame of reference, which must be aligned to the buoy's frame of reference according the mounting angle. The buoy's rotation relative to Earth azimuthal directions must be considered to determine the wind direction being reported. Underwater, acoustic doppler current profilers (ADCPs) may demand similar algorithms, and may also have to consider pitch and roll of the mounting platform.

A second use case for knowing exact positions and orientations of devices, relative to the platform on which they are mounted, is to create visualizations — possibly on the fly — of the assembled platform.

Because most platform specifications explicitly include the physical location and orientation of each predefined mount point, providing these attributes is often reasonably straightforward.

A thorough description of the possible and optimal strategies for representing geospatial and engineering coordinate reference systems is given in [4], and many of the other references provide useful discussion of the process of combining these reference systems.

The description of mounting position and mounting orientation presumes the existence of a labelled coordinate reference system specifying the X, Y, and Z axes and directions on the mounting platform. Typically, this is also described as part of the mechanical specifications of the platform.

Mounting Position

The mount position indicates the location of a device relative to the device (usually a platform) on which it is mounted. This value is specified in offsets along the X, Y, and Z axes, with more positive offsets indicating the device is further along the positive direction of the axis on the mounting platform. An offset of 0 for an axis indicates the device is at the defined axis origin.

Mounting Orientation

The mount orientation indicates which way a device is pointing — where the pointing direction is defined as the direction in which its sensor is pointing, unless another direction has been specified — relative to the device (usually a platform) on which it is mounted. References [4], [21], and [22] may be helpful in understanding the means of specifying pointing direction, and the necessary naming and transformations of the local coordinate systems. For Release 2, Z is assumed to be in the direction of view. (If the sensor pointing angle is offset from the physical x-y-z orientation of the device, in Release 2 this must be taken into account in specifying the mount orientation to include the sensor pointing angle offset.)

In Release 2, the mount orientation is specified as 3 rotations around the corresponding X, Y, and Z axes. Each rotation is specified in degrees clockwise (looking in the positive direction of the axis). The rotations are taken in succession — first around the X axis, then around the rotated Y axis, then around the twice-rotated Z axis.

Several aspects of this Euler-angle scheme are less than optimal, as is discussed in some of the references (e.g., [3], [4]). It was chosen for Release 2 because of its conceptual simplicity. More sophisticated representations may be adopted for Release 3 or future releases, as they become important. (The system is extensible, capable of using additional methods to specify orientation in future releases.)

Mount Names

Ideally, it is possible to label each mount point on a platform model, and then use the name (e.g., Attach Pt Cage #3) as an identifier for the mounting attributes. We do not offer this option in Release 2, since objects like MountPosition are not persisted. This capability is a worthy improvement for Release 3, and may be achieved by using a frame of reference concept for the mounting information.



External References

Reference Topic Content Link Comments
1 Sensor standards IEEE 1451 site (NIST)
2 Geospatial coordinates NetCDF metadata
3 Coordinate systems Euler angles
4 Reference Systems metadata 2011 article on specifying reference systems
5 Coordinate systems axes conventions
6 Coordinate systems rotations overview
7 Coordinate systems standards ISO 19111 ISO 19111.2007(E); for sale by ISO  
8 Geodetic CRS example of existing data set CRS
9 CRS terms SWE terms (definitions) for sensor ontology work
10 CRS example SSDS data model
11 Time format ISO8601 standard allegedly a CRS, but I don't think so
12 Datums Geodetic Datums updated 2008
13 Datums geodetic datums FAQ  
14 Bounding Boxes EPSG About Bounding Boxes  
15 CRS terms EPSG Registry lots of types and cases
16 Datums WGS84  
17 Registered terms NERC Data Grid term browser  
18 CRS terms NERC Data Grid vertical datum terms (registry) collection of possibly useful datums
19 CRS terms EPSG help pages terse, but helpful and aligned with ISO
20 CRS terms related UDUNITS  
21 CRS terms OGC Name Type Specification for CRSs OCG 11-0XX, in development best practices; See John Graybeal for status
22 Coordinate systems standards SWE 2.0 SensorML_2.0_evaluation_package, in development see John Graybeal for status
23 Datums tidal datums nice short presentation by Richard Edwing, CO-OPS, 2010
24 Datums DLESE guidance See below

Appendix: DLESE datum choices

DLESE [24] supports the following datums:

  • Horizontal - NAD27, NAD83, ATS77
  • Vertical - Sea level, CGD28-CDN, NAVD29-USA, NAVD88, IGLD88
  • Global - WGS72, WGS84, PZ-90
  • Other and Unknown are allowed values
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.