On Wed, Oct 25, 2017 at 8:57 AM, Sebastien Villaume < [email protected]> wrote:
> @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 [email protected]
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
