Re: [cf-pointobsconvention] Draft 2



Don Murray wrote:
John-

Thanks for getting this going.  I think you're on the right track.

John Caron wrote:
Attached is a PDF of second draft of what my thoughts are on a point obs convention. Its not really a proposal (yet), but a reasonable place to start.

A couple of points: :-)

- there should be no requirement of a z dimension for point data or
trajectories.  ship tracks, hurricane tracks, etc have no z dimension.
We've already run into this problem with the existing nc2.2 trajectory
implementation.

Ok, we can recommend but not require. Do you think "surface" is reasonable to assume when z is missing?


- "profiler" in the atmospheric community is used extensively for the
name of an instrument that produces "profiles".  I would recommend
changing your "profiler" to "profile" to remove this confusion.  A
RAOB sounding is a profile, but people do not refer to the instrument
as a profiler necessarily.

ok. anyone with a better name is welcome to offer it. What is "data that has an array of values along the vertical dimension"?



- RAOB sounding observations are currently broken out based on the
type of observation so that you have multiple profiles for the same
station at the same time (mandatory levels, significant temperature
levels, significant wind levels, tropopause levels, etc).  The number
of levels of each (paricularly the significant level data) varies from
station to station and time to time.  How would that fit into this
model?  See the current netCDF sounding files on motherlode for examples.

so you have more than one profile at same x,y,t, from the same instrument. The current files (eg http://motherlode.ucar.edu:8080/thredds/dodsC/station/profiler/RASS/1hr/20070917/PROFILER_RASS_01hr_20070917_1500.nc) use a fixed z dimension with missing data. (actually im not seeing the multiple profiles per file, am i looking at the right files?)

Assuming you decide to use variable length z, it probably fits into this:

Station Collection of Profilers (variable length)

 float humidity(obs);
 float temperature(obs);
 float pressure(obs);
 int profile_index(obs);

 double time(profile);
 double station_index(profile);

 double lat(station);
 double lon(station);

i guess the main wrinkle is that the time coordinates need not be unique.


-  while not necessarily a part of the convention, implementations
of these need easy factory methods for taking a set of point
observations and creating trajectories based on a particular variable
(e.g station name or id).  For example, if I have a collection of ship
reports for  multiple times, I'd like to be able to view this as point
observations or individual tracks for each ship.

Since trajectories need to be time ordered, it would be natural to order a set of points by time and call it a trajectory. However, this requires the data to be memory resident, so you could not do this operation on a set which doesnt fit into memory, unless you wanted to do disk-based sorting.

Going the other way, its easy to ignore the connectedness of a trajectory and call it a point collection. Since this is a convention for writing, we would like writers to add as much semantics as possible (which the reader can ignore). So we would encourage users to write trajectory files if the data is a trajectory. The only difference is that the data is written in time order, and the datatype is "trajectory" instead of "point".


- is there some explicit expectation that the z dimension is
convertible with altitude units (m,ft, etc).  Satellite wind
observations can have pressure as the vertical dimension so that
needs to be supported.

thats a good point. we should probably follow the existing CF conventions (section 4.3), which allows various vertical coordinates. so then we should allow vertical transforms (appendix D). While were at it, we should allow x,y projection coordinates and horizontal transforms (Appendix F). In other words, allow all the rest of the CF spec, unless it would mess things up.

Thanks for your input!