Chris,
The separation into CRS, Calendar, and Notation is excellent! Are you
taking the approach that a time system such as UTC constitutes part of a
calendar? In your terms am I right in thinking that International Atomic
Time (TAI) and GPS time would be CRSs, each coupled with a no-leapsecond
calendar and the standard (yyyy-mm-dd hh:mm:ss.sss) notation? And that UTC
would be, in essence the TAI CRS coupled with the UTC leapsecond calendar
and the standard time notation?
Grace and peace,
Jim
[image: 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
o: +1 828 271 4900
*We will be updating our social media soon. Follow our current Facebook
(NOAA National Climatic Data Center
<
https://www.facebook.com/NOAANationalClimaticDataCenter> and NOAA National
Oceanographic Data Center <
https://www.facebook.com/noaa.nodc>) and Twitter
(_at_NOAANCDC <
https://twitter.com/NOAANCDC> and @NOAAOceanData
<
https://twitter.com/NOAAOceanData>) accounts for the latest information.*
On Thu, May 21, 2015 at 4:59 AM, Little, Chris <
chris.little at metoffice.gov.uk> wrote:
> I apologise about coercing this Github datum discussion into a temporal
> datum discussion, but I do not know how else to place a marker in the
> CF2/Github debate as well as the CF 1.7 arena. CL
>
>
>
> Dear CF Land,
>
>
>
> I have been avidly reading and lurking on this debate, and thought it
> would be useful to state what we have done, and intend to do, in the OGC
> Temporal Domain WG, which is three things:
>
>
>
> 1. We have written an incomplete, draft Best Practice for temporal
> aspects of geo-spatial data.
>
>
>
> 2. We have registered several temporal coordinate reference systems under
> the aegis of the OGC Naming Authority. These are resolvable via structured,
> sort of human readable, URIs.
>
>
>
> 3. We are establishing a Standards Working Group to register a couple of
> calendars in a related, but separate registry branch of URI naming
> structure. Namely, the 360 day year and the 365 day year. These are purely
> for labelling. There will be no attempt to standardise conversions, though
> this would undoubtedly be a ?good thing?.
>
>
>
> We are trying to educate the OGC community not to make the categorical
> error of assuming that CRSs, Calendars and Notations are the same thing.
> They are three different things:
>
> a. A CRS has a monotonic number line, an origin (epoch), and normal
> (real) arithmetic.
>
> b. A Calendar does not have normal arithmetic. A very simple example is
> the count of years of the current era (CE and BCE, originally AD and BC):
> no year zero, so abnormal arithmetic.
>
> c. Many Notations can be invented that are fully ordered and monotonic,
> though not necessarily regular, but makes no assumptions about durations,
> arithmetic, calendars, CRSs etc. ISO8601, IETF RFC3339 and similar contain
> examples. That they look like CRSs or Calendars is part of the problem.
>
>
>
> There are a couple of logical quirks:
>
> A. How to specify the epoch - this is a bit chicken and egg, but we all
> know the egg came first (ask me later over a beer unless you are a
> creationist).
>
> B. The 360 day year could be viewed both as a calendar AND a CRS as the
> units are all well behaved and use normal arithmetic - 1yr = 12mon = 360d =
> 360x24hr = 360x24x60x60s
>
>
>
> I wish you success in choosing your conventions and balancing backward
> compatibility and moving forward.
>
>
>
> Chris
>
>
>
> Chris Little
>
> Co-Chair, OGC Meteorology & Oceanography Domain Working Group and Temporal
> DWG
>
>
>
> IT Fellow - Operational Infrastructures
>
> Met Office FitzRoy Road Exeter Devon EX1 3PB United Kingdom
>
> Tel: +44(0)1392 886278 Fax: +44(0)1392 885681 Mobile: +44(0)7753 880514
>
> E-mail: chris.little at metoffice.gov.uk http://www.metoffice.gov.uk
>
>
>
> I am normally at work Tuesday, Wednesday and Thursday each week
>
>
>
>
>
>
>
>
>
> *From:* David Blodgett [mailto:notifications at github.com]
> *Sent:* Thursday, April 30, 2015 2:35 PM
> *To:* cf-convention/CF-2
> *Subject:* [CF-2] Require PROJ.4 compatible horizontal and vertical
> projection declarations. (#11)
>
>
>
> For any software to accurately interoperate with a geospatial dataset it
> must be given or make an assumption about the datum and projection used for
> the geospatial content. It is unacceptable to omit this information
> regardless of the scale or intended use of the data. Specification of the
> reference datum (horizontal and vertical) and projection (as applicable to
> the dimensionality of the data) should be a requirement akin to inclusion
> of units for coordinate variables. If the requirement for a dataset to
> include such metadata is considered too onerous for data producers who are
> unfamiliar with the datum their data uses, the CF community should adopt a
> default lat/lon/elevation datum and encourage software producers to
> standardize on that datum to foster consistency across the community. What
> default to use should be determined in consultation with the National
> Geodetic Survey <http://www.ngs.noaa.gov/GEOID/> and their counterparts
> internationally.
>
> Proj.4 <https://trac.osgeo.org/proj/%5D> has been the de facto
> implementation of coordinate transformations, more or less, since the
> beginning of digital geospatial data. The ability to integrate CF-described
> geospatially referenced data with tools that implement the Proj.4
> projection libraries is important.
>
> Conversion of geospatial data into CF-described files requires CF support
> for the prevailing set of projections
> <http://www.remotesensing.org/geotiff/proj_list/> and reference datums.
>
> Use of identifiers from the EPSG naming authority and conventions
> consistent with OGC-WKT should be supported. The issue that forces this
> assertion is the need for 'shift grids' to convert to/from non-parametric
> datums. This is of particular importance for vertical datums
> <https://trac.osgeo.org/proj/wiki/VerticalDatums> but is also important
> for the common NADCON <http://www.ngs.noaa.gov/cgi-bin/nadcon.prl>
> conversion to/from the NAD27 datum.
>
> In practice, codes defined by the EPSG naming authority, encoded either
> alone or as part of a WKT datum/projection declaration, are necessary for
> integration of data with web services and for conversion to and from other
> formats. Geospatial applications that desire to interoperate with CF should
> not be forced to construct utilities like this one.
> <https://github.com/USGS-CIDA/geo-data-portal/blob/master/gdp-core-processing/src/main/java/gov/usgs/cida/gdp/coreprocessing/analysis/grid/CRSUtility.java>.
> This leads to the conclusion that proj.4 strings, EPSG codes, or WKT
> projections should be allowed for specification of projections.
>
> ?
> Reply to this email directly or view it on GitHub
> <https://github.com/cf-convention/CF-2/issues/11>.
>
> _______________________________________________
> 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/20150521/115b1a50/attachment-0001.html>
Received on Thu May 21 2015 - 07:18:19 BST
