Hi Jonathon,
I'm afraid I don't have much to add -- the use case is to record endpoints so that people can find out what the endpoints are. The transects are requested by specification of the endpoints. I'm requesting this for the CMIP6 metadata. What would be the use case for more detailed information?
cheers,
Martin
________________________________________
From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu] on behalf of cf-metadata-request at cgd.ucar.edu [cf-metadata-request at cgd.ucar.edu]
Sent: 29 June 2015 17:38
To: cf-metadata at cgd.ucar.edu
Subject: CF-metadata Digest, Vol 146, Issue 55
Send CF-metadata mailing list submissions to
cf-metadata at cgd.ucar.edu
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
or, via email, send a message with subject or body 'help' to
cf-metadata-request at cgd.ucar.edu
You can reach the person managing the list at
cf-metadata-owner at 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:
1. Specifying latitude and longitude of transects and regions
(Jonathan Gregory)
2. Re: How to define time coordinate in GPS? (Jim Biard)
----------------------------------------------------------------------
Message: 1
Date: Mon, 29 Jun 2015 17:37:15 +0100
From: Jonathan Gregory <j.m.gregory at reading.ac.uk>
To: cf-metadata at cgd.ucar.edu
Subject: [CF-metadata] Specifying latitude and longitude of transects
and regions
Message-ID: <20150629163715.GA7118 at met.reading.ac.uk>
Content-Type: text/plain; charset=us-ascii
Dear Martin
The reason for giving names to the transects and basins is because they are
numerically a bit imprecise - they will differ from model to model - but still
the Atlantic in one model should be regarded as comparable to the Atlantic in
another model, etc. I agree we do not have a way at present to record precisely
what it means in a given case. Since transects might be jagged lines and coasts
always are, a more general solution than endpoints would be a way to associate
a named line or outline (a geographical feature) with a list of coordinates
that trace it out, perhaps. Is there a use-case for this extra metadata? Has it
been requested in CMIP6?
Best wishes
Jonathan
----- Forwarded message from martin.juckes at stfc.ac.uk -----
> Date: Mon, 29 Jun 2015 12:31:37 +0000
> From: martin.juckes at stfc.ac.uk
> To: cf-metadata at cgd.ucar.edu
> Subject: [CF-metadata] Specifying latitude and longitude of transects and
> regions
>
> Hello All,
>
> There are some variables in the CMIP5 archive which lack explicit latitude and longitude information, such as mfo (standard name sea_water_transport_across_line) and msftzzzba (ocean_y_overturning_mass_streamfunction_due_to_bolus_advection). The first is a mass flux across a transect and the second is a zonally averaged stream function, averaged across an ocean basin.
>
> For transects, the mfo variable is encoded with an index dimension and a coordinate "passage" which labels transects by the name of the passage they cross (e.g. fram_strait). The information about precisely which part of the Fram Strait is used is in a document referred to from the MIP tables. It would be nice to have a means of encoding the end points of the transect in the CF metadata. I looked into using the "bounds" attribute, but that is defined to represent cell boundaries, so an extension to the convention is, I think, needed. It makes sense to follow the pattern used to represent cell boundaries. I propose defining a new attribute "transect" which, like the "bounds" attribute, can be attached to coordinate variables and takes the name of another variable as its value. The named variable should contain the end points of the transect.
>
> The same approach could be used for the streamfunction .. which is a mean across an east-west transect (this approach would lead to a specifcation of the east and west endpoints of each basin at each latitude -- but I'm not sure that it would be feasible to collect that much detail in the CMIP data files).
>
> Is there a cleaner way of encoding transect and basin coordinates?
>
> regards,
> Martin
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
------------------------------
Message: 2
Date: Mon, 29 Jun 2015 12:38:21 -0400
From: Jim Biard <jbiard at cicsnc.org>
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] How to define time coordinate in GPS?
Message-ID: <5591747D.2010104 at cicsnc.org>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Nan,
GPS time didn't exist, as such, before 1980-01-06 (year-month-day). It
is a continuous count from the reference date and time of 1980-01-06
00:00:00 using the Gregorian calendar and the UTC time system. UTC
started using leap seconds in 1972. Before that UTC was being adjusted
by small arbitrary amounts on much shorter time scales than the current
"a couple of times every three years or so" scale. To refer to times
prior to 1980-01-06 with the GPS time system, you would be using a
"proleptic" version, and leap seconds would still matter.
I like the idea of recording the time resolution or uncertainty. I think
this could help signal to data consumers that you took the trouble
needed with leap seconds, etc to achieve a certain level of accuracy and
precision.
Grace and peace,
Jim
On 6/29/15 11:56 AM, Nan Galbraith wrote:
> Hi Tim -
>
> I don't think there's any difference between GPS and UTC times
> before 1981-07-01, when the first leap second was accepted (if that's
> the right term), so, if your reference time is before that date, you
> can use the GPS calendar attribute, and not worry about it being used
> to muck with your reference date.
>
> I've argued that 'instrument and measurement datasets' generally have
> time values that can't be accurate enough to care about leap seconds,
> and you've expressed the opposite view. To be honest, my instrument
> clocks are mysterious, at best, and I often have to override them. Then,
> to top things off, I use Matlab to generate elapsed time for CF, and have
> no clue whether that software knows anything about leap seconds.
>
> Maybe an uncertainty attribute should be a best practice for time
> variables;
> OceanSITES recommends doing that, but I'm not sure often it's included
> - or
> noticed by data users.
>
> Cheers - Nan
>
> On 6/29/15 6:16 AM, Timothy Patterson wrote:
>> I understand that for climate or forecast data that 30+ seconds of
>> inaccuracy may not be significant, but even though the C and F in "CF
>> Conventions" stand for "Climate and Forecast", the conventions are
>> also being increasingly adopted for instrument and measurement
>> datasets. In these cases, time accuracy at small time scales becomes
>> more important, which is why seeing a proposed convention that allows
>> the time to be written ambiguously (so that there may or may not be
>> discontinuities or offsets) is rather disconcerting, like telling a
>> climate scientist that the netCDF encoding of his temperature data
>> may or may not have introduced an inaccuracy of a few Kelvin in some
>> readings.
>>
>> Under the CF1.6 conventions, I believe the base time or epoch time
>> was always expressed in UTC and the calendar attribute was applied to
>> the encoded time count. Using this convention, I could specify a UTC
>> start time and then have a simple GPS-like count of elapsed seconds
>> (with no discontinuities introduced by leap seconds). Under the
>> proposals for the 1.7 convention, this doesn't seem possible. The
>> epoch and time count must both be expressed either as UTC or as GPS
>> time and the only "mixed calendar" options introduce the above
>> mentioned ambiguity.
>>
>> Regards,
>>
>> Tim Patterson
>
>
--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
/formerly NOAA?s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
o: +1 828 271 4900
/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us
on Twitter at _at_NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
_at_NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150629/b2b6ee7f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CicsLogoTiny.png
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150629/b2b6ee7f/attachment.png>
------------------------------
Subject: Digest Footer
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
------------------------------
End of CF-metadata Digest, Vol 146, Issue 55
********************************************
Received on Mon Jun 29 2015 - 15:37:06 BST
