Jim, Good question!
Actually, there are two other categories of fundamental things in the OGC draft Best Practice doc: 1. An events regime (e.g. tree rings, ice cores, archaeological layers, king lists), where partial or full ordering can be deduced, but there is no actual ‘measure’ of time. The Allen algebraic operators can be applied (before, during, after, etc) but no subtraction or addition! 2. A TimeScale, such as TAI, where there are only ticks and an integer count from an origin/epoch (tick 0). Very physical. This is also the logical basis for relativistic time. Adding and subtracting of integers allowed. A CRS is a timescale that has been interpolated between ticks and extrapolated backwards and forwards using normal real arithmetic. In these term, I suppose that I posit the UTC as defined is TAI, converted to a CRS with one second ticks, plus a calendar (epoch displaced by quite a few seconds for solar and GPS alignment, Gregorian algorithms, IERS leap seconds) So I think we agree, with perhaps a little terminology to be refined and thrashed out. Of course, we have also defined the SI second in there somewhere. Chris From: Jim Biard [mailto:[email protected]] Sent: Thursday, May 21, 2015 2:18 PM To: Little, Chris Cc: cf-convention/CF-2; [email protected]; Piero Campalani; Matthias Müller Subject: Re: [CF-metadata] OGC Temporal Best Practice (draft). Was: [CF-2] Require PROJ.4 compatible... projection ... (#11) 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 [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]<mailto:[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]<mailto:[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<tel:%2B44%280%291392%20886278> Fax: +44(0)1392 885681<tel:%2B44%280%291392%20885681> Mobile: +44(0)7753 880514<tel:%2B44%280%297753%20880514> E-mail: [email protected]<mailto:[email protected]> http://www.metoffice.gov.uk I am normally at work Tuesday, Wednesday and Thursday each week From: David Blodgett [mailto:[email protected]<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]<mailto:[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
