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: [email protected] 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 (@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 < [email protected]> 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: [email protected] http://www.metoffice.gov.uk > > > > I am normally at work Tuesday, Wednesday and Thursday each week > > > > > > > > > > *From:* David Blodgett [mailto:[email protected]] > *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 > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > >
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
