Hi Ros and Alison,
The standardised region names are held in the NERC Vocabulary server. An
RDF-XML version may be obtained using:
http://vocab.nerc.ac.uk/collection/P30/current/accepted
You can also use this to check the validity of a particular area name, For
example to verify 'antarctica' s
Dear all,
what is this thing about region_names? I only now saw this popping up and
must say that I strongly object to adopt these as a standard. Region
definitions are so manifold and depend very much on individual applications
that I don't see any value in adopting one set of names (here
It's probably overkill but for Suomi NPP CrIS and ATMS we are planning to
provide
timestamps for each obs in both TAI and UTC.
TAI is the true time dimension, but UTC gives users a correct UTC if that's
what they want and should minimize the temptation for them to do TAI to UTC
conversions usin
Martin,
I tend to agree with you. We have enough on our plates trying to deal with
standard names. The same goes with area types. I am assisting a group that
has > 200 of them. Are we really going to expand area types that broadly?
And when the next group has 100 slightly different types, what the
Dear Martin
We added the regions to CF a long time ago and they are in use, for example,
in CMIP data. As Alison says, CF section 6.1.1 describes them. One reason to
need them is that they are *not* precise. Other definitions might relate to
the real-world geography precisely, but we need region n
Hi,
Thanks a lot for all your accurate answers!
With all these information, for the moment we think the best way to represent
our time in CF is to convert the time stamp of the units attribute from GPS to
UTC.
We cannot change it for the GPS beginning 1980-01-06 so we must transform the
2000-0
Dear all
Thanks for these interesting contributions. In CF terms, it seems that UTC and
GPS time are different calendars, because of the leap seconds in UTC. A given
YMDhms date-time will sometimes be a different number of time-units since
reference-time in the two calendars. We ought to clarify t
Julien,
The units attribute cannot have "UTC" in it. UTC is implied. Other than
that, it looks great!
Jim
On 4/24/15 12:14 PM, Julien Demaria wrote:
Hi,
Thanks a lot for all your accurate answers!
With all these information, for the moment we think the best way to
represent our time in C
Jonathan,
I think the answer depends rather heavily on the way people obtained
their elapsed times that they stored in their time variables. If they
started with time stamps and the conversion to and from elapsed times
was done with software that doesn't consider leap seconds, then the
recove
Jim--
Your suggestion in the last paragraph won't work. UTC is only
meaningfully defined for the real world, so the epoch timestamp in the
units attribute can only be UTC if the calendar is Gregorian...
I'm a bit confused by the way you talk about elapsed times. It seems to
me that elapsed time
10 matches
Mail list logo
