[CF-metadata] "T" in time string?

[Chris Barker]

Folks,

I recently noticed that the CF doc uses:

seconds since 1992-10-8 15:15:42.5 -6:00

ISO8061 uses:

2014-03-16T18:22:31+00:00

i.e., a "T" separating the date and time

In practice, I've seen it with and without the "T", both in
otherwise-compliant CF files and elsewhere.

I don't know if Udunits will accept it both with and without the "T", but
the python netCDF4 lib will (and much of our own code).

It's not that big a deal to strip the "T" out, but as it crops up a lot,
maybe we should make it officially accepted.

-Chris




Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Jim Biard]

Jonathan,

Quite right.  Even longitude and latitude depend on the choice of datum, 
whether that be an ellipsoid or a geoid.

To add to the fun, you can have mixed mode coordinates, where the horizontal 
coordinates use one datum, and the vertical uses another (an extreme example is 
instantaneous water surface, where the vertical datum has no fixed relationship 
to the body of the Earth at all!)

Grace and peace,

Jim

Visit us on
FacebookJim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA's National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org
o: +1 828 271 4900




On Mar 17, 2014, at 12:39 PM, Jonathan Gregory  
wrote:

> Dear Jim
> 
> Yes, I suppose you're right, on reflection. I was thinking of a situation in
> which you were interested in the ellipsoid only for the sake of a vertical
> datum, rather than as a horizontal datum (which is its usual purpose in
> grid_mapping). However, I now understand from the discussion and explanations
> from Jon Blower why you cannot actually refer heights to a vertical datum
> without implying a particular latitude-longitude coordinate system. So the
> existing grid_mapping_name of latitude_longitude will be appropriate if you
> want to identify the geoid or ellipsoid as a vertical datum, I agree.
> 
> My understanding is now that the height is taken perpendicular to the surface,
> and the lat-lon is defined on the surface, so the lat-lon of the point whose
> height is being measured depends on the choice of surface. Please correct me
> if that's not right.
> 
> Cheers
> 
> Jonathan
> 
>> I thought this was already defined.  In the second paragraph of section 5.6, 
>> it says that if you aren?t specifying a projected coordinate system (or, I 
>> assume, a Cartesian coordinate system such as ECF), then use the name 
>> ?latitude_longitude?.  I haven?t noticed anything we?ve talked about that 
>> would invalidate this usage.  We are talking about adding vertical datum 
>> specifications and such as further attributes to the variable, but even 
>> latitude and longitude values can shift depending on the ellipsoid and/or 
>> geoid being used, so these should specified even when there is no projected 
>> coordinate system.
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Jonathan Gregory]

Dear Jim

Yes, I suppose you're right, on reflection. I was thinking of a situation in
which you were interested in the ellipsoid only for the sake of a vertical
datum, rather than as a horizontal datum (which is its usual purpose in
grid_mapping). However, I now understand from the discussion and explanations
from Jon Blower why you cannot actually refer heights to a vertical datum
without implying a particular latitude-longitude coordinate system. So the
existing grid_mapping_name of latitude_longitude will be appropriate if you
want to identify the geoid or ellipsoid as a vertical datum, I agree.

My understanding is now that the height is taken perpendicular to the surface,
and the lat-lon is defined on the surface, so the lat-lon of the point whose
height is being measured depends on the choice of surface. Please correct me
if that's not right.

Cheers

Jonathan

> I thought this was already defined.  In the second paragraph of section 5.6, 
> it says that if you aren?t specifying a projected coordinate system (or, I 
> assume, a Cartesian coordinate system such as ECF), then use the name 
> ?latitude_longitude?.  I haven?t noticed anything we?ve talked about that 
> would invalidate this usage.  We are talking about adding vertical datum 
> specifications and such as further attributes to the variable, but even 
> latitude and longitude values can shift depending on the ellipsoid and/or 
> geoid being used, so these should specified even when there is no projected 
> coordinate system.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Hedley, Mark]

I agree; I don't see a need for a 'null'

I think the currently available grid mapping types will be fit for the vertical 
datum purposes so far discussed

mark


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Jim Biard 
[jbi...@cicsnc.org]
Sent: 14 March 2014 19:12
To: CF metadata
Subject: Re: [CF-metadata] Vertical datums (again)

Jonathan,

I thought this was already defined.  In the second paragraph of section 5.6, it 
says that if you aren’t specifying a projected coordinate system (or, I assume, 
a Cartesian coordinate system such as ECF), then use the name 
“latitude_longitude”.  I haven’t noticed anything we’ve talked about that would 
invalidate this usage.  We are talking about adding vertical datum 
specifications and such as further attributes to the variable, but even 
latitude and longitude values can shift depending on the ellipsoid and/or geoid 
being used, so these should specified even when there is no projected 
coordinate system.

Is there something I’m missing?

Grace and peace,

Jim

Visit us on
FacebookJim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA's National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org
o: +1 828 271 4900





On Mar 14, 2014, at 2:21 PM, Jonathan Gregory 
mailto:j.m.greg...@reading.ac.uk>> wrote:

Dear Jim

Given what you say, what would you suggest for the grid_mapping_name when the
grid_mapping supplies only the figure of the Earth and does not specify any
transformation of coordinate systems?

I agree that grid_mapping is itself an unsatisfactory name, which reflects
the purpose we had in mind when it was first introduced, subsequently
generalised. In the data model we can (and indeed we propose to) call it
something else. We could change its name in the convention but we'd have to
retain the old one too for backward compatibility, I'd argue, and I would
feel it's not worth the effort. It's more important to describe clearly what
it does in principle.

Best wishes and thanks

Jonathan


- Forwarded message from Jim Biard 
mailto:jbi...@cicsnc.org>> -

The contents of the grid_mapping variable are doing as much mapping when 
specifying a projected coordinate system as they are when specifying a 
geographic (i.e., lon/lat) coordinate system.  It is telling you how to 
understand the spatial coordinate information, particularly in relation to any 
other choice of coordinate system.  It has an unfortunate name, in that it 
leads us to think about it as ?the thing that tells me how I got from my X & Y 
coordinate variables to my lon & lat grids?.  When you have both X/Y 
coordinates and lon/lat auxiliary coordinates, the grid_mapping variable is 
actually telling you how to understand both.  There is really no such thing as 
a ?null mapping?.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata