To answer this concern, I would agree to modify the statement
"Applications are free to assume that data is missing where the auxiliary coordinates are missing"
to
"Applications should treat the data as missing where the auxiliary coordinates are missing"
My concern is that we shouldnt make a file "non CF compliant" just because the data provider would like to store data values where there arent coordinate values. But telling them that standard software _will_ ignore them seems good.
On 3/29/2012 9:47 AM, Rich Signell wrote:
> Jonathan,
>
> +1 on your idea of only identifying variables as aux coordinate
> variables once they have valid values at valid data locations.
>
> -Rich
>
> On Thu, Mar 29, 2012 at 11:32 AM, Jonathan Gregory
> <j.m.gregory at reading.ac.uk> wrote:
>> Dear Jim
>>
>> We are discussing auxiliary coordinate variables. They do not have to be
>> 1D or monotonic. Those requirements apply to coordinate variables in the
>> Unidata sense. CF distinguishes these two concepts in Sect 1.2.
>>
>>> The point is, the information in the variable *is* coordinate information,
>> I would say, if it's missing, it's not information.
>>
>>> What if we say something along the lines of, "Applications should treat the
>>> data as missing where the auxiliary coordinates are missing when plotting
>>> data."? Would that resolve the problem?
>> Plotting is not the only thing that an application might wish to use it for.
>> If we said, more generally, "Applications should treat the data as missing for
>> all purposes where the aux coord variables are missing", it would be almost
>> the same as not allowing missing data in aux coord vars, since there would be
>> no point in providing a data value if it was not permitted to use it.
>>
>> Although I am arguing one side, I could be convinced either way. But it does
>> feel unsafe to me at present.
>>
>> Cheers
>>
>> Jonathan
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
Received on Thu Mar 29 2012 - 10:01:08 BST
