So there are an infinite number of ways to decompose a 3-D orientation into
three orthogonal rotations. Specifying the projection in terms of the final
location of the north pole and an optional rotation around that point means
that CF is actually agnostic about exactly how you get there.
That sa
CDO is great if your data is on a lat-lon grid, but on curvilinear grids it has
a tendency to trash the ancillary data. I would not recommend it for something
like Izidor's use.
(At least, that was my experience the last time I used it; possibly it's better
now, but I haven't read anything in the
1) Set the time values to the midpoint of the time interval.*
2) Set a "cell_methods" attribute on the data variable with a
value of "time: mean (interval: 1 month)".
3) Create a time_bounds variable with dimensions (time,2)
whose values are the start and end points of each time interval.
4) S
If your intervals are contiguous, time_bounds[i,1] should equal
time_bounds[i+1,0] (See the beginning of section 7.1 in the CF spec.) So for
January 2013, you should set the endpoint to 2013-02-01 00:00:00.
(The resulting potential for confusion is why I think it's best practice to put
the time
office.gov.uk
>
>
>-Original Message-
>From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Seth
>McGinnis
>Sent: 15 March 2013 22:01
>To: Andreas Hilboll; CF-metadata@cgd.ucar.edu
>Subject: Re: [CF-metadata] how to specify time dimension for
Um, I don't think that's true, actually. That's probably a sensible convention
to follow in many cases, but I don't believe it's a CF requirement. (Or at
least, I never noticed it. If it is in there, we need to edit the spec to make
it more prominent!)
Cheers,
--Seth
On Mon, 18 Mar 2013 08:2
Hi all,
I'm a bit late to the discussion, but I just want to go on the record as being
(fairly strongly) opposed to allowing *anything* to be expressed as a string
if there's a reasonable numeric representation we can use instead.
Maybe I'll change my mind after the community has made the jump t
On Thu, 28 Mar 2013 09:22:57 -0400
Aleksandar Jelenak - NOAA Affiliate wrote:
>On Fri, Mar 22, 2013 at 4:31 PM, Seth McGinnis wrote:
>> Maybe I'll change my mind after the community has made the jump to
>> netcdf4
>
>Dear Seth,
>
>What benchmark do you suggest to
I'll agree with option A.
I can think of a number of cases where scalar coordinate variables
are a convenient way to record metadata about the positioning
of the data in space-time, but it's not like the data at other
positions actually exists and isn't recorded in this file; it's just a
way of fo
Hi Ellyn,
According to CF Trac Ticket #31 (slated for inclusion in the update to CF 1.7),
the way to cache minimum & maximum values in metadata is to use an attribute
named "actual_range" and store them as a pair.
(I kind of think this is a bad idea, and wish that ticket was still open. I
missed
>> Computing the min & max on the fly is cheap, and approximating it is even
>> cheaper, so why introduce the uncertainty?
>
>... but computing min & max on the fly can also be very expensive.
>We have aggregated model output datasets where each variable is more
>than 1TB!
Sure, I can see that t
Hi Jonathan,
I would like to suggest a small modification to your proposal for the
lifted index (LI) standard_name.
I'm working on proposals for standard_names for CAPE, CIN, LCL, and
LFC, all of which, like LI, are based on lifting a parcel of air
adiabatically from one height to another.
The u
Greetings CF mailing list!
I would like to propose some new standard_names related to convective
instability indices.
I apologize for sending such a long proposal right before a holiday
weekend in the US, but I've been working on it for a while and it
dovetails with the recent discussion of a sta
--
>Dr Philip Cameron-Smith, p...@llnl.gov, Lawrence Livermore National Lab.
>-------
>
>-Original Message-
>From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Seth
>McGinnis
>Sent: Friday, May 24, 2013 4:
Hi Jonathan,
I suggested two such standard_names in an email on Friday,
because I need them for various CAPE/CIN/etc standard_names:
air_pressure_of_lifted_parcel_at_start
air_pressure_of_lifted_parcel_at_finish
These would have the following definitions:
Various stability and convective poten
adiabatically from there to an ending height (often the top of
>the data/model/atmosphere). air_pressure_of_lifted_parcel_at_origin
>[finish] is the pressure height at the start [end] of lifting.
>
>Canonical units: Pa
>
>
>I will also revise the definition of the total total
two
>arbitrary pressure levels, and thus should include your two proposed
>air_pressure_of_X standard names.
>
>Sincerely,
>
>Jonathan
>
>On 5/29/2013 2:11 PM, Seth McGinnis wrote:
>> Hi Jonathan,
>>
>> I suggested two such standard_na
Hi Jonathan (G),
I had thought we needed the finish level for CAPE and CIN, but after
consulting with a colleague, I realize we actually don't need it.
For the CAPE & CIN calculations, you integrate until the parcel hits
equilibrium. I am assured that it will suffice just to mention that in the
Works for me. And although I don't need it for CAPE, I like Jonathan W's
suggestion of final_air_pressure_of_lifted_parcel for the upper limit.
(I was originally thinking it would be preferable to have the physical quantity
(air pressure) at the beginning, but looking at the Guidelines for Constr
Hi all,
Since they are going to be used in conjunction, at least some of the time, I
favor the parallel construction of original_air_pressure_of_lifted_parcel and
final_air_pressure_of_lifted_parcel. It makes the semantic link between the
two quantities more obvious.
Cheers,
--Seth
On Wed, 0
integrating the temperature
>difference between the parcel and environment, where the parcel temperature
>may be corrected due to the moisture content of the air parcel (e.g. the
>virtual temperature). Using "temperature difference" as opposed to a specific
>temperature, e.
Hi all,
Here are the updated proposals for new standard names for CIN, LFC, and LCL;
an update to the standard name for CAPE; and the two standard names for the
starting and ending heights of lifted parcels.
Following the suggestion that came up in our discussion, these come in pairs:
the basi
On Mon, 17 Jun 2013 13:49:30 +0100
Jonathan Gregory wrote:
>Dear Seth
>
>Thanks for the updated list of names. This all looks logical to me.
>
>I now wonder whether, in the names, wrt_surface would convey the meaning more
>obviously than from_the_surface. It's not obvious until you read the
>defi
Hi Jonathan,
Frankly, no, I'm not certain. My thinking is that if anyone is using the
existing standard_name, their data is somewhat underspecified, and
since it could in principle be one of many types of CAPE, it would be
preferable to point to the more generic name.
If anybody on the mailing
Hi Richard,
I'm confused by 1). Could you explain further?
It sounds like what you mean is that you want to propose that the
basetime specified by the units attribute should not have an offset
specifier after the date-time if the calendar is not real-world.
That makes sense, although I don't th
as-is...
So yes, I think it's significant that the data coming out of
THREDDS is in a different convention than the source files, and
that it's cause for concern.
Cheers,
--Seth
Seth McGinnis
NARCCAP Data Manager
NCAR - IMAGe
On Wed, 28 Aug 2013 10:11:10 -0700
John Grayb
ed, 28 Aug 2013 17:25:21 -0600
John Caron wrote:
>Hi Seth:
>
>On 8/28/2013 12:59 PM, Seth McGinnis wrote:
>> Hi Sean,
>>
>> Personally, I would regard that as suspect behavior.
>>
>> I'm of the opinion that it's best practice for a data s
_available_potential_energy should be
> made an alias of proposal (7) or (8). Once we can resolve that
> question the names can be added. Please see
> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056725.html
> and
> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056
Hi all,
I think ultraviolet_index, all spelled out, is better. If you
abbreviate it uv_index, you have the potential to confuse people who are
used to thinking about U and V as symbolizing wind vectors.
Cheers,
--Seth
On 11/15/13 1:58 AM, Jonathan Gregory wrote:
> Dear Oystein
>
> Since the
In this dataset, lat and lon aren't coordinate variables, they're
auxiliary coordinate variables. There's no requirement that auxiliary
coordinate variables be monotonic or lacking in missing_values. Your
coordinate variables will be the ones associated with the I and J
dimensions of the arrays.
Hi all,
I have to agree with Randy. When you're producing data, you generally
don't have time to wait for the standard to stabilize, you just do your
best to find whatever elements of CF are a decent match to the problem
at hand and use them, regardless of whether or not they might be marked
'pro
using in a published data product.)
In any case, I don't think there's really a standard "best" answer, so
the most important thing is to document your choice thoroughly. As long
as the end-user can easily figure out how you handled leap days, I think
it's reasonable for you to
h
> individual year, and then the set of means for Jan 1 for each year
> are averaged.
>
> Grace and peace,
>
> Jim
>
> On 6/2/14, 2:32 PM, Seth McGinnis wrote:
>> Jim--
>>
>> Section 7.4 covers climatologies. My understanding of it is:
>>
>&
rting period was 9am-9am GMT, but following
WMO guidance effectively adjusts this to 0Z-0Z."
Cheers,
--Seth
Seth McGinnis
NARCCAP Data Manager
Associate Scientist III
RISC / IMAGe / NCAR
On 8/29/14 6:19 AM, Hollis, Dan wrote:
> Hi all,
>
> Here is the third in a series of que
Hi Stephan,
My understanding is that the CF point of view would be that if you don't
have a data variable, you can't have auxiliary coordinates.
In my experience, if your file only contains 2D lat and lon, it's
because you want to work with them as data variables, not because
they're coordinates
general conventions. My library already does not
> strictly enforce the CF data model (it takes a more practical bent), but
> this is the first time I would need to come up with storage conventions
> of my own.
>
> Thanks,
> Stephan
>
> [1] https://github.com/xray/xray
the currents as an output parameter. (And if it's
not, I would say that means the data portal software doesn't understand
CF very well, and needs some fixing up.)
Cheers,
--Seth
Seth McGinnis
NARCCAP Data Manager
IMAGe - CISL - NCAR
On 1/23/2015 3:56 AM, Gaffney, Sean P. wrote:
> Hi
Speaking as Joe Average User, my impression is that the only purpose of
marking changes as provisional is to highlight the differences between
the current version of the spec and the previous version. (It also
seems like provisional changes are automatically accepted whenever the
version is increm
Julien,
I would say that you don't need to do anything. Your data is already in
GPS time.
Strictly speaking, you can't specify a different time referential,
because CF says to specify the time units following the recommendations
of udunits, and udunits assumes that all times are relative to UTC.
gt;> has a
>> fixed offset to GPS time. Then we would need to introduce a new calendar of
>> utc, valid only for dates since UTC was defined. We could do it the other way
>> round, and define the default as UTC, but that would probably not be right
>> for
>> (nearl
Hi all,
I haven't chimed in for a bit because others have been saying all the
things I would have said. I think Jonathan's take is dead-on, and I
agree pretty much completely.
Are there any other real-world time systems we need to be concerned
about, or would adding a distinction between prolept
Hi all,
I would argue that time coordinates should always go somewhere in the
middle of the interval, not at either end.
Certainly, putting the time coordinate at one end of the interval is the
easy and unambiguous choice when generating data files. But in my
experience, it tends to cause confus
This seems eminently sensible to me. I particularly like the
clarification you suggest in the second point.
When edits are made to abolish the "standard" calendar, I would suggest
including a footnote about what it used to mean, to spare users of old
data the need to go hunting through old versio
fluxes, and
as Karl says, we'd likely want to use that even if we did make the
change to avoid confusion with the old names.
So it seems to me that there's no real benefit to changing flux to
flux_density, and the potential for a very large downside.
Cheers,
--Seth McGinnis
On 5/19/1
Hi all,
So what's the status of the effort to move the CF editing process to GitHub?
There's a Trac ticket (#92) that has been accepted, but that hasn't yet
been added to the v1.7 draft. I'd like to get it added to the draft
document on the CF website so that I have an easy (and official) place
Hi Dan,
Your example looks correct to me. Not that I'm an expert or anything,
but if you *are* confused, at least you're not alone. :)
Cheers,
--Seth
On 12/17/2015 4:35 AM, Hollis, Dan wrote:
> Hi all,
>
> I thought I understood coordinates until I read this post :-)
>
> I've waded throug
Hi Karl,
I think that the existing spec can't accurately represent your climatology.
The spec implicitly assumes that all the subintervals start and end at
the same point in the annual cycle, and that therefore we can represent
both the start and end of the input data and the start and end of the
Hi David,
I have argued myself back and forth into a couple different positions,
but I have two major thoughts to contribute:
1) I think using the axis attribute may help.
2) Much of the observational data that's out there already is probably
actually doing the thing that you're describing and u
o geospatial_x_resolution &
geospatial_y_resolution.)
In other words, what Jim said. He just got to the "send" button before
me. :)
Cheers,
--Seth
Seth McGinnis
Associate Scientist IV
NARCCAP Data Manager
IMAGe / CISL / NCAR
-
On 8/16/16 10:33 AM, Mary Jo Brodzik wrote:
to move to align CF more closely with external standards,
is there any way to also apply corresponding pressure on external
systems to better accommodate CF?
Yrs,
--Seth
Seth McGinnis
NA-CORDEX / NARCCAP Data Manager
Associate Scientist IV
IMAGe - CISL - NCAR
-
On 9/22/16 3:14 PM,
I have to disagree. Personally, I find the T a lot less readable than
separating them with a space.
On 9/22/16 4:04 PM, Armstrong, Edward M (398G) wrote:
> Just making the time stamp more human readable is important so I too am
> in favor of a âTâ to separate the date and time !
>
> From: CF-met
But then the data is non-compliant, and it sounds like a valid CF
solution is needed.
Two possible solutions come to my mind. The first way would be to store
the undated measurements separately. Record the normal measurements in
the normal way, and then record the undated measurements in a separ
each the person managing the list at
> cf-metadata-ow...@cgd.ucar.edu
> <mailto:cf-metadata-ow...@cgd.ucar.edu>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of CF-metadata digest..."
>
>
>
tes in the
grid_mapping that
describes your map projection. See Appendix F and examples
5.8 and 5.9.
That would implicitly define the vertical coordinate
system, wouldn't it?
(I'm just an end-user, though, not an expert -- I may well
be wrong.)
--Seth
Seth McGinnis
Associate S
accuracy and usability.
A very minor suggestion: for names that involve numbers, it seems best to use
numerals rather than spelled-out numbers. It makes certain kinds of automation
easier, and it causes an alphabetical sort to put the names in a sensible order.
Cheers,
--Seth
--
ever in that community wants
to deal with it, and no matter how many groups come to CF with new standard
names, the system can handle it. Right?
Cheers,
--Seth
Seth McGinnis
[EMAIL PROTECTED]
NARCCAP Data & User Community Manager
Associate Scientist
ISSE / NCAR
_
erature data is taken at a reference height of 2 meters, for example, you
define a scalar coordinate variable to store the value '2' and include that
variable name in the coordinates attribute. (See 5.7 for an example.)
Cheers,
Seth McGinnis
Associate Scient
et 17, which
lists allowable types as some variation on "land", "sea", and "all". (I never
did manage to figure out what the final set of names was.)
So, is there a CF-compliant way to record this land-cover information? Or is
it now outside the scope of CF?
Thank
well. I don't know a lot about the
details of this model (we're still waiting to hear from an expert), but I
figured we could get the ball rolling.
Cheers,
--Seth McGinnis
Seth McGinnis
[EMAIL PROTECTED]
NARCCAP Data Manager
Associate Scientist
ISSE / NCAR
>Dear All,
>
&
Jonathan--
I believe those would both be sensible choices. I will double-check with
people who understand the model better than I do and find out whether there's
anything objectionable about them.
--Seth
>Dear Seth
>
>> grassland
>Perhaps we could call this "grass" because I anticipate we wi
where the grid-cells are
located without needing to research and implement the relevant coordinate
transformations by hand is a big win for usability.
Cheers,
--Seth McGinnis
Associate Scientist
NARCCAP Data & User Community Manager
ISSE / NCAR
> Just a word about GIS clients, picking
Rich,
There aren't any best practices documents that I'm aware of. In theory, if
it's CF-compliant, it should be readable. It's just that ArcMap's NetCDF
capabilities are still new, so it still has some kinks. ESRI is relying on the
(small) user community to report bugs in the implementation so
you could be using some other proleptic Gregorian calendar
and still be CF, but I think it's fair to assume that ISO 8601 is what's
meant.)
Seth McGinnis
NARCCAP Data Manager
Associate Scientist
ISSE / NCAR
>Godin, Michael wrote:
> I'd like to convert some
in an attribute; the best you
can do is reference a dummy container variable and look at *its*
attributes.
(Which is an approach that works well enough for the grid mapping
problem. It may be worth formalizing / regularizing it and applying it
to any attribute sets that are grouped together and h
In the case of 'raw' output from numerical models, it probably makes sense to
use the end-point of the time interval rather than the mid-point. That's the
moment for which the model stores the data, whether they're instantaneous
values (intensive variables) or time-averages over the previous times
d have sea_water_temperature for oceans and
water_body_temperature for oceans, rivers, lakes, and other
significant accumulations of liquid water.
Cheers,
Seth McGinnis
NARCCAP Data Manager
ISSE / ISP / IMAGe / CISL / NCAR
(P.S.: Observation/tangent: It seems like this conundrum may be arisin
emble itself.
It may not be technically feasible to apply a dimension to a global attribute
per se, but I think something that aims in that general direction would have a
lot of benefits.
--Seth
Seth McGinnis
Associate Scientist
NARCCAP Data Manager
ISSE / IMAGe / NCAR
On Tue, 23 Mar 2010 16:
t it would
be more helpful to support that broader usage than to load the
definition toward error.
Cheers,
--Seth
Seth McGinnis
NARCCAP Data Manager
Associate Scientist
IMAGe / NCAR
On Wed, 7 Apr 2010 12:14:06 +0100
"Kettleborough, Jamie" wrote:
>Hello Nan,
>
>o
Glancing at my local copy of the cf-checker code, I believe it is
case-sensitive, yes.
As it ought to be: the spec lists valid values for axis as capital letters and
uses the markup that indicates an exact term.
--Seth
On Fri, 23 Jul 2010 12:55:04 -0600
John Caron wrote:
>the units appear
I believe this is correct; a 'time' has to be a numeric value.
What about using 'date' for string-valued times? That was my homebrew solution
when I was considering a similar problem.
(Note that string data is a big pain to deal with in NetCDF-3, because you're
limited to fixed-length character
s (which isn't the same thing as providing a
>>> tolerance value on the numeric coordinate value of a time axis).
>>>
>>> I'm not saying that we should definitely allow time strings in CF, just
>>> pointing out that they have some use cases we currently ca
ing, I think usability has
to trump structural purity. The value of a standard lies in its widespread
adoption. If it's not used because it can't do what people need it to do, it's
not a standard.
Cheers,
--Seth
Seth McGinnis
mcgin...@ucar.edu
imeseries must have exactly the same temporal
coverage. I don't think it's a net win.
Cheers,
--Seth
Seth McGinnis
NARCCAP Data Manager
Associate Scientist
IMAGe / NCAR
On Tue, 8 Feb 2011 23:22:16 -0800
"Ateljevich, Eli" wrote:
>Hi, I am modeling the San Fr
I'm in favor of a generalized system for automatically constructing new
standard names by applying quantifiers to established ones. In fact, when I
first encountered the Guidelines for Construction of CF Standard Names, I
thought that's what it *was*, and it took me a while to understand that you
>
>However, at the end of the day, I don't see the use -- you really can't talk
>about dates in this calendar anyway, so why not pick an arbitrary point in
>time and use hours? When if comes down to it, I can certainly see why one
>might want to do ca
Hi all,
Having encountered some subtle and insidious errors arising from
coordinate values aligned with the end of the interval, I would argue
that it's good practice to always place the time centers somewhere
near the middle of the interval. It's a better match for your default
mental model,
s adequate.
Does that seem like a fair test? (And note, there's a fourth
land-surface model that I don't have data from. I expect that
when I do get it, I'll have another list of around 20-40 land
types to reconcile with / add to the existing list. So proposed
additions wil
On Tue, 4 Oct 2011 15:28:15 +0100
Jonathan Gregory wrote:
>
>The CF convention as it stands can say a lot less, but it does look more
>self-explanatory to me! The meaning of the WKT is not clear to me. I'm quite
>uneasy about importing a convention into CF which produces opaque metadata
>like thi
>ArcGIS already reads and writes netCDF but doesn't pay any attention to
> the CF projection information as it stands.
Untrue, actually; as of v.9.3+, you can directly import CF-compliant NetCDF
as a raster using the Multidimension Tools. The map projection metadata
has to follow CF *stringentl
>I agree with your reasoning. It is worth considering the use of Groups, but
>the approach should be weighed against the best proposals that can be
>generated that stick to the classic model. Fundamentally the need is for 2
>bit of semantics:
>
> 1. associate components together so they form a co
reference.
Cheers,
--Seth
Seth McGinnis
NARCCAP Data Manager
Associate Scientist
IMAGe / NCAR
=
On Thu, 19 Apr 2012 16:13:51 +0100
"Gaffney, Sean P." wrote:
>Hi all,
>
>My name is Sean Gaffney, from the British Oceanographic Data Centre, and I'm
>working
according to the actual data contents,
>although a checker could never be sure that they are right.
>
>HTH,
>Jon
>
>
>-Original Message-
>From: cf-metadata-boun...@cgd.ucar.edu
>[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Seth McGinnis
>Sent: 19 A
I do want to see Trac messages, but since this update happened I'm getting two
or three copies of each one. Is anyone else having this problem?
What do I need to do to get only one copy?
Thanks,
--Seth
On Thu, 21 Jun 2012 16:44:40 -0700
"Jeffrey F. Painter" wrote:
>CF metadata issues get dis
I agree with this prioritization. My experience with NARCCAP suggests that any
solution that requires modelers to produce data with WKT in it is a complete
non-starter, and will be widely ignored.
Cheers,
--Seth
>so in summary, I would favour:
>
>Option 1: Long form : full parameter attribution
>> For our application in semantic mediation, the separators chosen don't
>> matter much, as long as the syntax is unambiguous, extensible, and
>> backward compatible with standard names of data.
>> The proposed syntax favors economy and a familiar CF style, as
>> advised by Jonathan. (You did spl
The datum should always be interpreted according to the calendar system
specified in the file.
That's how the time coordinate is handled in the output from every model
that I've seen (which is at least a dozen), so I'd say do it that way just for
the sake of backwards compatibility. But it's not
What are your data volumes like? I'm working at the
terabyte scale, and as long as my file sizes stay under a few dozen GB,
I don't really even bother thinking about anything that affects the file
size by less than an order of magnitude.
Cheers,
Seth McGinnis
NARCCAP / NA-CORDEX Da
> Just to be clear, however, would I be correct in saying that CF has no
> accepted way of representing the data as I've described?
>
> Thanks again,
> Jonathan
>
>> On Apr 7, 2017, at 4:43 PM, Seth McGinnis > <mailto:mcgin...@ucar.edu>> wrote:
>>
&
88 matches
Mail list logo
