Dapper in-situ conventions spec available

[Joe Sirott]

John Caron wrote:
> 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
>
The name variable would be an attribute in Dapper (no strings except _id 
in outer sequence):

Sequence {
  lat, lon, z;
   id;
  Sequence {
   time;
   v1, v2, ...
  } obs;     // connected
*  Structure {
    name;
  } attributes;
*} 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
>
Dapper version would be:

Sequence {
  lat, lon, z, _id;
  Sequence { // Inner sequence has length of 1
    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
>
Both could be represented as:

Sequence {
  _id;
 lat0,lon0,z0;    // Centroid of trajectory (or should a bounding box be 
used?)
 Sequence {
  lat, lon, z, time;
  v1, v2, ...
 } obs;       // connected
} traj;    // not connected

In the first case (single trajectory) there's only be one id and one 
inner sequence.
>
> 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?
Connectivity is implied by the Dapper 2-level sequence -- all inner 
sequence values are implicitly connected. Am I missing any scenarios 
where this breaks down?

>
> 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.
Perhaps there should be a global attribute to describe the data type 
("epic-insitu-datatype"?) that could have the values 
"trajectory","profile", or "time-series". This could be extended as the 
spec evolves.


Joe