CRS and Axis Types
The OGC resolver offers definitions of spatio-temporal, as well as non-referenced Coordinate Reference Systems (CRSs). These include single axes as well as axis combinations for multi-dimensional CRSs. On this page, we briefly discuss the different types as well as dynamic composition of axes and CRSs into new CRSs.
These are defined mostly through the EPSG database of OGP which periodically is imported verbatim into the OGC resolver.
Time ("temporal") axes and CRSs
While much more efforts have been dedicated to the definition of any sort of spatial datums, projections, transformations etc., time
is equally important in the analysis of geospatial features but still there is now conventional way to handle time within the OGC standards.
The newly born Temporal DWG
working group is coping with the definitions of temporal geometries, nomenclature, semantics, and the like: you can subscribe to the mailing-list
to follow the group proceedings.
Part of these efforts resulted in the definition of a first set of Time CRSs.
Using the existing
elements, these definitions can be exploited by coverage web services to create space-time CRSs compositions, and hence augment the subsetting domain to have one (or more) temporal dimensions.
Leaving the handling of time calendar complexities to time libraries, this approach lets you index time information on a linear axis, in a publicly resolvable way (via HTTP URLs and SECORE): as performed by the rasdaman
WCS service, subsettings along the time CRS dimension need not be time direct positions (encoded via a Time CRS), but they can be more convenient ISO:8601 time strings, if enclosed in double-quotes.
What is a time CRS?
It simply defines a linear counting of a time-step from and origin time position: for instance, UNIX time is the linear counting of seconds from 1970-01-01T00:00:00 UTC.
The CRS dimension is strictly 1D, but you can always add more than one CRS to a compound spatio-temporal domain (like the MetOcean
5D grids use-case). The directions of the time axis can be either future
: for instance, in domains like astronomy, geology or biology, they usually want to refer to million years ago
as time information.
The GML definition of a Time CRS then specifies:
- an epoch : the origin time of the CRS (the datum). This is specified as an xsd:dateTime element (
- a time step : the unit of measure of the CRS. This shall be a URI identifier too, the code being a proper UCUM standard abbreviation (
- a direction : the direction of the time axis: future (positive forward), or past (positive backwards) (
- a label : the label of the time axis: this is what is addressed in a WCS subset (
For a full list of submitted Time-CRS definitions, see our dedicated wiki page
Related link: http://rasdaman.org/wiki/PetascopeTimeHandling
- 01 Jul 2014
Data need not necessarily be referenced in space (or time). In order to achieve uniform treatment, however, CRSs have been defined which allow implementations to handle such situations no different from referenced ones. Earlier this has been called an "Image CRS", but later this 2-D concept has been generalized to "Index CRSs" which define integer index coordinates in various dimensions (currently: from 1-D through 5-D).
Corresponding OGC resources identifiers for non-spatial CRSs have been submitted and accepted by OGC.
The associated Name-Type Specification (NTS) document
has been accepted by OGC at the TC meeting
in Geneva (June 2014).
For a preview of the definitions, see:
For a full list of URIs for Index CRSs going to be submitted to OGC-NA, see this page
- 25 Nov 2013
Existing CRSs and axes can be combined dynamically into new CRSs.
branch accomplishes such a combination, all based on URLs.
For example, a CRS for a satellite image timeseries datacube having 3 dimensions, horizontal Latitude and Longitude as well as time, can be described by composing 2-D WGS84 - offering Lat and Long - with a time ("temporal") CRS as follows:
This would define a CRS by importing
axes from EPSG:4326 and add the time axis of
, effectively yielding a 3-D CRS with
in proper order which can be retrieved as a single CRS from the resolver
Compound CRS handling follows the OGC CRS Name Type Specification
(OGC 11-135): "This OGC Best Practice document defines a syntax, based on http URIs, for identifying Coordinate Reference Systems (CRSs), including compound and parameterized CRSs. Strings conforming to this syntax are called CRS URIs. The semantics of such definitions is established by the OGC registry service. The specification on hand does not define concrete URIs, it only establishes an URI scheme; definition of CRS URIs based on this scheme, such as temporal CRSs, is done separately within OGC."
Parametrized CRS types offer the chance to keep a simple and clean code
, while letting a customization of the CRS definition via KV-pairs (e.g. the datum to be in the centre of nD cell by default, but with a parametrizable offset). This can avoid overly long codes like what happened for previous identifiers for Image CRSs: http://www.opengis.net/def/crs/OGC/1.0/ImageCRSpixelCorner
(to be completed)
CRSdefinitionResolver Web Utilities