Hi Karl:
Do you know of any specific "quick look" software that wouldnt work?
John
On 3/21/2013 10:04 AM, Karl Taylor wrote:
> Hi John,
>
> I'm probably repeating what others have said, but allowing strings as
> actual (rather than ancillary) coordinate values would break lots of
> "quick look" software which can't plot variables which are "functions"
> of a string representation of the independent variable (i.e, time). If
> I'm correct about this, I think making the proposed change to CF would
> be a mistake.
>
> If the alternate string representation is stored as an ancillary
> variable, a human reading the ncdump would immediately see what the
> "dates" are, and the software would continue to work by reading the
> actual coordinate values.
>
> Karl
>
> On 3/21/13 8:51 AM, John Caron wrote:
>> On 3/21/2013 9:41 AM, Steve Hankin wrote:
>>>
>>> On 3/21/2013 8:25 AM, John Caron wrote:
>>>> Probably my proposal comes down to 2 parts, which are separable:
>>>>
>>>> 1. Find a suitable replacement for udunits as a reference library
>>>> for CF calendar dates. Unfortunately, udunits used a slightly
>>>> non-standard syntax, which we need to still be legal for backwards
>>>> compatibility. So its unlikely a standard library would work off the
>>>> shelf. Someone needs to commit to making a library that supports CF
>>>> as it evolves. Other libraries can test against it.
>>>>
>>>> 2. *Allow*
>>>
>>> Hi John,
>>>
>>> The crux of this debate has been whether to "allow" a new (for CF),
>>> redundant encoding of time coordinates. I *think* you are suggesting
>>> in your bullet #2 to allow the new syntax only in ancillary variables
>>> (metadata), but not as a representation of coordinates. Can you clarify?
>>>
>>> - Steve
>>>
>>>> a suitable string syntax for date/times, probably expressed as a
>>>> profile of ISO8601. Its a modest but worthwhile improvement IMO. The
>>>> syntax that is already used in udunits would be ok with me. However
>>>> this syntax has to be defined (it never was, unless you are yacc).
>>>> In my understanding, udunits is more or less a superset of ISO. that
>>>> is, its a bit more lenient in the syntax. However it adds a few
>>>> restrictions, like defaulting to UTC and filling non specified
>>>> fields with 0. So its not strictly a superset. The advantage of
>>>> using CF process to define the syntax ("clarify the profile of
>>>> ISO8601") is that we are less likely to miss some subtlety in syntax
>>>> and meaning.
>>>>
>>>> John
>>>> _______________________________________________
>>>> CF-metadata mailing list
>>>> CF-metadata at cgd.ucar.edu
>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>
>>
>> Hi Steve:
>>
>> Im proposing that time coordinates may be expressed as strings, in
>> addition to the current way of using time offsets from a base date
>> expressed as a string in the unit attribute. The two date string
>> syntaxes (standalone and in the unit attribute) c/should be the same.
>>
>> Presumably we want to do either this or Aleksandar's proposal ?
>>
>> John
>>
>>
>> _______________________________________________
>> 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 Mar 21 2013 - 14:26:49 GMT
