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
