Dear Bob
That's right, there doesn't have to be an instance dimension. The problem with
the file is that the variable you're concerned with (timeseries) isn't linked
to any of the other variables, so its purpose is not clear.
Best wishes
Jonathan
----- Forwarded message from Bob Simons - NOAA Federal <bob.simons at noaa.gov> -----
> Date: Sat, 25 Feb 2017 08:16:57 -0800
> From: Bob Simons - NOAA Federal <bob.simons at noaa.gov>
> To: CF Metadata <cf-metadata at cgd.ucar.edu>
> Subject: [CF-metadata] Pre-proposal for "charset"
>
> Jonathan and David, I disagree. The sample file I showed is a valid CF DSG
> file.
> CF Section 9.2 says "If there is only a single feature to be stored in a
> data variable, there is no need for an instance dimension and it is
> permitted to omit it. [followed by more details and examples]" I was
> surprised when that was first pointed out to me. And this isn't me
> defending my file: I didn't create this file. And I have seem this type of
> file created by other groups, all of whom contend that this type of file is
> a valid CF DSG file. As I often say, DSG is deceptively complex.
>
> And that is part of my point about the need for a charset and a data_type
> attribute. The writer of that file understands the data and how it is
> stored in the file. The problem is for the software reading the file that
> has to figure out what type of file this is (e.g., what variant of DSG
> formats) and what is what in the file. The DSG spec is not very helpful,
> given the large number of allowed variants of the standard sample files.
> And software readers have to beware of files that aren't valid. For many CF
> files and for CF DSG in particular, this is a surprisingly difficult
> problem. Yes, perhaps a human looking at this file for a while will
> conclude (with some level of confidence) that this is a "multidimensional"
> DSG file where the instance dimension has been omitted, but that is very
> difficult for a computer program. With my request for charset and data_type
> attributes, I'm asking for assistance (in making the software reader's job
> easier) and clarity (to remove the ambiguity).
>
> Again, I hope you now find my sample file acceptable. If not, please let me
> know why.
>
>
>
>
> > Date: Thu, 23 Feb 2017 16:22:52 +0000
> > From: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> > To: cf-metadata at cgd.ucar.edu
> > Subject: [CF-metadata] Pre-proposal for "charset"
> > Message-ID: <20170223162252.GA7690 at met.reading.ac.uk>
> > Content-Type: text/plain; charset=us-ascii
> >
> > Dear Bob
> >
> > > CF section 9.5 says: "The variable carrying the cf_role attribute may
> > > have any data type."
> > > And that makes sense, because some profile_id might be an integer and
> > > theoretically could be a single char.
> > >
> > >> Yes, I agree that on the basis of netCDF
> > >> alone
> > >> you can't tell whether it's a string or a 10-char array. However, the
> > >> cf_role
> > >> is a string-valued attribute, according to the CF convention, so it must
> > >> be a
> > >> string. I expect that for contents of netCDF files that follow the CF
> > con-
> > >> vention this ambiguity shouldn't arise - but if there are cases where it
> > >> does
> > >> we should consider them.
> >
> > Sorry. Being in a hurry, because you mentioned cf_role, I assumed you were
> > referring to the attribute, rather than the variable which has that
> > attribute.
> >
> > Looking again at the example you sent, I'd say that this file is not a
> > proper
> > CF DSG file; it contains a number of variables which could be individual
> > timeseries, but they haven't been combined into a single data variable so
> > there is no element (or "station") dimension. The "timeseries" variable
> > which
> > you asked about isn't referred to by any of the data variables. I agree
> > that
> > its function is unclear, but I would say it's not CF-compliant anyway, so
> > CF
> > doesn't need to provide an answer to this ambiguity. The file should look
> > like Example H3, H6 or H7 of the CF document.
> >
> > Best wishes
> >
> > Jonathan
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Fri, 24 Feb 2017 15:56:33 +0000
> > From: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> > To: cf-metadata at cgd.ucar.edu
> > Subject: Re: [CF-metadata] Pre-proposal for "charset"
> > Message-ID: <20170224155633.GA6601 at met.reading.ac.uk>
> > Content-Type: text/plain; charset=us-ascii
> >
> > Dear David
> >
> > I must have overlooked that example, sorry. Please could you spell it out
> > for
> > me? Thanks
> >
> > Jonathan
> >
> > ----- Forwarded message from David Hassell <david.hassell at ncas.ac.uk>
> > -----
> >
> > > Date: Fri, 24 Feb 2017 08:38:13 +0000
> > > From: David Hassell <david.hassell at ncas.ac.uk>
> > > To: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> > > CC: CF Metadata <cf-metadata at cgd.ucar.edu>
> > > Subject: Re: [CF-metadata] Pre-proposal for "charset"
> > >
> > > Hello,
> > >
> > > I think that Jonathan is right about the CF-compliance of the example DSG
> > > file. I think that the confusion still exists for "proper" data
> > variables,
> > > though. Are the Argo profile float profiles (single char data that are
> > > stored in char arrays that Bob mention earlier in the thread) data
> > > variables, or metadata to other data variables?.
> > >
> > > Thanks,
> > >
> > > David
> > >
> > > On 23 February 2017 at 16:22, Jonathan Gregory <
> > j.m.gregory at reading.ac.uk>
> > > wrote:
> > >
> > > > Dear Bob
> > > >
> > > > > CF section 9.5 says: "The variable carrying the cf_role attribute may
> > > > > have any data type."
> > > > > And that makes sense, because some profile_id might be an integer and
> > > > > theoretically could be a single char.
> > > > >
> > > > >> Yes, I agree that on the basis of netCDF
> > > > >> alone
> > > > >> you can't tell whether it's a string or a 10-char array. However,
> > the
> > > > >> cf_role
> > > > >> is a string-valued attribute, according to the CF convention, so it
> > must
> > > > >> be a
> > > > >> string. I expect that for contents of netCDF files that follow the
> > CF
> > > > con-
> > > > >> vention this ambiguity shouldn't arise - but if there are cases
> > where it
> > > > >> does
> > > > >> we should consider them.
> > > >
> > > > Sorry. Being in a hurry, because you mentioned cf_role, I assumed you
> > were
> > > > referring to the attribute, rather than the variable which has that
> > > > attribute.
> > > >
> > > > Looking again at the example you sent, I'd say that this file is not a
> > > > proper
> > > > CF DSG file; it contains a number of variables which could be
> > individual
> > > > timeseries, but they haven't been combined into a single data variable
> > so
> > > > there is no element (or "station") dimension. The "timeseries" variable
> > > > which
> > > > you asked about isn't referred to by any of the data variables. I agree
> > > > that
> > > > its function is unclear, but I would say it's not CF-compliant anyway,
> > so
> > > > CF
> > > > doesn't need to provide an answer to this ambiguity. The file should
> > look
> > > > like Example H3, H6 or H7 of the CF document.
> > > >
> > > > Best wishes
> > > >
> > > > Jonathan
> > > > _______________________________________________
> > > > CF-metadata mailing list
> > > > CF-metadata at cgd.ucar.edu
> > > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > > >
> > >
> > >
> > >
> > > --
> > > David Hassell
> > > National Centre for Atmospheric Science
> > > Department of Meteorology, University of Reading,
> > > Earley Gate, PO Box 243, Reading RG6 6BB
> > > Tel: +44 118 378 5613
> > > http://www.met.reading.ac.uk/
> >
> > ----- End forwarded message -----
> >
> >
> > --
> Sincerely,
>
> Bob Simons
> IT Specialist
> Environmental Research Division
> NOAA Southwest Fisheries Science Center
> 99 Pacific St., Suite 255A (New!)
> Monterey, CA 93940 (New!)
> Phone: (831)333-9878 (New!)
> Fax: (831)648-8440
> Email: bob.simons at noaa.gov
>
> The contents of this message are mine personally and
> do not necessarily reflect any position of the
> Government or the National Oceanic and Atmospheric Administration.
> <>< <>< <>< <>< <>< <>< <>< <>< <><
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
Received on Mon Feb 27 2017 - 11:11:29 GMT
