Dear Thomas and Jonathan,
This is I think easy enough that even I will weigh in. Makes sense to
me to recommend, but not require, that the coordinate value be the
mid-point, so I agree with Jonathan.
Best regards,
Karl
Thomas Lavergne wrote:
> Dear all,
>
> I would like to push the discussion a bit further on those cell bounds.
>
> We agree that some variables are intensive, others are extensive. For coping equally well with both types of variable, the CF convention offers the notion of coordinates (axis) and cell bounds.
>
> However, there seem to be a bias here, since bounds cannot be defined without an axis. This leads to the issues that was raise earlier in this thread, namely "what axis value is representative for my cell?". It is common to use the central value but, as we have seen for accumulated precipitations, other choices might be relevant.
>
> Yet, as far as I understand this, CF does not give the answer. CF advises us to provide cell bounds for extensive variables but we are free to choose the axis value associated to each cell. It could even be outside the bounds, am I correct? Could it be a "missing value"?
>
> Now, we cannot assume that a (visualization) software will care about our cell boundaries. It will most probably use the axis value, trusting the data provider, and this choice is not without consequences.
>
> So the questions are:
> 1) should we aim at community consensus outside CF (the community of accumulated precipitation would agree on using the end date, etc...)?
> 2) Should CF propose guidelines on what value to use?
> 3) Should CF mention that there is an ambiguity here?
> 4) Did I miss a point?
>
> I have the example of a sea ice motion dataset which is a time-extensive variable, defined as a Lagragian accumulation between a start and a stop time. This aspect is reflected in my time_bounds. But what should I put as the time axis: start time? stop time? mid-time?
>
> Any suggestions/comments are welcome.
>
> Cheers,
> Thomas
>
>
> ----- "Ethan Davis" <edavis at unidata.ucar.edu> wrote:
>
>
>> Hi Benno,
>>
>> Benno Blumenthal wrote:
>>
>>> Also, it is not particularly natural to use the end point as the
>>>
>> label
>>
>>> for the data, certainly not so natural that a program would assume
>>>
>> that
>>
>>> not knowing anything else about the data. It makes sense from a
>>>
>> data
>>
>>> collection point of view, maybe, but stops there. Most of us use
>>> center of interval as default, particularly since our semantics are
>>>
>> not
>>
>>> good enough to detect accumulation (which is the only case where end
>>>
>> of
>>
>>> interval is natural).
>>>
>> The accumulated precipitation data from these models is currently
>> labeled by the end points of the accumulation intervals (i.e., they
>> are
>> all on the forecast time dimension). I'm trying to add the semantics
>> to
>> make it possible to detect that this data is an accumulation without
>> breaking backwards compatibility.
>>
>> Since, as you say, accumulation "is the only case where the end of
>> interval is natural", adding the cell bounds information while using
>> the
>> same forecast time dimension seems natural for this case.
>>
>> Ethan
>>
>>
>> Benno Blumenthal wrote:
>>
>>> I have to vote for multiple dimensions here -- these are different,
>>> parallel dimensions which happen to have the same number of points.
>>>
>>> Also, it is not true that a generic program cannot use the bounds.
>>> Ingrid, in fact, prints time almost always as an interval, e.g. Jan
>>>
>> 1980
>>
>>> if the time cell goes from 0000 1 Jan 1980 to 0000 1 Feb 1980, so
>>>
>> that
>>
>>> cell boundaries are critical for time, much more important that
>>> spacially. This is because in common usage when we specify a time
>>>
>> we
>>
>>> almost always implicitly specify an interval.
>>>
>>> Also, it is not particularly natural to use the end point as the
>>>
>> label
>>
>>> for the data, certainly not so natural that a program would assume
>>>
>> that
>>
>>> not knowing anything else about the data. It makes sense from a
>>>
>> data
>>
>>> collection point of view, maybe, but stops there. Most of us use
>>> center of interval as default, particularly since our semantics are
>>>
>> not
>>
>>> good enough to detect accumulation (which is the only case where end
>>>
>> of
>>
>>> interval is natural).
>>>
>>> Benno
>>>
>>> On Thu, Oct 22, 2009 at 6:08 PM, Ethan Davis
>>>
>> <edavis at unidata.ucar.edu
>>
>>> <mailto:edavis at unidata.ucar.edu>> wrote:
>>>
>>> Hi John,
>>>
>>> John Caron wrote:
>>> >
>>> > The time coordinate here means forecast time, and you are
>>>
>> trying to
>>
>>> > capture "interval of accumulation".
>>>
>>> I'm not sure I understand your point here. The forecast time is
>>>
>> the only
>>
>>> time dimension we have. What other time coordinate would the
>>>
>> "interval
>>
>>> of accumulation" be over?
>>>
>>> > As jonathan says, you would have to create separate time
>>> coordinates for
>>> > each variable which has a distinct bounds.
>>>
>>> Yes, CF is currently written so only one boundary variable can
>>>
>> be
>>
>>> associate with one coordinate variable so this situation would
>>>
>> require
>>
>>> multiple time coordinates. I'm wondering if CF should be
>>>
>> extended to
>>
>>> allow multiple boundary variables to be associated with a
>>>
>> single
>>
>>> coordinate variable.
>>>
>>> > theoretically theres no
>>> > problem with that, practically it may be more confusing than
>>>
>> just
>>
>>> > documenting the bounds on the variable in a non-standard but
>>> > human-readable way. it seems unlikely that a generic program
>>>
>> could do
>>
>>> > anything useful with those coordinate bounds.
>>>
>>> I agree that multiple time coordinates would do nothing for
>>>
>> clarity.
>>
>>> Which is why I'm wondering about extending CF to allow for a
>>>
>> clearer,
>>
>>> programmatically useful representation of this data.
>>>
>>> Ethan
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> CF-metadata mailing list
>>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>>> http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>
>>>
>>>
>>>
>>> --
>>> Dr. M. Benno Blumenthal benno at iri.columbia.edu
>>> <mailto:benno at iri.columbia.edu>
>>> International Research Institute for climate and society
>>> The Earth Institute at Columbia University
>>> Lamont Campus, Palisades NY 10964-8000 (845) 680-4450
>>>
>>>
>>>
>>>
>> ------------------------------------------------------------------------
>>
>>> _______________________________________________
>>> CF-metadata mailing list
>>> CF-metadata at cgd.ucar.edu
>>> http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>
>> --
>> Ethan R. Davis Telephone: (303)
>> 497-8155
>> Software Engineer Fax: (303)
>> 497-8690
>> UCAR Unidata Program Center E-mail:
>> edavis at ucar.edu
>> P.O. Box 3000
>> Boulder, CO 80307-3000
>> http://*www.*unidata.ucar.edu/
>> ---------------------------------------------------------------------------
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
>
Received on Thu Nov 12 2009 - 06:43:52 GMT
