+1 to Steve's wording (that's what I was *trying* to say, Steve's is much better).
While I agree that each application should respond predictably to this situation, it is not the case that every application should respond the same way, and we should not indicate that such a monolithic response is required or assumed.
john
On Mar 29, 2012, at 10:01, Steve Hankin wrote:
> Returning to Nan's valid example, the proposed wording isn't very attuned to the valid needs of (in situ) observations. If the pressure sensor fails, while other sensors remain active, then the Z auxiliary coordinate becomes unknown but other parameters remain valid. The observations have potential value (though greatly degraded, of course), because a future investigator may figure out how to estimate the Z position from other information. For the investigator writing those applications, the statements below are wrong or misleading.
>
> I think the right thing to say is something along the lines of
> "Application writers should be aware that under some (rare) circumstances data auxiliary coordinate values may be missing, while other parameters at the corresponding indices remain valid. While special purpose applications may be able to glean useful information at these indices, most applications will want to regard data as missing where the auxiliary coordinates are missing "
>
> On 3/29/2012 9:05 AM, Jim Biard wrote:
>>
>> All,
>>
>> For the work I am doing right now, I am required to not fill in missing values in any variable. I encourage everyone to go with John Caron's idea.
>>
>> Grace and peace,
>>
>> Jim
>>
>>
>> On Thu, Mar 29, 2012 at 12:01 PM, John Caron <caron at unidata.ucar.edu> wrote:
>> 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
>>
>>
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>>
>>
>> --
>> Jim Biard
>> Research Scholar
>> Cooperative Institute for Climate and Satellites
>> Remote Sensing and Applications Division
>> National Climatic Data Center
>> 151 Patton Ave, Asheville, NC 28801-5001
>>
>> jim.biard at noaa.gov
>> 828-271-4900
>>
>>
>>
>> _______________________________________________
>> 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
John Graybeal <mailto:jgraybeal at ucsd.edu>
phone: 858-534-2162
Product Manager
Ocean Observatories Initiative Cyberinfrastructure Project:
http://ci.oceanobservatories.org
Marine Metadata Interoperability Project:
http://marinemetadata.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20120329/60bb0769/attachment.html>
Received on Thu Mar 29 2012 - 12:49:38 BST
