Hi Martin,
I guess the question is why the longitude and latitude of end points
would be of interest to anyone. I guess you could make a case for
seeing whether a modeler had computed the transect for some region that
doesn't correspond to the strait (or comparable feature) of interest,
but I don't think that's compelling. Are there other reasons to know
exact coordinates when we know the models are only approximately
representing the ocean basins and their behavior.
cheers,
Karl
On 6/29/15 2:37 PM, martin.juckes at stfc.ac.uk wrote:
> 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
> ********************************************
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150629/416e1cf4/attachment.html>
Received on Mon Jun 29 2015 - 16:05:11 BST
