Dear Dave
> I will be glad to open a trac ticket. Let me have a day or so draft
> some amendment wording. My intention is to use Unidata's
> recommendations in the NetCDF Users Guide as a starting point, and
> include notes about conformance and avoiding conflicts.
Thanks for volunteering. Best
I will be glad to open a trac ticket. Let me have a day or so draft
some amendment wording. My intention is to use Unidata's
recommendations in the NetCDF Users Guide as a starting point, and
include notes about conformance and avoiding conflicts.
--Dave
On Tue, Jan 3, 2012 at 11:49 AM, Jonatha
Dear all - such as Roy, John (Graybeal) and Mark (Hedley)
Would someone have time to open a trac ticket to propose a change to the CF
convention, in order to clarify the Conventions attribute, following all this
useful email discussion? It seems to me that it would be good to make a
definite decis
]
Sent: 02 January 2012 18:47
To: Lowry, Roy K.
Cc: CF Metadata List; sdn2-t...@seadatanet.org
Subject: Re: [CF-metadata] Convention attribute
I wasn't sure how to parse these, I'm a little slow today I guess. After
trying a few ways, I decided they mostly use spaces to separate conventi
I wasn't sure how to parse these, I'm a little slow today I guess. After
trying a few ways, I decided they mostly use spaces to separate convention
identifiers, and slashes to designate hierarchy. (Except the first two embed a
space within "OceanSITES x.x", which I think should be a hyphen.)
o cost.
Cheers, Roy.
From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On
Behalf Of Nan Galbraith [ngalbra...@whoi.edu]
Sent: 30 December 2011 17:16
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Convention attribute
Hmmm, I GUESS it's good that someone n
From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On
Behalf Of Hedley, Mark [mark.hed...@metoffice.gov.uk]
Sent: 29 December 2011 13:27
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Convention attribute
hello Roy
I wonder if this
n
Behalf Of Hedley, Mark [mark.hed...@metoffice.gov.uk]
Sent: 29 December 2011 13:27
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Convention attribute
hello Roy
I wonder if this could be captured by the notation in the Unidata documentation:
'''
Later, if another group agrees upon some ad
e stated that
"mark'sFruityProfile" is CF compliant, is that enough information?
cheers
mark
-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu on behalf of Lowry, Roy K.
Sent: Thu 29/12/2011 10:08
To: Jonathan Gregory; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Co
I think this represents a sensible approach. I think that the name_spacing is
implicit and will have to remain so.
I think a strong statement detailing the responsibility placed on the data
provider to have checked that the metadata is unambiguously consistent with all
standards stated in the
t: Re: [CF-metadata] Convention attribute
Dear Mark and Dave
I agree with Dave's answers. If two conventions are used together, it is the
responsibility of the data-writer to guarantee that the metadata supplied is
consistent if there are any overlaps in meaning. A particular case of that is
Dear Mark and Dave
I agree with Dave's answers. If two conventions are used together, it is the
responsibility of the data-writer to guarantee that the metadata supplied is
consistent if there are any overlaps in meaning. A particular case of that is
if the two conventions define attributes with t
Mark,
That is an important question. I suggest that there is only one
practical interpretation for multiple conventions: 100 percent
compiance with the requirements of each listed convention. This leads
to immediate answers for your questions, as follows.
On Wed, Dec 28, 2011 at 9:59 AM, Hedley
Perhaps this problem can be resolved if we carefully distinguish between the
convention *identifier* in the Conventions attribute, and the convention name
(which can be in any other attribute, like Convention_Names or
Metadata_Conventions). For the names we could specify either attribute, or
bo
Seems a bit extreme to say that a convention is not compatible with CF
just because it has a name with spaces in it. Apart from the
Conventions attribute, a file can be completely conformant with both CF
and one or more other conventions. I feel like our goal should be to
maximize the ability
Dear all
This is certainly a lively thread! :-)
An array of strings would be nice but I don't think we should do that because
it's not compatible with the Unidata convention and it depends on the non-
classic netCDF model. In this case we can probably get by without it. While
we can't control the
On 22/12/11 18:00, John Graybeal wrote:
> So my vote
> is to create a truly machine-friendly way of handling convention
> identifiers and clearly spell it out in the standard.
Sounds like an array of strings if you're really going for a clean
solution ;)
Delimiters (and anything embedding informa
I'm confused by several comments on this thread.
If netCDF has always been explicit about space-delimited convention
identifiers, what explains the existence of a convention identifier with a
space in it (Conventions = "OceanSITES 1.1, CF-1.1")?Does netCDF have a
review process for netCDF c
Russ (and thus core netcdf) has always been explicit about space-delimited
conventions, so really there shouldn't be any conventions with spaces in
the names.
On the other hand, we have adopted the technique of using the convention
name as a pattern to match against the convention attribute, so th
On 12/22/2011 2:11 AM, Jonathan Gregory wrote:
Dear all
The existing Unidata recommendation is OK and we could incorporate it into
CF but it would help to be more precise, for instance: If the Conventions att
includes no commas, it is interpreted as a blank-separated list of conventions;
if it c
It is "easier" (not by much, code-wise) to not to allow commas as
delimiters, but if you want to allow for machine-recognition of
convention names, how are you going to handle conventions that have
spaces in their names? Telling everyone else to get rid of spaces isn't
a practical solution, an
Thanks Russ, Dave(s), Jonathan and Lorenzo -
Thanks for the clarifications. I agree that it makes sense to
require that convention names not contain spaces, and that
it's easier (and more CF-like, hence better!) to parse space
separated terms.
Cheers - Nan
The recommendation on the Unidata sit
Hi all,
my opinion is to keep with the current recommendation, which better supports
automatic parsing and the existing conforming datasets.
In particular, I would avoid any parsing rule for the conventions attribute,
keeping its syntax as simple as possible (as Jonathan points out,
blank-separ
Dear all
The existing Unidata recommendation is OK and we could incorporate it into
CF but it would help to be more precise, for instance: If the Conventions att
includes no commas, it is interpreted as a blank-separated list of conventions;
if it contains at least one comma, it is interpreted as
Russ et al,
I suggest that the Unidata recommendation needs to be changed to
commas only. I recall seeing recent cases where a convention name
includes spaces, but I have never seen a comma in such name. Case in
point, from Nan's follow-up:
Conventions = "OceanSITES 1.1, CF-1.1" ;
Also I ag
Ah, thanks, I guess that's another solution.
In OceanSITES, we have added ours to the main Conventions
attribute, so we have
Conventions = "OceanSITES 1.1, CF-1.1" ;
which might not be ideal... I was fairly sure we'd discussed it
on this list, but ma
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
Hi Nan,
Within ACDD the guidance is to use:
Metadata_Conventions = "Unidata Dataset Discovery v1.0";
This is documented at the top of the Unidata page but not within the
listed HTML tables which I think makes it easy to overlook.
http://www.unidata.ucar.edu/software/netcdf-java/formats/DataD
Hi all -
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
29 matches
Mail list logo
