Hi All,
2 cents: Since this is a new twist on previously discussed feature
types, the tires of alternative approaches probably deserve to be
kicked. What's special about this use case is that the trajectories are
all synchronized in time. (Though with differing start/stop times.)
Analogous cases exist in profiles -- for example the Levitus ocean
profile collection has all been interpolated to common depths.
Similarly, time series collections are commonly synchronized.
The synchronization of coordinates opens a potential door to great
simplicity of representation.
metadata(i) data(i,o) x(i,o) y(i,o) z(i,o) t(o)
where i is the instance (which of the trajectories), o is simply the
time index. The possible costs are proliferation in numbers of ways to
represent similar things and file size. The question that I'd be
inclined to ask of Ute and Rich would be a judgment call on the cost in
file size that would result from filling missing values at the start/end
of each individual trajectory. Optionally the metadata could include
tstart_index(i) tend_index(i)
This representation seems _the simplest from the standpoint of
application code (reading)_. Synoptic view are simply projection at
fixed "o" index; the history of an individual trajectory is simply a
projection at a fixed "i" index.
-----
For each of the three basic structure -- time series, profiles, and
trajectories -- discussed at
https://cf-pcmdi.llnl.gov/trac/wiki/PointObservationConventions we have
three approaches: multi-dimensional, ragged contiguous, ragged indexed.
("flattened" omitted here). Effectively what I am kicking the tires on
here is a 4th approach: a "synchronized representation", which would be
the simplest of all of them. If we replaced "t(o)" with "t(i,o)" above
the "synchronized representation" generalizes into the
"multi-dimensional representation" of trajectories.
By the way, it is quite likely that *none *of the above precisely
addresses the needs of the model that is producing the data. Does that
model know in advance what the maximum number of tracer particles will
be? If that number is known, then the "Ragged array (indexed)
representation" of trajectories is arguably _the simplest from the
standpoint of model (writing)._ (And already documented. ;-) )
- Steve
============================
On 10/13/2010 5:49 AM, Jonathan Gregory wrote:
> Dear Rich
>
>> With the approach you suggest, if you wanted to obtain all the
>> particle positions at a particular time step, would you need to read
>> all tindex for all particles? (I'm a little fuzzy on what the CDL
>> would look like...)
> No, I don't think so. Either of John's proposed packing mechanisms would
> allow you to get just the tindex (and x y z) that applied to a particular
> particle without reading the others.
>
> Cheers
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20101013/677f41e3/attachment-0002.html>
Received on Wed Oct 13 2010 - 11:39:04 BST
