I think one the important factors, implied if not stated is what is
meant by accuracy.
One approach is to set all non specified values to 0, such that:
1930-01-01 == 1930-01-01T00:00:00Z
Another appraoch is to take the accuracy to be encompassing, such that:
1930-01-01 == 1930-01-01T00:00:00Z
There are global attribute names defined with specific meaning in 2.6.2
Description of File Contents
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/ch02s06.html#description-of-file-contents
Specifically the names:
institution
source
It is a common operation to combine data from
It seems like there is support for this proposal. What should I do to make
this happen?
many thanks
mark
-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu on behalf of Jonathan Gregory
Sent: Fri 23/09/2011 18:14
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] standard
Hello Patrick
Phil Bentley has recently commented on the benefits of using OGC WKT within the
CF data representation.
I believe he is preparing a proposal to this effect, which would address the
issue you have highlighted, I think, and a range of other similar issues
relating to the
Hello Mike
there is a ticket open on the TRAC system proposing the use of OGC WKT to
describe coordinate reference systems:
https://cf-pcmdi.llnl.gov/trac/ticket/69
Would this give you the vocabulary you require?
mark
-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu on
To define a coordinate reference system, a grid_mapping variable is defined,
with variable attributes to define the coordinate reference system attributes.
(http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/ch05s06.html)
I would like to define coordinates, be they coordinate variable or
of transverse_mercator in a trajectory file that includes the triplets
of projection_zone, projection_x_coordinate, and projection_y_coordinate
should be adequate for indicating a UTM trajectory.
Mike
-Original Message-
From: Hedley, Mark [mailto:mark.hed...@metoffice.gov.uk]
Sent: Monday, October 17
;
crs:semi_major_axis = 6378137.0 ;
crs:inverse_flattening = 298.257223563 ;
-Original Message-
From: Jonathan Gregory [mailto:j.m.greg...@reading.ac.uk]
Sent: Tue 25/10/2011 15:13
To: Hedley, Mark
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Connecting coordinates to Grid
Hello
I think the approach:
to extend CF to allow you to preserve the original time axis to which the
first operation applied, even though it is no longer provides the time
coordinates once the second operation has been carried out.
is of particular interest. I do not agree that I 'prefer
reference systems.
many thanks
mark
-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu on behalf of Hedley, Mark
Sent: Wed 26/10/2011 16:44
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] FW: Connecting coordinates to Grid Mapping variables
Hello
Actually I am unclear
Hello David
Thank you for sharing your thoughts. Having considered input from you and
Jonathan I think that I am convinced that an extended grid_mapping syntax
represents a good approach to meeting the requirements I am aware of.
I guess the next step is to create a trac ticket and propose
I am interested in the implications for defining multiple conventions in the
same file. As a data creator, what am I asserting by defining my file with
multiple conventions?
It could be said that the conventions attribute provides an implicit name space
for the controlled terms it defines.
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, Mark
mark.hed...@metoffice.gov.uk wrote:
I am interested in the implications for defining
I am pleased to see the chapter on Discrete Sampling Geometries in the 1.6
version of CF
Appendix H provides useful examples of datasets using the approach detailed in
chapter 9
Is there a package of such sample data files available for software developers
to use as test cases for building
hello Roy
I wonder if this could be captured by the notation in the Unidata documentation:
'''
Later, if another group agrees upon some additional conventions for a specific
subset of XXX data, for example time series data, the description of the
additional conventions might be associated
I think that the important factor in the text posted by Jonathan:
'''Generic applications should treat the data as missing where any
auxiliary
coordinate variables have missing values; special-purpose applications
might
be able to make use of the data.'''
is that it puts the onus on
this cause concern?
many thanks
mark
-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu on behalf of Hedley, Mark
Sent: Thu 05/04/2012 17:35
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] identification of vector components
There is a statement in the definition of many standard
-metadata@cgd.ucar.edu
Cc: Hedley, Mark
Subject: Re: [CF-metadata] identification of vector components
Hi Mark
Sorry, silence doesn't mean consent.
I think it is exactly the place of standard names to be completely proscriptive
about what terms mean.
The you say x, I say x, and we both mean
for the implicit lat-lon grid that CF allows and tends to be the default in the
GCM community.)
Thoughts?
Jon
-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Hedley, Mark
Sent: 19 April 2012 12:51
To: cf-metadata@cgd.ucar.edu
as my data. If that turns out
to be east, that's a useful piece of downstream information, not a core part of
the phenomenon definition.
mark
-Original Message-
From: Jon Blower [mailto:j.d.blo...@reading.ac.uk]
Sent: Fri 20/04/2012 18:46
To: Hedley, Mark; cf-metadata@cgd.ucar.edu
Subject
The CF Specification
(http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/ch04s02.html) states:
'Optionally, the longitude type may be indicated additionally by providing the
standard_name attribute with the value longitude, and/or the axis attribute
with the value X.'
Which suggests that
Dear Jonathan et al.
I appreciate the concerns and I agree that the current situation provides the
information required, however I do not feel comfortable with the way it is
done: I think it is open to ambiguity and I am concerned that there are
multiple standard names for what I consider the
Hello
I have had some time to consider this issue and I am still of the view that a
change is needed to the standard name definitions for vectors, and that this is
not simply a matter on convenience. I assert that
'grid_aligned_vector_component_of_...' is the key piece of information.
But,
Hello
I have considered a slightly alternative approach to getting what I would like
while being considerate of the concerns raised to date.
I wonder whether we could use the approach of constraining standard names, as
with qualification. For example:
there is a standard name of
Hello CF community
I am interested in taking the excellent work on a logical data model for CF
Jonathan and David documented in https://cf-pcmdi.llnl.gov/trac/ticket/68
further, in the hope that this may reach a stable, agreed state.
I would like to address the scope and terms of reference of
I am cross posting with regard to ticket #89
(https://cf-pcmdi.llnl.gov/trac/ticket/89)
This comment:
https://cf-pcmdi.llnl.gov/trac/ticket/89#comment:4
presents a choice, which I encourage interested parties to state their view on,
either on the ticket or by e-mail to myself and Jonathan.
Dear Alison
I note from your previous post that:
I plan to make the next update of the standard name table on 30th August
As ticket 89 (https://cf-pcmdi.llnl.gov/trac/ticket/89) has passed it's 3 week
objection window without further comment I believe this change is approved by
the
Hello CF Community
There has been agreement, on ticket 88, that a data model for CF would be
beneficial, and the terms of reference for the development and maintenance of
this model.
I have started a Wiki page on the CF Trac site, my hope is that we can develop
a list of defined
...@gmail.com on behalf of Ben Domenico
Sent: Tue 18/09/2012 22:48
To: Hedley, Mark
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Data Model Development | types
Hi Mark,
Thanks for making a great start. One addition I might suggest is to have
an example or two for each type. That would
I have put a couple of posts onto a trac ticket:
https://cf-pcmdi.llnl.gov/trac/ticket/68#comment:26
but these do not seem to be posted to the mailing list, which is unfortunate, I
thought this functionality had been implemented.
Apologies for anyone who already has these, but I don't want them
Hello Jim
If I have caught your sense correctly, I think this was the objective for the
change proposed in
https://cf-pcmdi.llnl.gov/trac/ticket/70
This ticket has been accepted and is waiting for the next version of the CF
conventions for NetCDF files to be put forward.
Do you think this
into the association loop?
Grace and peace,
Jim
Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites
Remote Sensing and Applications Division
National Climatic Data Center
151 Patton Ave, Asheville, NC 28801-5001
jim.bi...@noaa.gov
828-271-4900
On Oct 15, 2012, at 10:24 AM, Hedley, Mark
Hello Mark
It looks a bit like your two examples are two different datasets.
In Example 1 you have a Wind_SFC value for each pair of projection coordinates;
the data is 2D whilst the projection coordinates are 1D. To be CF compliant
you must include latitude and longitude coordinates in
Hi Martin
Could you clarify your case a little please?
Are you providing a colour (as rgb?) for each data value in the cloudmask,
cloudtype datasets?
in which case I might include a (?,?,?,3) array of r,g,b values alongside
each dataset
or
Are you providing a colourmap linking rgb values
Hi Chris
I heartily agree with sentiments expressed here, I particularly like this:
So: in short -- the CF data model should be more general, and deal with data
concepts, separate from encoding of those data. File formats should specify
encoding, and libraries should handle
Hello CF community
I have been perusing the CF conventions again, particularly the section on
Ancillary Data
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/ch03s04.html
The conventions make the statement:
The nature of the relationship between variables associated via
; the
individual component variables (like serial number) have a dimension
that matches
the depth dimension of the obs data variables.
- Nan
On 2/13/13 12:15 PM, Hedley, Mark wrote:
Hello CF community
I have been perusing the CF conventions again, particularly the section on
Ancillary Data
http
these are types of case I am particularly concerned to find examples
of, or, preferably, discount explicitly.
much obliged
mark
On 2/13/13 12:15 PM, Hedley, Mark wrote:
a. reference the same file dimensions as the data variable with the
ancillary_variables attribute references
b. reference
I would appreciate community views on the interpretation of global attributes
from a NetCDF file.
Scenario:
- My file has multiple data variables and a list of global attributes.
- I am loading one data variable and the associated information from one file.
Question:
- The global
to moderate this
ticket?
thank you
mark
From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Hedley, Mark
[mark.hed...@metoffice.gov.uk]
Sent: 18 February 2013 10:45
To: andrew walsh
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Ancillary
Patton Ave, Asheville, NC 28801-5001
jim.bi...@noaa.govmailto:jim.bi...@noaa.gov
828-271-4900
On Mar 14, 2013, at 7:53 AM, Hedley, Mark
mark.hed...@metoffice.gov.ukmailto:mark.hed...@metoffice.gov.uk wrote:
Thank you for the responses on this topic.
So far I have not found an example of ancillary
input on this topic
mark
From: Jim Biard [jim.bi...@noaa.gov]
Sent: 15 March 2013 12:58
To: Hedley, Mark
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Ancillary Data
Mark,
I'm looking at this from the standpoint of the use of an ancillary variable
Hello Randy
Is the image regular in location and resolution (with respect to a defined
coordinate reference system)?
If so, could an approach be to create a regular coordinate type which can
simply encode all of this information in one place?
such a type could be expanded at will to provide
Hello CF
We have identified a perceived uncertainty in the CF conventions document which
we strongly feel needs clarification. I would like to update the conventions
document to remove this ambiguity. In order to update the text we have to
agree on the objective.
(a statement of A or B is
The term 'convenience feature' is mentioned in the conventions document:
'The new scalar coordinate variable is a convenience feature which avoids
adding size one dimensions to variables.'
Data creators have seen the benefits in not encoding size one dimensions and
made use of this feature,
. Casey - NOAA Federal kenneth.ca...@noaa.gov
Date: Tue, 21 May 2013 07:22:34 -0400
To: Hedley, Mark mark.hed...@metoffice.gov.uk
X-Mailer: Apple Mail (2.1503)
CC: cf-metadata@cgd.ucar.edu cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] scalar coordinates
Hi Everyone,
After spending 15
available.
mark
From: Kettleborough, Jamie
Sent: 24 May 2013 12:34
To: Hedley, Mark; cf-metadata@cgd.ucar.edu
Cc: Kettleborough, Jamie
Subject: RE: [CF-metadata] scalar coordinates
Hello Mark,
I'm not sure I understand your example:
For example a data
Hello CF
A few standard names:
sound_intensity_level_*
sound_pressure_level_*
have a stated canonical units of dB. I think valid units in CF are defined by
udunits2.
My install of udunits (udunits2-2.1.24) does not recognise dB as a valid units
string.
Is this an issue for the CF standard
Hello
The discussion on CF-1.6 DSG clarification: time series lat/lon coordinates
provides us with further example of the use of scalar coordinates and their
potential interpretation. I would like to use this to investigate the question
of scalar interpretation.
The conversation on this
Hello Jonathan
As a result of this discussion, it seems me that for a DSG (which is
indicated by the presence of featureType), scalar coordinate variables have
to be interpreted as auxiliary coordinate variables of an omitted size-one
instance dimension. That is what is implied by section
have found it
important to separate the data model and the encoding of the model in
the netCDF file. Probably you are both already doing that, but I wasnt sure.
John
On 6/7/2013 3:23 AM, Hedley, Mark wrote:
Hello Jonathan
As a result of this discussion, it seems me that for a DSG (which
To: Hedley, Mark
Cc: CF Metadata List
Subject: Re: [CF-metadata] publishing standard names
Mark,
While there is a close relationship between NERC and CF, they are not the only
two mechanisms publishing CF terms. The MMI vocabulary server,
http://mmisw.org/orr, also publishes CF standard name
Hello Jonathan
The reason why this is hard to settle is that, as we have agreed, it has no
implication at all for the netCDF file. It is just a matter of interpretation.
This doesn't seem right to me, my thought process is addressing how we encode
concepts and what concepts are allowed to be
I'm not sure of the details, I'll need to dig out some reference material, but
is NetCDF-U and it's work with uncertainty and statistics providing some
insight into how to represent this kind of informaiton?
From: CF-metadata
I think the need for CF 1.7 is clear. There are a lot of agreed tickets to
process.
I am particularly concerned by the comment:
Making a new version of CF depends on Jeff Painter or a colleague at PCMDI
having time to do it, I presume.
I am worried that this factor is a barrier to
The important factor for me is the work flow and people, not the technology.
Git and github are a bit nicer to work with than svn, the merging is a bit
better etc but we can support collaborative editing either way around.
I will vote for github as it has a number of useful tools and the work
. Making edits can sometimes be a lot simpler
than understanding what someone else has done.
Cheers - Nan
On 9/30/13 1:18 PM, Hedley, Mark wrote:
The important factor for me is the work flow and people, not the technology.
Git and github are a bit nicer to work with than svn, the merging is a bit
Hello CF
I am interested in defining cell methods where there are no coordinates.
I have a set of cases which I do not think fit the patterns in the current
conventions.
I suggest that we provide further capability for defining cell method instances.
I have prepared a use case on the Trac
From: Steve Hankin [steven.c.han...@noaa.gov]
Sent: 25 October 2013 17:15
To: Hedley, Mark
Cc: CF metadata
Subject: Re: [CF-metadata] Cell methods when there are no coordinates
Hi Mark,
Volumes of documentation have been written about cell_methods that I have
Hello CF
It looks like the uncertainty surrounding scalar coordinate variables is
reaching a conclusion which is likely to make it into CF1.7
https://cf-pcmdi.llnl.gov/trac/ticket/104
The broad brush conclusions are forming and I suspect that the remaining
conversation will focus on editorial
Hello Jonathan et al
The current syntax is clear about using the 'name' to reference a dimension for
the cell method.
In the case I have described I am wary about creating length one coordinates
for realization, experiment_id, source and institution, it is not clear to me
how to do this
, not currently supported by CF,
with utility in a number of scenarios.
If there are no strong objections I will raise a trac ticket proposing this
enhancement to CF.
thank you
mark
From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Hedley, Mark
[mark.hed
.
many thanks for your comments and thoughts
mark
From: Jonathan Gregory [j.m.greg...@reading.ac.uk]
Sent: 09 November 2013 21:07
To: Hedley, Mark
Cc: CF metadata
Subject: [CF-metadata] Cell methods when there are no coordinates
Dear Mark
Thanks
of the daily maximum air_pressure
values at the surface in hPa
I thought the was the raison d'etre of the cell_methods string
mark
From: Steve Hankin [steven.c.han...@noaa.gov]
Sent: 12 November 2013 17:49
To: Gregory, Jonathan
Cc: Hedley, Mark; CF metadata
Subject: Re
Hello Rich
I think that using the WKT representation for vertical datum definitions is a
good approach
As you have indicated, it is to be supported in CF 1.7 and provides a
controlled terminology set for this purpose.
There is an example using the OS Newlyn datum in the draft spec which fits
We could modify this to:
Allowed for auxiliary coordinate variables but not allowed for coordinate
variables. Missing data is only permitted in auxiliary coordinate varirables
only at points where the data variable(s) concerned has missing data.
I would support this, I think there are use
I agree; I don't see a need for a 'null'
I think the currently available grid mapping types will be fit for the vertical
datum purposes so far discussed
mark
From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Jim Biard
[jbi...@cicsnc.org]
Sent:
Hello CF
I think this is an excellent proposal. In particular it would be very useful
for the conclusion of a request for change (ticket) to include the explicit
change to the CF conventions documents including review and commit.
Being able to access the latest development version of the
Hello CF
I have been having an interesting conversation with some modelling colleagues
regarding the standard names and descriptions for cloud amount:
cloud_area_fraction:
'X_area_fraction' means the fraction of horizontal area occupied by X. 'X_area'
means the horizontal area occupied by X
the
different types.
Heiko
On 2014-06-11 15:41, Hedley, Mark wrote:
Hello CF
I have been having an interesting conversation with some modelling
colleagues regarding the standard names and descriptions for cloud amount:
cloud_area_fraction:
'X_area_fraction' means the fraction of horizontal area
.'
thank you
mark
From: Heiko Klein [heiko.kl...@met.no]
Sent: 18 June 2014 08:20
To: Hedley, Mark; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] cloud amounts
Hi Mark,
the first proposal for the *_cloud_area_fraction was in fact
high/medium/low
Hello CF
We have a requirement to calculate volume integrals for a large range of model
diagnostics. We would like a method to correctly identify these derived fields.
I am interested in creating a new cell_method, an integral, which would allow
us to use this approach with any standard name.
Hello Jonathan, Karl
many thanks for all the feedback; It looks like I will need to get to work with
a package of standard_name definitions. I had hoped to circumvent this effort,
but if you think that is not possible, then it will need to be done.
I will report back when we have collated a
Hi Richard
I see no responses yet on prior art for this concept, perhaps it is not widely
used in CF-netCDF.
If that is the case, may I suggest that a new standard_name is required to
label such a coordinate?
perhaps
data_cut-off_time
s
A datetime which defines the instant after which
Hello CF
The standard name
realization
is available for use:
Realization is used to label a dimension that can be thought of asa
statistical sample, e.g., labelling members of a model ensemble.
It is common practice in forecasting and some forecasting formats to explicitly
state the number
Hello CF
I understand that netCDF coordinate variables have to be strictly monotonic,
and no-one wants to define what this means for the general case of strings;
that is fine.
But I believe that I can create a CF auxiliary coordinate with string values
without any concern.
I am interested in
coordinate vars to exist with this dimension (though they
could if you want to supply them too).
Best wishes
Jonathan
- Forwarded message from Hedley, Mark mark.hed...@metoffice.gov.uk -
From: Hedley, Mark mark.hed...@metoffice.gov.uk
To: cf-metadata@cgd.ucar.edu cf-metadata@cgd.ucar.edu
Date
Hello Jonathan
Do you mean The expected length of the realization coordinate and dimension,
if the whole ensemble *was* present? I mean, is the whole ensemble present
or not? I'm sorry, I'm not clear what you mean still.
In my use case, the whole ensemble is not present, I only have a
Hello Brendan
I believe the intent of the rotated pole grid mapping definition is to describe
a polar coordinate reference system, based on the earth, but with a different
axis of rotation.
To do this, a new north pole location is specified in the earth polar
coordinate reference system by
--
Brendan DeTracey
brendan.detra...@dfo-mpo.gc.camailto:brendan.detra...@dfo-mpo.gc.ca
(902)426-9727 3-30 VS
Marine Ecosystem Section / Section de l'écosystème marin
From: Hedley, Mark [mailto:mark.hed...@metoffice.gov.uk]
Sent: October-17-14 8:14 AM
To: DeTracey
Hello CF
From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Jonathan
Gregory [j.m.greg...@reading.ac.uk]
Yes, there are some standard names which imply string values, as Karl says.
If the standard_name table says 1, that means the quantity is dimensionless,
so it's also
Thank you for the discussion on the number of realizations in an ensemble.
Please may people raise any further concerns about a new standard name:
number_of_realizations
with a canonical unit of
''
and a description of
The number of member realizations within a given ensemble.
This name
Please could any further objections to this proposal be raised, as I would like
this entry added to the standard names list.
thank you
mark
From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Hedley, Mark
[mark.hed...@metoffice.gov.uk]
Sent: 02
on usage, but I don't think '-' characters are allowed, so
data_cutoff_time or data_cut_off_time are probably better choices. I like
data_cutoff_time better, but that's just me.
Grace and peace,
Jim
On 10/30/14, 4:40 AM, Hedley, Mark wrote:
Please could any further objections to this proposal
number_of_realizations = 9
I just unpacked this into a single label, to illustrate the information wanted
(but I seem to have reduced clarity again; never mind).
mark
From: John Graybeal [jbgrayb...@mindspring.com]
Sent: 30 October 2014 17:10
To: Hedley, Mark
Cc: CF Metadata
be good to clarify.
John
On Thu, Oct 30, 2014 at 2:37 AM, Hedley, Mark
mark.hed...@metoffice.gov.ukmailto:mark.hed...@metoffice.gov.uk wrote:
Hello CF
From: CF-metadata
[cf-metadata-boun...@cgd.ucar.edumailto:cf-metadata-boun...@cgd.ucar.edu]
on behalf of Jonathan Gregory
[j.m.greg
.
From: Eizi TOYODA [toy...@gfd-dennou.org]
Sent: 31 October 2014 08:44
To: John Graybeal
Cc: Hedley, Mark; CF Metadata List
Subject: Re: [CF-metadata] string valued coordinates
Hi John
I think '?' is not a definition that is helpful to most users -- it is more
like
to its original group
(even if the group is no longer intact).
mark
From: John Graybeal [jbgrayb...@mindspring.com]
Sent: 31 October 2014 17:27
To: Hedley, Mark
Cc: CF Metadata List
Subject: Re: [CF-metadata] realization | x of n
As I indicated, I think if we're
no
units attribute present?
Grace and peace,
Jim
On 10/31/14, 11:04 AM, Hedley, Mark wrote:
Thank you for all the responses, it sounds like 'all of the above' is the
preferred response to my suggestions of plausible next steps. I will pursue
all of these.
Eizi's point about having no_unit
-conventions.html#units
and let us know if your position remains the same?
I am afraid I do not think it is born out by the specification.
all the best
mark
From: Jim Biard [jbi...@cicsnc.org]
Sent: 04 November 2014 16:45
To: Hedley, Mark; cf-metadata@cgd.ucar.edu
suppose you could attach this information to the data variable using a
scalar coordinate variable - is that what you think?
Best wishes
Jonathan
- Forwarded message from Hedley, Mark mark.hed...@metoffice.gov.uk -
Date: Fri, 31 Oct 2014 14:50:53 +
From: Hedley, Mark mark.hed
standard_names which appear not to
follow this approach (I have only 'area_type' so far).
I hope this seems like a reasonable response.
From: Eizi TOYODA [toy...@gfd-dennou.org]
Sent: 31 October 2014 08:44
To: John Graybeal
Cc: Hedley, Mark; CF Metadata List
@cgd.ucar.edu
Subject: CF-metadata Digest, Vol 139, Issue 4
Send CF-metadata mailing list submissions to
cf-metadata@cgd.ucar.edu
Message: 2
Date: Tue, 4 Nov 2014 16:38:12 +
From: Hedley, Mark mark.hed...@metoffice.gov.uk
To: Jim Biard jbi...@cicsnc.org, cf-metadata@cgd.ucar.edu
cf
From: Jim Biard [jbi...@cicsnc.org]
Sent: 04 November 2014 17:45
To: Hedley, Mark; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] string valued coordinates
Mark,
As I read the CF Conventions document, my conclusion is that CF currently
conflates the two concepts 'doesn't have units
Hello Jim et al
I have followed your path and I agree with your analysis
It looks like my assumption, and a whole part of my discussion thread, is based
on a piece of code in a third party udunits wrapper which is not part of
udunits. Hence I have been muddying the issue with an
From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Hedley, Mark
[mark.hed...@metoffice.gov.uk]
Sent: 03 August 2015 17:10
To: Jim Biard; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] original_ensemble_size
Hello Jim
I like your thinking on this topic
Hello Martin et al
this sounds an awful lot like an extensive feature definition to me.
such definitions are widely supported in spatial data sets and software.
It would be very useful to be able to define these in CF. I would not limit
this (in principal) to defining the start and end of a
and the ensemble size in the attribute.
Grace and peace,
Jim
On 7/23/15 6:11 AM, Hedley, Mark wrote:
I use the
'coordinates'
attribute on my data variable, referencing the scalar 'ensemble_size' variable,
thus defining this ensemble_size as a scalar coordinate variable for the
temperature dataset
mark
Hello Karl
I agree with your analysis that it is unlikely that a data variable will ever
vary with ensemble_size, so having ensemble_size as a scalar coordinate is
slightly odd, in that we'd not expect it to be anything other than scalar.
It would meet my use case, but I can see the interest in
there shouldn't be a
need for a modified ensemble size, so wouldn't ensemble size suffice?
thanks,
Karl
On 7/20/15 9:24 AM, Hedley, Mark wrote:
Hello CF
Late last year we had a discussion about storing
original_ensemble_size
in a CF file
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2014
1 - 100 of 110 matches
Mail list logo
