+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 <[email protected]> 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 >> <[email protected]> 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 >> [email protected] >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> >> >> _______________________________________________ >> CF-metadata mailing list >> [email protected] >> 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 >> >> [email protected] >> 828-271-4900 >> >> >> >> _______________________________________________ >> CF-metadata mailing list >> [email protected] >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata John Graybeal <mailto:[email protected]> phone: 858-534-2162 Product Manager Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org Marine Metadata Interoperability Project: http://marinemetadata.org
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
