Re: [CF-metadata] CF Conventions and netCDF-4 enhanced model

I'd also like to participate in a working group developing updated CF conventions that take advantage of the netCDF-4 enhanced data model. On Wed, Sep 10, 2014 at 12:34 PM, John Caron wrote: > Hi Karl and all: > > NetCDF-4 compression and chunking are transparent to the user, and are > compatib

Re: [CF-metadata] CF Conventions and netCDF-4 enhanced model

Jim, I'm hoping more data providers follow your approach, as it will gradually bring along software developers, other data providers, and ultimately conventions authors. I gave a talk at AGU a few years back about how to manage

Re: [CF-metadata] CF upgrade to netCDF variable names

John Graybeal wrote: > This prompts me to observe that somehow, in this brave new age of computer > programming, people are > developing netCDF software that supports Unicode characters -- Unicode!! -- > in variable (attribute > etc) names. There will be netCDF files in the wild, used by scientis

Re: [CF-metadata] Are ensembles a compelling use case for "group-aware" metadata?

Charlie, Great use case, clearly explained ... It also demonstrates a potential need for "Group dimensions", so instead of groups cesm_01 and cesm_02, it would be possible to refer to Groups cesm[1] and cesm[2], supporting loops over contents of closely related groups without having to invent a c

Re: [CF-metadata] Towards recognizing and exploiting hierarchical groups

Jim, > I've got a few of questions. People have suggested using '.' delimiters > to build full variable names (path names). Since '.' has historically > been a legal part of a variable name, would it perhaps be better to use > ':', '\', or '|' instead? And why is '/' forbidden? Is it used > in

Re: [CF-metadata] Towards recognizing and exploiting hierarchical groups

Steve, > A question I'd like to see discussed (primarily to Unidata, I guess): > how difficult would it be to make accommodations in the netCDF API, > itself, so that netCDF4 groups were accessible through the netCDF-3 > API. If such enhancements could be baked into the netCDF code the > characte

Re: [CF-metadata] Towards recognizing and exploiting hierarchical groups (Charlie Zender - Steve Hankin - Richard Signell)

> Dear all, I'm also glad to see this discussion surface. Since I first presented "Developing Conventions for netCDF-4" at the 2007 GO-ESSP meeting: http://www.unidata.ucar.edu/presentations/Rew/nc4-conventions.pdf I've been hoping that netCDF-4 feature adoption would begin to gain traction i

Re: [CF-metadata] New standard name: datetime_iso8601

_360 = "2013-02-30" ; it's time (using *any* calendar) to update your netCDF software :-). --Russ > -Original Message- > From: CF-metadata on behalf of Russ Rew > Sent: Mon 14/01/2013 15:56 > To: ngalbra...@whoi.edu > Cc: cf-metadata@cgd.ucar.edu >

Re: [CF-metadata] New standard name: datetime_iso8601

Nan and Chris, > I agree with Chris. > > Having ncdump or other clients show dates in an ISO-compliant format > is a fine idea, as is using ISO strings for dates in attributes, but those > are completely different from storing date variables as strings. Yes, since version 4.2, ncdump has support

Re: [CF-metadata] Choice of fill value for unpacked data

National Guard and go missing. This may lead you to elect a new _FillValue. --Russ > Refining my earlier suggestion, that attribute could also be global, in > which case it would be used for all unpacked variables which didn't > define the new fill value via a variable-scope att

Re: [CF-metadata] Choice of fill value for unpacked data

Hi Phil, > The final para of section 2.5.1 of the CF conventions document describes > the use of the _FillValue (or missing_value) attribute in the case of > data packed using the scale-and-offset method. What is not clear - at > least to me - is what the preferred application behaviour should be

Re: [CF-metadata] netcdf4 and CF-1.6

Hi Corey, > On 30/03/12 15:01, Corey Bettenhausen wrote: > > To the CF group in general, how can I help to introduce groups into > > the CF conventions? And also extend CF to HDF5? What's the first > > step I need to take? > > My experience is that coming up with a proposal or two is a good star

Re: [CF-metadata] Convention attribute

Hi Nan, > I'm certain that this has been discussed, but I can't > find it anywhere in the email archive, or on the trac site. > > Don't we allow a compound (comma separated) string > in the global attribute 'Conventions'? > > Because there are new, complimentary conventions > available - like t

Re: [CF-metadata] Storing outline information in NetCDF/CF?

> Is there a way to store outline information in NetCDF/CF? = > > > I am looking for a way to store e.g. glacier outline, sea ice edge/extent e= > tc = > > in NetCDF. It would simplify data management within heterogeneous systems. = > > Data can then be dumped to Shapefiles, KML etc upon user

Re: [CF-metadata] Proposed addition to CF principles: outside conventions

Hi Jonathan, > I agree with these principles. I think we might phrase 3 and 4 as balanced > alternatives: > > > "CF may incorporate an outside convention into it when the following > > conditions hold: > > > > 1. The semantics of the convention are important to the CF community. > > 2. The conve

Re: [CF-metadata] standard name request

Hi James, > I would like to request a new standard name to represent wind speed at = > 10 m height. Would you please advice how to proceed? Thanks. The standard name of "wind_speed" should be used, with a scalar coordinate variable or size-one dimension of height, specifying 10 m. --Russ ___

Re: [CF-metadata] relationship between CF model and netCDF-classic data model

Upendra, There is also a document "Developing Conventions for NetCDF-4", no doubt in need of some updating, that describes why it's wise to wait for the crystallization of community best practices and experience before proposing new conventions that haven't been used yet: http://www.unidata.uc

Re: [CF-metadata] CF data model

Hi Jonathan, > Although CF is primarily a file format convention, we often have in mind a > logical data model for CF data while we are discussing modifications and > extensions to CF. In principle the data model can be separated from the > mechanics, restrictions and requirements of netCDF itself

Re: [CF-metadata] New standard names for satellite obs data

Ben Hetland wrote: > One may argue, though, that an option to output time values formatted as > ISO8601 would be very useful in tools like 'ncdump'. In that case it > should be optional as I believe the basic idea is to "dump" the internal > values as directly as possible from how they are actuall

Re: [CF-metadata] Units micro prefix "u" deprecated in udunits-2

Jonathan, > Should we put a general convention in CF that text attributes can only > contain US ASCII characters? I think that would avoid some problems. However it would also appear to place a new restriction on variable (and dimension) names that is not currently in CF, namely that only US ASC

Re: [CF-metadata] Conventions (vs. Community Profiles), and CF-checker

> Russ Rew wrote: > > Another possibility to consider is the notation > > > > :Conventions = "A/B" ; > > > Aha, and thanks - I thought the recommended separator was a > comma - my mistake. The separator "/" is only recommended when conv

Re: [CF-metadata] Conventions (vs. Community Profiles), and CF-checker

would use the global attribute :Conventions = "XXX/Time_series" ; --Russ _ Russ Rew UCAR Unidata Program r...@unidata.ucar.edu http://www.unidata.ucar.edu

Re: [CF-metadata] Salinity units

Karl, > We are using dB for one of the radar reflectivity fields that will be > collected as part of CMIP5. So, I second Jonathan's suggestion to allow > "dB" as a unit in udunits. No one has ever mentioned to me what the > "reference level" for this field is, so I'm afraid it won't be part

Re: [CF-metadata] Salinity units

Jonathan, > The intention of recording the units as 1e-3 (dimensionless) was to > suggest a canonical unit of PSU i.e. approximately the same as parts > per thousand. However, this is unclear and therefore > unsatisfactory. We have discussed this before, in fact, and I believe > we have decided i

Re: [CF-metadata] CF conventions and netCDF-4

Hi Phil, > I can't recall if this topic has come up for discussion on the mailing > list before - apologies in advance if that is the case. > > Although the current CF conventions do not appear to be tied explicitly > to a particular version of the netCDF library, there are certain > sections (e.

[CF-metadata] Independent documentation of CF conventions?

Hi, There is currently a Wikipedia discussion taking place on whether a CF Metadata Conventions article is appropriate: http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/CF_Metadata_Conventions One of the characteristics that Wikipedia strives for in all articles is verifiable accu

Re: [CF-metadata] CF procedures: some observations

Hi Jon, > Having gone through the process for the first time of recommending an > amendment to CF I'd like to share some experiences and opinions. If > you don't want to read all of this mail, then I can summarize this by > saying that I think the requirements for proposers of changes are too > o