P.S. I neglected the obvious further simplification: replace "t(o)"
with "t(t)". Time becomes a simple netCDF coordinate variable in the
synchronized representation of trajectories. Similar for synchronized
profiles and time series.
===========================
On 10/13/2010 10:39 AM, Steve hankin wrote:
> 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/a7f67a20/attachment-0002.html>
Received on Wed Oct 13 2010 - 11:42:06 BST
