Dear all,
once again I haven't followed the entire discussion carefully, but I sense
there is more to the problem than what has been discussed so far:
1) if we define the meaning of "time" as a specific datetime instance on a
given calendar, then all time values along a trajectory should indeed be in a
form that can be expressed in the usual "days since DATE" units.
2) the trajectory "starting point" (as 4D space-time tuple if you like to get
fancy ;-) is a unique characteristic of the trajectory as a whole. This means
that within the same model (or interpolation technique) you will always be able
to reproduce the exact same trajectory if you know this one location and time.
In this sense it is similar to the "reference time" of for example a 3D model
run, which is usually expressed as the DATE in the time units attribute. In
order to avoid confusion here, I suggest to use the term
"trajectory_start_time" (or short: "start_time") here.
3) trajectories can be run forward and backward in time. Therefore the "time"
values can be negative relative to the "trajectory_start_time".
4) in the simple case of having one trajectory in the file (equivalent to some
output interval from a model simulation), one could easily live with the
standard way of setting the reference time (DATE part of time units attribute)
to the trajectory_start_time and have the time values express the relatve time
shift with respect to the trajectory_start_time.
5) in the more complex case with several trajectories in the file, one option
could be to allow for a new DATE value in the time units attribute, such as:
time: units = 'days since trajectory_start_time'
string trajectory_start_time(ntraj)
double time(ntraj, nsteps)
Hence, the term "trajectory_start_time" would refer to a variable rather than a
given fixed date.
Not so nice if you have to evaluate a lot of strings every time you use this.
6) Alternatively, DATE would still be an arbitrary reference date, and the
trajectory_start_time variable would be an offset relative to this. Hence:
real_time = reftime + trajectory_start_time + time
This would, however, require some means of expressing the meaning of the
"trajectory_start_time" variable, because otherwise any automated system would
compute time simply as real_time = reftime + time. Could one use the formula
terms for this?
7) Trajectories don't necessarily all have the same length (for example flight
tracks of ozone sondes which end when the balloon bursts). Not too careful
thinking suggests that one should then either move to hdf or agree on a certain
maximum number of "steps" for all trajectories.
Hope this helps a bit,
Martin
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Besuchen Sie uns auf unserem neuen Webauftritt unter www.fz-juelich.de
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
