NOTE: The cf-pointobsconvention mailing list is no longer active. The list archives are made available for historical reasons.
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@xxxxxxxxxxxxxxxx P.O. Box 3000 (303) 497-8628 Boulder, CO 80307 http://www.unidata.ucar.edu/staff/donm *************************************************************
cf-pointobsconvention archives: