[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: netcdf conventions for EOL profiler data



Gary Granger wrote:

John Caron wrote:

in consensus.cdl:
1. Will there always be 50 heights for every time? That is, is this really a max, and do you expect a lot of missing values?
It is a max, related to the details about time-varying heights that I mentioned in my other email. 


2. use of valid_range:
Good point about valid_range, so we can avoid it when the data are never expected to be invalid. Is there already a convention for indicating instead the "expected or typical range" for a variable, something a plot program might use as the default scale? Is there any software that would use something like that? Otherwise we could rename it to "nominal_range" or "expected_range" just for the descriptive value. I know it helps me to know what range of numbers to expect when looking at a file. 

"actual_range" if you looking at the real data. otherwise, "nominal_range" 
seems good.




...
It doesnt matter to IDV/CDM, but theres no reason not to follow CF advice to not use dimension name for multidimensional coordinates. So heights is better. 

Roger that.
A bigger problem is that heights _is_ a vertical coordinate, as is altitude. How to indicate this? 

Hey, I asked you first. :)
for unitless quantities like confidence, better to use an empty string units = "", although "1" is ok also. definitely dont omit the attribute units 

So we'll go with an empty units attribute for unitless variables.
yes, bounds is good. we actually are parsing it, and the info is available in the CoordinateAxis object. 

Good to know.


For global attributes you might want to have a look at:
http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html
Given the above, we can add or rename a few of the global attributes. For example, we can use 'title' instead of 'description', and/or 'description' could become 'comment'. 

    :standard_name_vocabulary = "CF-1.0";
    :title = "Consensus winds from NIMA" ;
    :summary = ?
    :keywords = ?
    :comment = "?"
        :project = <project>
Instead of 'author' we can use 'creator_name', and instead of 'date_processed' use 'date_created'. Maybe we can use 'processing_level' instead of 'Processing-Method'. 'title' seems like a good place to distinguish the particular kind of profiler data, eg, Consensus winds, Consensus temperatures, Moments, Spectra, and so on. When the software knows the field project name, it can specify the 'project' attribute. 


...
I assume this would make it easier for more generic software to integrate 
profiler data at the correct relative heights, but maybe it's excessive.


this is the issue that needs some more thought


Indeed.
Should our lat/lon/alt variables have a single dimension of size 1, to make 
them COARDS-compliant coordinate variables?  CF allows scalar coordinate
variables, and they can be associated with a variable using the
'coordinates' attribute, but using the 1-dimensional option could be more 
universal.

 http://tinyurl.com/2lrjkt
my own opinion is its a mistake to extrapolate COARDS, which is about grids, to observational data. It works ok as long as you are storing a single profile in the file, but is incorrect when storing multiple profiles in a file. For that case, the correct generalization is a "profile" dimension, and then lat(profile), lon(profile), etc. 
So I would advise against it.


Ok.


Should we store the boundaries for the gate heights, eg
height_bounds(time,height,2), so that it's obvious where the gate is and
where the height coordinate falls relative to the gate?  Or is there an
attribute we can specify to indicate that the height coordinates are always 
at the center of the gate (assuming that's where they are)?

 http://tinyurl.com/38htef
We will assume that the coordinate is a midpoint, and edges are half-way in between. Use bounds if thats not the case, or you need to convince some other piece of software of the correct interpretation.
In that case, I'm thinking it's excessive to also store the bounds array for heights. The 'expectation' for profiler data is also that the gate height is the center of the gate. We can document that some other way, both in the file as an attribute of heights and on a web site, and we can embed a link to the web site in a global attribute 'eol_profiler_convention_url'. 


Should we identify the Conventions as 'CF-1.0' (assuming we can make
everything compliant), or is it still better to have a separate convention 
'EOL Profiler Convention 1.0'?

 http://tinyurl.com/2mfobc
If you can make it CF, you can do :Conventions = "EOL Profiler Convention 1.0, CF-1.0" indicating that it satisfies both. What you have then is "EOL Profiler Convention 1.0" extends "CF-1.0" in some sense. 

Ok.
I will consolidate all the comments and wisdom into a web site along with a set of reference CDL files. That will be the start for documenting our netcdf profiler conventions. I'll let everyone know when it's up. 

Thanks,
gary