Dear Nan, (Wow, I actually typed your name as "NaN" to start with, just shows how I get buried in code! ;-)
Thanks for this. Yes, you're right, we would need to be careful with data subsets, either recalculating or omitting these values. As for "actual_valid_min/max", I see what you are saying but I actually find that nomenclature more confusing (it seems to imply that the other valid_min/max is somehow fictitious). Others might disagree. Anyway, I have posted a Trac ticket on this matter http://cf-pcmdi.llnl.gov/trac/ticket/31, which I guess is where future discussion will happen. Cheers, Jon On Fri, Jun 20, 2008 at 4:11 PM, Nan Galbraith <[EMAIL PROTECTED]> wrote: > This "breaks" when you subset data via opendap, for example, > doesn't it? I agree that it could be useful for discovery and for > apps like contouring, but it will need to be used carefully. > > Although the name would be "actual_min" (or max), the definition > would need to specify that it include only valid data values, otherwise > it won't be useful. Maybe actual_valid_min (or max) would be more > clear, and would save the overhead that the use of valid_min/max > incurs. > > Cheers - Nan > >> Since Jon mentions me in this thread I'll put in my brief contribution, >> although I agree very much with the discussion so far. >> >> Despite the limitations I think we really need these attributes. At >> BADC we are either putting custom attributes in the NetCDF or setting >> approximate min/max in configuration files. A standard approach would >> be a great improvement. >> >> I too like actual_min/max. >> >> Cheers, >> Stephen. >> >> --- >> Stephen Pascoe +44 (0)1235 445980 >> British Atmospheric Data Centre >> Rutherford Appleton Laboratory >> >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of John Caron >> Sent: 10 June 2008 00:54 >> Cc: [email protected] >> Subject: Re: [CF-metadata] attributes for min/max data valuesfor >> visualization >> >> I also like "actual_min" and "actual_max": short and to the point. >> >> One point Ill make is that I see a number of well thought out files >> using valid_min and valid_max when they really mean actual_min and >> actual_max. On first glance this may seem harmless, but it triggers (in >> the netcdf-java library default behavior) a costly scan of the data >> looking for invalid data, ie values outside that range. >> >> So adding actual_min/max as recommended attributes should help users >> from mistakenly using valid min/max. And its very useful for visualizers >> to create color scales etc. >> >> Julia Collins wrote: >> >>> On Mon, 9 Jun 2008, Jon Blower wrote: >>> >>> >>>> I have rediscovered this conversation in the depths of my inbox and >>>> thought it might be worth resurrecting. To summarize the discussion >>>> so far: >>>> 1) I proposed two new standard optional CF attributes (called >>>> something like minimum_data_value and maximum_data_value) that would >>>> be attached to a variable in a NetCDF file, redundantly holding its >>>> actual min and max values in that file. [...] As well as helping with >>>> >> >> >>>> data mining applications, this would act as a hint to visualization >>>> packages to provide a first attempt at automatically defining a >>>> colour scale range for sensible portrayal. Note that this attribute >>>> pair is distinct in purpose from valid_min and valid_max (which >>>> contains theoretical extrema, beyond which data is considered >>>> >> invalid). >> >>>> >>>> >>> I support the idea of formalizing these sorts of attributes in some >>> way. However, I would prefer a simpler name(s). For example: >>> >> "actual_min" >> >>> and "actual_max." Less typing :-), and more like the existing >>> >> "valid_min" >> >>> and "valid_max" attributes. >>> > > > -- > ******************************************************* > * Nan Galbraith (508) 289-2444 * > * Upper Ocean Processes Group Mail Stop 29 * > * Woods Hole Oceanographic Institution * > * Woods Hole, MA 02543 * > ******************************************************* > > > > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > -- -------------------------------------------------------------- Dr Jon Blower Tel: +44 118 378 5213 (direct line) Technical Director Tel: +44 118 378 8741 (ESSC) Reading e-Science Centre Fax: +44 118 378 6413 ESSC Email: [EMAIL PROTECTED] University of Reading 3 Earley Gate Reading RG6 6AL, UK -------------------------------------------------------------- _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
