September 2011 – Version 1

Shawn R. Smith¹ (smith@coaps.fsu.edu), Toby Martin², David O’Gorman², Daryl Swensen², Bill Fanning³, Robert Arko⁴, Aaron Sweeney⁵, Dru Clark⁵, and Suzanne O'Hara⁴.

¹COAPS, Florida State University

²Oregon State University

³University of Rhode Island

⁴LDEO, Columbia University

⁵SIO, University of California San Diego

Introduction

As part of the ongoing NSF Rolling Deck to Repository (R2R) program and in support of the Shipboard Automated Meteorological and Oceanographic System (SAMOS) initiative, the authors have developed a draft data-exchange protocol focusing on real-time transfers of meteorology and thermosalinograph data from UNOLS-operated vessels to shore. One area of much discussion and debate has been a coordinate system (reference frame) for a research vessel that will allow sensors to be precisely located on the vessel. Such a coordinate system is generally considered to use a three-axis (x, y, z) approach (to date, no user requirements for a polar coordinate system have been raised).

Note: We use the term sensor, as opposed to the R2R device_type, since in some cases the device may have several sensors that are located in different physical locations. For example, the device type “metstation” may consist of a thermometer, hygrometer, and barometer that are separated by some distance on a mast. Also, the coordinate system should be flexible enough to represent positions of both point sources or the position and orientation of extended devices (e.g., transducer arrays).

Coordinate System Schema

During summer 2011, the authors arrived at a general consensus that the following information should be included to define the vessel coordinate system:

1. x, y, z locations of the origin of the coordinate system (where is x=0, y=0, z=0)
2. The positive direction for each axis
3. The measurement units used when referencing the coordinate system
4. A survey reference (who conducted vessel survey and when)
5. Allowance for tilt angles relative to x, y, z axes and an indicator for clockwise versus counterclockwise angles [optional]

Here is an example of a coordinate system definition in XML:

<coordinateSystem>

• <xPositive>forward</xPositive>
• <xOrigin>fantail</xOrigin>
• <yPositive>port</yPositive>
• <yOrigin>center line</yOrigin>
• <zPositive>up</zPositive>
• <zOrigin>plimsoll</zOrigin>
• <MeasurmentUnits>Meters</MeasurmentUnits>
• <SurveyReference>J&R surveys, Inc., January 10 2010</SurveyReference>

</coordinateSystem>

With this coordinate system defined, the actual locations of sensors will include the following:

1. x, y, z measurements from the origin
2. a descriptive location [optional] (a controlled vocabulary is under development by R2R)

Here is an XML example for a GPS:

<talker>

• <make>Garmin</make>
• <model>GPS 17N</model>
• <serial_number>R-231.2</serial_number>
• <Location>
  • <x>42.0</x>
  • <y>2.0</y>
  • <z>7.1</z>
  • <description>Pilothouse roof</description>
• </location>

</talker>

Survey Reference

The form of the survey reference has been an area of much discussion. The consensus is that some form of survey reference document should be required. The option will exist to provide either a formal vessel survey document (from a vendor, see example above) or a brief document written by the operator on how they defined their coordinate system.

The survey document or operator coordinate system description will be provided to R2R. R2R will then host them in an on-line library, which can subsequently be referenced within the coordinate system schema (e.g., in the XML records). Within the Survey_reference block, a name, survey date, unique ID (leading to the document), and/or a URI can be used to link the survey reference at R2R.

Although having a well-defined coordinate system is essential, only the basic information on the origin and positive axis directions needs to be carried with the data files (e.g., in the XML schema above). The remaining details (e.g., which 2 points define the line of the axis or how the coordinates are defined in vector space) will be referenced via the survey document or operator description document. Most data users primarily need to know the offsets from the origin for a device and/or the difference in distance between devices referenced to the common origin.

The survey date and vessel for which the survey applies are critical metadata elements. The former should be part of the definition of the coordinate system (under the “survey_reference” block of information). For meteorology and thermosalinograph real-time data, the latter is available elsewhere in the metadata files, but an alternative may be needed for other device types.

Another consideration for the survey reference document is to store the x, y, z position of reference marks made on the vessel by the operators. In some cases, practically measuring the location of a sensor to these reference marks is easier/more practical than measuring to the vessel origin. In most cases, this information should be stored in the survey document or operator coordinate document. Another suggestion is to include x, y, z location of common instrument positions (e.g., jackstaff, mainmast, tow points, etc.) in the survey document.

There also may be cases when more than one formal survey document or operator description are needed. For example, a commercial survey may have been used for the multibeam, but this may not consider the location of the meteorological instruments. In this case, the operator may need to provide a secondary document describing the method used to provide a coordinate location of the meteorological sensors. If the same coordinate system is used, then the operator document will be included along with the commercial survey document. If a different coordinate system is used for the meteorological sensors, we will recommend that the operator document describe how this alternate coordinate system is offset from the commercial coordinate system (for the multibeam). This will reduce confusion in the future.

In summary, operators should provide sensor locations relative to the coordinate system(s) defined for their vessels. The coordinate system can be defined either by the operator or by a precise commercial vessel survey.

Controlled Vocabularies

In addition to the <description> field (see example above), provision for a controlled vocabulary of general vessel position descriptors is suggested. To facilitate metadata integration, R2R will look for a controlled vocabulary for maritime terms (starboard, centerline, fantail, etc). Once available, these terms can be used when defining the coordinate system (and elsewhere as needed).

In addition, there is a need for a controlled vocabulary for units. SAMOS suggested the UDUNITS system developed by UniData – http://www.unidata.ucar.edu/software/udunits/ – but others can be considered.

Final Thoughts

SAMOS and R2R will not recommend a specific origin for the coordinate system on the vessel. We certainly can provide examples for those who are interested. The desired origin is user dependent. Many activities desire an origin at the vessel center of mass, whereas others want an origin with a z=0 at the waterline (plimsoll). The specification herein will work for either origin, but the specification does not allow for conversion between coordinates (e.g., what is the difference in z between the center of mass and the plimsoll)?

Establishing a set of standard offsets from the origin to physical locations on the vessel has been suggested. For example, distances from the origin to the plimsoll line and tow point locations are desirable. Another suggestion is to establish an offset from the sample location (for example, offset in time or distance along a pipe run). This can be provided in the