Coordinate Reference Systems

Introduction

This page is for collecting information on the topic Coordinate Reference Systems (CRSs). The collected information can be used for both the Use Cases and Requirements deliverable (UCR) and the Best Practices deliverable (BP).

The need for CRS data

Geometry is described by numbers. A CRS tells us how the numbers should be interpreted. Without a known CRS, coordinates in the descriptions of geometry have little meaning, just like saying that something has a speed of 103: the frame of reference needs to be known in order to do something useful with the numbers.

For geographic coordinates many well known CRSs exist that can be applied to the whole or parts of Earth. In the SDWWG we do not deal with geographic data only, so we also need to have a way of handling specification of CRSs for non-geographic spatial data.

CRS related requirements

The UCR has several CRS-related requirements:

1. CRS definition
2. Default CRS (still being discussed in ISSUE-28)
3. Independance on reference systems
4. 4D model of space-time
5. Non-geographic reference system
6. Spatial metadata
7. Time dependencies in CRS definitions

CRS related issues

The following unresolved issues are in the tracker:

1. ISSUE-28: phrasing of the Default CRS requirement
2. ISSUE-29: possible new requirement for linking a geometry to a CRS

One CRS to rule them all?

There are many CRSs for geographic data. Would it be possible to have a useful default CRS?

WGS84

WGS84, a CRS for latitude-longitude coordinates, is very popular on the web. This has lead to the idea that this CRS can be considered a default CRS. In fact, many specifications have done so (basic geo, GeoJSON, geosparql).

One might ask how many data providers have consciously selected WGS84 as the most appropriate CRS for their data. In some cases using WGS84 explicitly or implicitly is just the easiest way because it is the favoured CRS in many specifications. Could it be that actually what data providers want to express is “this is a longitude and latitude in a spherical CRS in which the Greenwich meridian is the prime meridian”?

There are good reasons why WGS84 is not a good candidate for a worldwide default CRS. It mostly has to do with plate tectonics. WGS84 is fixed to the North American plate, which means that while WGS84 serves well for locations on that plate, locations on other plates that move with respect to the North American plates suffer displacement that gradually increases with time. For example, North America and Europe move apart at a rate of about 2.5 cm/year.

The displacement that has occurred since the location was measured can be calculated, but in order to do that the time of measurement needs to be known, which is not always the case. If determination of location is more or less recent and spatial accuracy is not that important, WGS84 could be used to describe locations outside of North America but there are reasons not to recommended it as a good practice:

• It is likely that accuracy of measurements of location will increase because of technologcial advancements, making displacement of centimeters per year relatively more important.
• Unfortunately in many cases the uncertainty of coordinates is not communicated well (e.g. by means of significant digits), so it is not easy to determine which amount of error is acceptable.
• It is good practice to publish data at the highest quality and to not make assumptions on how data will be used.
• Error that is increasing with time does not go well with trying to provide lasting data.

Because WGS84 is unsuitable in Europe, European guidelines (like INSPIRE) recommend using ETRS89. Also, GNSSs other than GPS do not use WGS84.

New CRS based on a dynamic datum

In this e-mail thread the idea of dynamic datums was discussed. In the future, these could help in moving the temporal aspects of location measurements from the location data to the CRS definition. Could a global datum that takes changes in the earth's surface into account be a candidate for the foundation of a default CRS?

Collected practices

This chapter is for collecting current practices for handling CRS data, and for collecting thoughts and observations on those practices.

EPSG database

The EPSG registry (http://www.epsg-registry.org/) is the traditional source of CRS definitions in GIS, most GIS systems use EPSG codes (e.g. EPSG::4258) to refer to CRS definitions. The fact that geodetic CRSs (CRSs that use degrees longitude and latitude) use the traditional coordinate order latitude-longitude (y,x instead of x,y) in the EPSG definitions has been a continuous source of confusion in GIS.

GeoSPARQL

In the WKT representation of geometry, GeoSPARQL uses the concept of a default CRS: “The URI <http://www.opengis.net/def/crs/OGC/1.3/CRS84> shall be assumed as the spatial reference system for geo:wktLiterals that do not specify an explicit spatial reference system URI.”

The URI http://www.opengis.net/def/crs/OGC/1.3/CRS84 denotes WGS84 with the order longitude, latitude.

An example of a geometry expression that uses another CRS:

 "<http://www.opengis.net/def/crs/EPSG/0/4326> Point(33.95 -83.38)"^^<http://www.opengis.net/ont/geosparql#wktLiteral>

A notable feature is that the CRS URI is concatenated with the WKT string in the literal. This design is debatable (see the discussion in this thread in the locadd group). Some arguments against:

• The CRS is a URI, so it should be published as one.
• Software libraries that handle WKT geometry do not expect a CRS as start of the string.
• It is not possible to assign a CRS to a collection of geometries (e.g. a dataset).

arguments for:

• Without the CRS the coordinates do not make sense, so the two should be inseparable

GeoJSON

GeoJSON uses the same default as GeoSPARQL: if no CRS is specified, coordinates are assumed to be WGS84 with reversed axes. GeoJSON has a general rule that for geodetic CRSs the coordinates always have the order longitude, latitude. CRSs can be identified by a string value (so it is not possible to use designate a CRS reference as a URI). The axis order rule implies that EPSG codes for geodetic CRSs like 4326 (WGS84) or 4258 (ETTRS89) can not be used to identify a CRS.

OGC CRS registry

The OGC maintains a registery of CRS URIs at http://www.opengis.net/def/crs. Within that space, EPSG CRS definitions like http://www.opengis.net/def/crs/EPSG/0/4258 can be looked up an dereferenced to GML descriptions of the CRS. The OGC also serves its own CRSs (like http://www.opengis.net/def/crs/OGC/1.3/CRS84) which can not be dereferenced.

IGN France CRS registry

IGN France has a CRS registry in which CRS URIs can be dereferenced to RDF desccriptions. See http://data.ign.fr/def/ignf

Possible solutions

This chapter is for describing possible solutions for CRS related issues.

Layered semantics

One possible way out of CRS related problems is to introduce layered (modular) semantics for defining CRSs. Such a semantic framework could make use of the principles of specialization/generalisation to define:

• numerical reference systems in general.
• temporal and spatial reference systems.
• one-dimensional, two-dimensional and three-dimensional spatial reference systems.
• spherical coordinate reference systems and rectangular reference systems.
• planetary reference systems.
• earth based reference systems.

Having such a model in place would allow the following:

1. Have dereferencable URI references for all CRS classes and instances.
2. Pick the most applicable generalisation level (e.g. general latitude/longitude versus latitude/longitude in ETRS89).
3. Use the same foundations for coordinates on Earth or other planets.
4. Use the same foundations for geographic coordinates and non-geographic coordinates (e.g. coordinates on the floor plan of a building).
5. Embed newly conceived coordinate reference systems in an existing framework.
6. Make CRS definitions from different authorities interoperable.
7. Have more possibilities for CRS-based logic/inference.
8. Formalize historical CRSs that aren't used any longer but can be found in historical sources.
9. Have a common framework for allowing coordinate transformations between different CRSs.
10. Enable associating CRSs (e.g. specify the origin of a local CRS in a global CRS).

3D web clients

One problematic aspect of geographic coordinates is that they are often projected onto a flat (2D) plane. That is a necessity for displaying a map on paper, but it is not for displaying data in a web browser. Geographical data can be drawn upon a spherical surface representing earth (an example). This does not solve problems resulting from plate tectonics, but it does solve problems relating to projections of 3D longitude-latidude on to a flat plane (as illustrated by the US government advising against using the popular web mercator projection for any serious applications).