NOTE: The cf-pointobsconvention mailing list is no longer active. The list archives are made available for historical reasons.
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!
cf-pointobsconvention archives: