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
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
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:
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
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
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
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".
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 Murray UCAR Unidata Program
dmurray@xxxxxxxxxxxxxxxx P.O. Box 3000
(303) 497-8628 Boulder, CO 80307