[cf-pointobsconvention] Draft 2

[Don Murray]

John-

John Caron wrote:

>> - 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?

No, just because Z is missing you can't assume that it's at the surface.
It could be something like "tropopause" and just that there is no 
additional data to set that reference.

>>
>> - "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"?

I'm with John G.  What's wrong with profile?

>> - 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?)

Those are acoustic sounder data or wind profiler data (mislabeled in the
  catalog), not sounding data.  Look at the files in:

/local/ldm/data/pub/decoded/netcdf/upperair

on motherlode for the RAOB soundings.

> Assuming you decide to use variable length z, it probably fits into this:
> 
> Station Collection of Profilers (variable length)

Station Collection of Profiles

>  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.

Not sure I'm understanding this, but it is really pulling out a 
timeseries based on a particular variable - eg. all points in
time for the variable "track_name".

Since point observations and tracks can have similar structures,
I guess the idea would be to have a way of opening a file as either
a collection of points or as a set to tracks relative to a named
variable.

> Going the other way, its easy to ignore the connectedness of a 
> trajectory and call it a point collection.

agreed.

> 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".

However, it's important to take into account the needs of the users
of the data, not just the data providers.  So getting an idea of how
people want to use the data should influence how to write the data out.

>>
>> - 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.

That sounds like a good plan since readers out there will probably
already have code to support the other CF vertical dimensions.

> Thanks for your input!


Don
*************************************************************
Don Murray                               UCAR Unidata Program
dmurray at unidata.ucar.edu                        P.O. Box 3000
(303) 497-8628                              Boulder, CO 80307
http://www.unidata.ucar.edu/staff/donm
*************************************************************