Dear all,
interesting discussion. From the point of view of an outsider (not dealing
with ocean data ;-) there are two issues which still aren't entirely clear to
me:
1) as Steve Hankin wrote, this variable has a potential to deflect from the
actual physical quantity, which is expressed
Dear all,
after reading through the unusally vivid discussion on this issue, I
feel like I have to make a statement as well. My background being the
experience with not-so-CF-compliant CF-netCDF datasets submitted to us
by several different groups and the resulting development of a CFchecker
to
Folks:
Last year we (GOES-R Ground System) proposed a change that would allow
coordinate variables to use scale_factor and add_offset (see trac item #86
with title Allow coordinate variables to be scaled integers).
We will be producing one type of product on a lat/lon grid and would like to
Hi all:
Another thing to consider is the relationship to the current udunit/CF
standard for specifying dates in the unit string
period SINCE date
The udunits documentation
http://www.unidata.ucar.edu/software/udunits/udunits-2/udunits2lib.html#Grammar
not being very clear, I wrote up my
Hi.
I'm opposed to the addition of a standard name. Standard names are
intended to identify classes, or types of things. As I look at it, the
goal is to keep implementation details out of standard names. ISO8601 is
an implementation, so I think it has no place in the standard name
vocabulary.
Hello,
My beer/coffee/perocet levels are too low to want to comment broadly on
this, so I'll just make one comment ...
Really the main advantage is that data writers are less likely to
make a mistake specifying
1952-08-15T00:00:00Z
than
2434567 days since -4713-01-01T00:00:00Z.
I'm
On 3/20/2013 9:41 AM, David Hassell wrote:
Hello,
My beer/coffee/perocet levels are too low to want to comment broadly on
this, so I'll just make one comment ...
Really the main advantage is that data writers are less likely to
make a mistake specifying
1952-08-15T00:00:00Z
than
2434567
On 03/20/2013 04:51 PM, John Caron wrote:
I guess the point is that its not always fair to assume that, and the
user wont know when it fails, esp for
'2434567 days since -4713-01-01T00:00:00Z'
unless she also computes
'1952-08-15T00:00:00Z'
which presumably she could do as a double
Correction, I said this yesterday:
If leap seconds are excluded, then the correct [value of
the CF calendar attribute] should be proleptic_gregorian.
In the most common cases where the data is fully within the range of
the Gregorian calendar, the calendar attribute should be simply
gregorian.
I was wondering if it is possible to describe the pixel geometry of
satellite measurements in CF. In atmospheric trace gas remote sensing,
an individual measurement's location is often described by the center
point's lat/lon coordinates plus the four pixel corner points' lat/lon
coordinates. One
On 3/20/2013 7:58 AM, John Caron wrote:
Hi all:
I guess I started this messy discussion, then invited everyone to
drink too much and say whatever they wanted. The conversation gets a
bit loud and fuzzy. So now we've switched back to caffeine and the
sober realities of deciding on grammars
Hello Steve,
On Tue, Mar 19, 2013 at 6:19 PM, Steve Hankin steven.c.han...@noaa.gov wrote:
A question to debate in your trac ticket. Per the CF documentation, the
definition of the standard_name is The name used to identify the physical
quantity
Hello Andreas,
On Wed, Mar 20, 2013 at 5:50 PM, Andreas Hilboll li...@hilboll.de wrote:
I was wondering if it is possible to describe the pixel geometry of
satellite measurements in CF. In atmospheric trace gas remote sensing,
an individual measurement's location is often described by the
13 matches
Mail list logo
