On Wed, Oct 25, 2017 at 8:57 AM, Sebastien Villaume <
sebastien.villaume at ecmwf.int> wrote:
> _at_Chris, thanks for your contribution to the discussion. very interesting
>
> I don't agree with your comment regarding 3D data variable with 4
> coordinates being wrong. I have 3 physical axes and 4 coordinates, yes, but
> leadtime is a coordinates associated to the same time axis than the
> forecast_reference_time coordinate.
> In other words, I have 2 coordinates sharing the same physical axis. I
> don't have multiple Time, I have multiple descriptions/partitioning of Time.
>
I understand what you are trying to do, but:
1) does CF allow multiple coordinates for a single axis???
2) how does the user (or even more so, software) know which axes has dual
coordinates.
But also -- as you say: "I have multiple descriptions/partitioning of Time."
I think that only ONE of those is the coordinate variable -- a given
forecast is "good" for one particular datetime. That is the time
coordinate. If it ALSO is, say 24 hours after the initialization, that is
additional meta data, not a coordinate. I don't understand what that can't
be a new variable, with shape (1,) and time as it's coordinate axis...
among other things, I'm pretty sure a time coordinate has to be a full
datetime (and monotonic??)
> I am doing this because I want to associate 2 informations for each time:
you can associate any amount of information with the time coordinate --
each variable that uses the time coordinate in more information associated
with that time.
the reference time and the elapsed time since that reference time (instead
> of only providing the valid time which is simply the composite of the two
> with a loss of information).
As Jonathan pointed it out, this is discussed in detail in trac ticket 117
> and on this mailing list. I have also looked at the discussions from the
> early 90's on the unidata netCDF mailing list. It took a while to go
> through, it seems to be a recurrent problem and nobody really solved it so
> far.
>
that maybe so -- I haven't had any trouble storing multiple forecast runs
with the additional info about when the run was initialized, etc all in
meta data, but I can see why you might want a more "standardized" way to do
it.
But I think that would require maybe a couple new standard names? rather
than multiple time coordinates -- I really don't think your additional
"times" are really time coordinates.
> We have a fundamental disagreement: I don't see this as a "multiple time
> axes" problem, I see it as a "single time axis with multiple time
> coordinates defined on it" problem. Our preferred solution (so far) is in
> fact to use all three standard names (time, forecast_reference_time and
> forecast_period) in
ah -- so those standard names do exist!
> the same file but only "time" has the attribute "axis = T". One can see
> the two other coordinates as "auxiliary coordinates" of the same physical
> axis. It means having redundant informations (only 2 are needed, the 3rd
> one can be derived from these 2) but it makes the data files compatible
> with more tools.
>
so what is the problem??
I think the "trick" here is that something like forecast_reference_time is
NOT a time coordinate -- it is data associated with an index of the time
axes of your data. IIUC, you might have a bunch of indexes in the data
array that are the forecast at different datetimes (say, hourly), but all
have the same forecast_reference_time -- which means it is not a time
coordinate, it is data -- what is the reference time for this particular
point in the array? similar to "that is the temperature at this particular
point".
Think of it this way -- if you wanted to plot the change of some parameter
at one location over time from this model run, what would you put on the
X-axis? I don't think you'd put the forecast_reference_time.
> I see two options to move forward:
> 1) expand the available list of standard names to be able to describe
> accurately any type of forecasts, analysis, hindcast, etc.
>
That makes sense to me -- I think that would be required in any case if we
want to capture more of that info with standard names.
> 2) recognise that time and processes are decoupled information, deprecates
> "forecast_reference_time" and "forecast_period" for something more generic
> like "reference_time" and "time_interval", and finally design a mechanism
> to describe forecast, hindcast, analysis, etc.
>
there are some standard names that have more and less specific versions --
to a "reference_time" name (and others) might make sense
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20171025/2aff2ea2/attachment.html>
Received on Wed Oct 25 2017 - 13:25:57 BST
