CRS and Axis Types

Overview Axes General structuring Horizontal axes Vertical axes Time ("temporal") axes and CRSs Index CRSs CRS Composition Parametrized definitions CRSdefinitionResolver Web Utilities

Overview

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.

Axes

General structuring

• Complete CRSs are provided under branch http://www.opengis.net/def/crs/.
• Single axes are provided under branch http://www.opengis.net/def/axis/.

Horizontal axes

These are defined mostly through the EPSG database of OGP which periodically is imported verbatim into the OGC resolver.

Vertical axes

tbd

Time ("temporal") axes and CRSs

While much more efforts have been dedicated to the definition of any sort of spatial datums, projections, transformations etc., timeis 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 gml:TemporalCRS 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 rasdamanWCS 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 or past: for instance, in domains like astronomy, geology or biology, they usually want to refer to million years agoas 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 (//gml:TemporalDatum/gml:origin).
• 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 (//gml:TimeCS/gml:axis/gml:CoordinateSystemAxis/@uom).
• a direction : the direction of the time axis: future (positive forward), or past (positive backwards) (//gml:TimeCS/gml:axis/gml:CoordinateSystemAxis/gml:axisDirection).
• a label : the label of the time axis: this is what is addressed in a WCS subset (//gml:TimeCS/gml:axis/gml:CoordinateSystemAxis/gml:axisAbbrev).

For a full list of submitted Time-CRS definitions, see our dedicated wiki page.

Related link: http://rasdaman.org/wiki/PetascopeTimeHandling.

-- PieroCampalani - 01 Jul 2014

Index CRSs

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 meetingin Geneva (June 2014).

For a preview of the definitions, see:

• Index 1D : http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/Index1D
• Index 2D : http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/Index2D
• Index 3D : http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/Index3D
• Index 4D : http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/Index4D
• Index 5D : http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/Index5D

For a full list of URIs for Index CRSs going to be submitted to OGC-NA, see this page.

-- PieroCampalani - 25 Nov 2013

CRS Composition

Existing CRSs and axes can be combined dynamically into new CRSs. The OGC crs-compound 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:

http://www.opengis.net/def/crs-compound?
           1=http://www.opengis.net/def/crs/EPSG/0/4326
       & 2=http://www.opengis.net/def/crs/OGC/0/AnsiDate

This would define a CRS by importing Lat and Long axes from EPSG:4326 and add the time axis of ansiDate, effectively yielding a 3-D CRS with Lat, Long, and ansiDate 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 definitions

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, etc.

(to be completed)

CRSdefinitionResolver Web Utilities

• WebTopicList - all topics in alphabetical order
• WebChanges - recent topic changes in this web
• WebNotify - subscribe to an e-mail alert sent when topics change
• WebRss, WebAtom - RSS and ATOM news feeds of topic changes
• WebStatistics - listing popular topics and top contributors
• WebPreferences - preferences of this web