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 <mcgin...@ucar.edu
>> <mailto:mcgin...@ucar.edu>> wrote:
>>
>> Hi Jon
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 Data Manager
RISC - IM
ng 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..."
>
>
> Today's Topics
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
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:
gn 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, Bob Simons - NO
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:
>
> I a
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
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
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
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/15 3:23 PM, Jonathan Gregory wrote:
Dear all
Like Karl, I
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
message from Seth McGinnis mcgin...@ucar.edu -
Date: Thu, 23 Apr 2015 13:06:21 -0600
From: Seth McGinnis mcgin...@ucar.edu
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] How to define time coordinate in GPS?
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0)
Gecko
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
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
. (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 everyone,
Sean Gaffney from the British
), 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
On Mon, Oct 13, 2014 at 10:52 AM, Seth McGinnis mcgin...@ucar.edu
mailto:mcgin...@ucar.edu wrote:
Hi Stephan,
My understanding
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
,
--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 questions relating to our work on
converting gridded UK observations data to NetCDF…
As many of you will know
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 deal with the issue in whatever way you find
most convenient.
Cheers,
--Seth
Seth McGinnis
mcgin...@ucar.edu
since my first time interval (for the first cell) is specified to be
Jan 1 00:00:00 to Jan 2 00:00:00, which is applied within each
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
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
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 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 UV
Appleton Laboratory R25,
2.22 Harwell Oxford, Didcot, OX11 0QX, U.K.
-Original Message- From: CF-metadata
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Seth
McGinnis Sent: 01 July 2013 23:49 To: Jonathan Gregory;
cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] new standard
17:25:21 -0600
John Caron ca...@unidata.ucar.edu 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 service to
affect the data it operates on in very targeted
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 Graybeal john.grayb...@marinexplore.com wrote
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
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 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
to the moisture content of the air parcel (e.g. the
virtual temperature). Using temperature difference as opposed to a specific
temperature, e.g. the virtual temperature, would help to generalize the
definition.
Sincerely,
Jonathan Wrotny
On 5/24/2013 7:57 PM, Seth McGinnis wrote:
Greetings CF
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
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,
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
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
of the total totals index that I recently
submitted and includes the coordinate variables in two other stability indices
that I will post this week.
How does this look now?
Thanks again.
-Jonathan
On 5/24/2013 7:17 PM, Seth McGinnis wrote:
Hi Jonathan,
I would like to suggest a small modification
standard names.
Sincerely,
Jonathan
On 5/29/2013 2:11 PM, Seth McGinnis wrote:
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
.
---
-Original Message-
From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Seth
McGinnis
Sent: Friday, May 24, 2013 4:58 PM
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] new standard names for CIN, LFC,LCL; update to CAPE
Greetings CF mailing list!
I would like
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
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 that's
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
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
On Thu, 28 Mar 2013 09:22:57 -0400
Aleksandar Jelenak - NOAA Affiliate aleksandar.jele...@noaa.gov wrote:
On Fri, Mar 22, 2013 at 4:31 PM, Seth McGinnis mcgin...@ucar.edu wrote:
Maybe I'll change my mind after the community has made the jump to
netcdf4
Dear Seth,
What benchmark do you suggest
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
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
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) Set
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 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
,
--Seth
Seth McGinnis
NARCCAP Data Manager
Associate Scientist
IMAGe / NCAR
=
On Thu, 19 Apr 2012 16:13:51 +0100
Gaffney, Sean P. s...@bodc.ac.uk wrote:
Hi all,
My name is Sean Gaffney, from the British Oceanographic Data Centre, and I'm
working on a project dealing with numerical model
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 April 2012 21:05
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] code that does
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
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
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
to it, I can certainly see why one
might want to do calculations and plotting, etc, in those calendars, but I
don't see why your netcdf file has to store the data that way.
-
Seth McGinnis
NARCCAP Data Manager
Associate Scientist
IMAGe / NCAR
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 e...@water.ca.gov wrote:
Hi, I am modeling the San Francisco Bay-Delta an estuary with several
tributaries
-
From: cf-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Ben Hetland
Sent: 20 October 2010 09:14
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data
On 19.10.2010 16:27, Seth McGinnis wrote:
What about using
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 code markup that indicates an exact term.
--Seth
On Fri, 23 Jul 2010 12:55:04 -0600
John Caron
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:12:13
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 arising in
part because the day-to-day meaning of the term
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
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 files from Matlab to NetCDF formats with as little
modification
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 up on one of Steve's
comments
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
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 will
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 Scientist
NARCCAP Data Manager
ISSE / NCAR
handle it. Right?
Cheers,
--Seth
Seth McGinnis
[EMAIL PROTECTED]
NARCCAP Data User Community Manager
Associate Scientist
ISSE / NCAR
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
66 matches
Mail list logo
