Dapper in-situ conventions spec available

[John Caron]

Hi Joe, et al:

I was looking over our "data type" classes for observational data, and translated them into dapper/dods description (I hope the abbreviated notation is clear). The first 2 are the same as Dapper:

Collection of Station Time series: (same as Dapper "time series data" example)

 Sequence {
   lat, lon, z;
   name;
   id;
   Sequence {
    time;
    v1, v2, ...
   } obs;     // connected
 } stn;  // not connected


-------------------------------

Profile / Sounding Collection: (same as Dapper "CTD measurements" example)

 Sequence {
  lat, lon, time;
  id;       
  Sequence {
    z;		// time could be in inner seq instead ?
    v1, v2, ...
  } obs;             // connected
 } profile;         // not connected

-------------------------------

This one is for a collection of point data, eg earthquake data:

Collection of Point data:

 Sequence {
   lat, lon, z, time;
   v1, v2, ...
 } obs;      // not connected

-------------------------------

A single trajectory looks exactly like a point collection, but the points are understood to be connected:

Trajectory:

  Sequence {
    lat, lon, z, time;
    v1, v2, ...
  } obs;      // connected

Trajectory Collection:

 Sequence {
  id;
  Sequence {
   lat, lon, z, time;
   v1, v2, ...
  } obs;       // connected
} traj;    // not connected


1. We would like to use the dapper convention to handle these other types of observation data; we have various datasets that we are required to serve. If dapper cant handle them, we would probably define an extension that would stay dapper compatible for the common data types (stations and soundings).

2. I recently realized that the connectivity is an essential aspect of the data type, and is currently implicit in our data type classification. We are considering the possibility of adding some specific attributes to make this explicit. Has any one else thought about this issue?

3. These are the data types we've actually seen, but a others seem likely, eg a collection of stations that have a time series of vertical profile or soundings. It would be nice to be able to extend the spec, in a way that clients can determine which data types they know how to handle.

John