Ah, I see. Interesting. Maybe that's an argument for recommending that
valid_min/max be used sparingly and only when necessary, and not as generic
prophylaxis?
At least with regard to things like lat/lon coordinates, this example has me
thinking that it's more likely that one would encounter problems due to a
mis-specification of the valid range than that one would avoid problems because
there were known bad values in the file that got properly ignored because they
were outside the valid range...
If anyone knows of a scenario where it's known a priori that certain values of
coordinate-type variables are bad, but likely to end up in the file anyway,
please share. I think it would be illuminating for thinking about the
real-world practicalities of standards compliance.
Cheers,
--Seth
On Thu, 19 Apr 2012 20:28:38 +0000
Jon Blower <j.d.blower at reading.ac.uk> wrote:
>Hi Seth, all,
>
>Sean did mean valid_min/max, not actual_min/max. His situation was a
>curvilinear grid which requires latitude and longitude 2D data variables. The
>valid_min/max should have been -90:90 for the latitude data variable, but were
>set incorrectly (not by Sean) to a narrower range, meaning that Java-NetCDF
>interpreted all latitude coordinate values outside this range to be "missing
>values". Hence the georeferencing screwed up completely.
>
>It would seem fairly easy for an automated checker to check that valid_min/max
>(if they exist) seemed reasonable according to the actual data contents,
>although a checker could never be sure that they are right.
>
>HTH,
>Jon
>
>
>-----Original Message-----
>From: cf-metadata-bounces at cgd.ucar.edu
>[mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Seth McGinnis
>Sent: 19 April 2012 21:05
>To: cf-metadata at cgd.ucar.edu
>Subject: Re: [CF-metadata] code that does semantic checking of CF headers
>
>Hi Sean,
>
>>From your description, it sounds like you're confusing valid_min and
>>valid_max
>with actual_min and actual_max. The former attributes define theoretical
>extrema, beyond which data is considered invalid (e.g., latitude > 90 degrees
>or precipitation < 0). The latter are what modelers would include if they
>were providing information to assist with visualizations.
>
>Personally, I dislike actual_min and actual_max, because I don't think you can
>trust them to be correct. But if you want to take advantage of visualization
>hints in metadata, those are the attributes to reference.
>
>Cheers,
>
>--Seth
>
>====
>Seth McGinnis
>NARCCAP Data Manager
>Associate Scientist
>IMAGe / NCAR
>=====
>
>
>On Thu, 19 Apr 2012 16:13:51 +0100
> "Gaffney, Sean P." <sgaf at bodc.ac.uk> wrote:
>>Hi all,
>>
>>My name is Sean Gaffney, from the British Oceanographic Data Centre,
>>and I'm working on a project dealing with numerical model data that are
>>in CF compliant NetCDF, so I thought I'd sign up to the community.
>>
>>The project I am working on aims to develop a web-based delivery system
>>for oceanographic numerical model data and has a module which allows
>>visualisation of the data. We've been using test CF data to fine-tune
>>some of the technical aspects of this visualisation.
>>
>>I have a particular issue at the moment which I hope someone out there
>>might be able to assist me with.
>>
>>My problem started when I found that the test CF data were passing the
>>BADC CF compliance checker, but not visualising properly. A check with
>>the people who developed the visualisation module led to the discovery
>>that, while the CF metadata were formatted correctly, the actual values
>>within the metadata were incorrect e.g. the valid_min and valid_max
>>attributes for both the latitude and longitude and dimensional
>>variables had values which did not reflect the actual range of data in
>>the file. The visualisation was setting itself up based on the values
>>stored in the attributes and was therefore not displaying any data.
>>
>>Has anyone in the CF community come across this sort of issue before
>>and if so, what solutions would you recommend? My initial thoughts were
>>that I'd have to develop some sort of code which interrogates the data
>>file and compares the entries in the CF metadata header against the
>>actual data values in the file, but I'd be interested to see what
>>people think. Please bear in mind that I won't actually be generating
>>model runs myself, but will be receiving data from people that have
>>done so and need to know that I'm being given valid data and metadata.
>>
>>Sorry for making my first message to the CF community so long.
>>
>>Looking forward to your responses
>>
>>Yours
>>
>>Sean Gaffney
>>BODC
>>
>>
>>-----------------------------------------------------------------------
>>---------
>>Sean Gaffney
>>Data Scientist
>>British Oceanographic Data Centre
>>Joseph Proudman Building
>>6 Brownlow Street
>>Liverpool
>>L3 5DA
>>UK
>>+44 (0)151 795 4950
>>
>>
>>--
>>This message (and any attachments) is for the recipient only. NERC is
>>subject to the Freedom of Information Act 2000 and the contents of this
>>email and any reply you make may be disclosed by NERC unless it is
>>exempt from release under the Act. Any material supplied to NERC may be
>>stored in an electronic records management system.
>>_______________________________________________
>>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 Apr 19 2012 - 15:31:59 BST
