Approach for declaring the CRS

[cportele]

This issue is based on discussions in OGC Testbed-17.

General options

1. reuse (and extend) the CRS rules in the obsolete GeoJSON spec from 2008 ("GeoJSON 2008")
2. use a fresh start that is tailored towards the specific CRS needs that are identified now by the community

Following option 1, a declaration could look like one of the two:

  "crs": {
    "type": "name",
    "properties": {
      "name": "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
    }
  }

or

  "crs": {
    "type": "link",
    "properties": {
      "href": "http://www.opengis.net/def/crs/OGC/1.3/CRS84",
      "type": "application/gml+xml"
    }
  }

Using option 1 has the obvious advantage that some libraries/clients that have already supported the now obsolete GeoJSON spec may directly support such CRS declarations.

However, there are some caveats, including:

• GeoJSON 2008 recommended the use of URNs as identifiers ("name" option), but since a number of years OGC has moved to http URIs instead of URNs, so such tools may not support the identifiers that would be used today.
• The statement of a CRS does not change the requirement to use "easting, northing, altitude for coordinates in a projected coordinate reference system, or longitude, latitude, altitude for coordinates in a geographic coordinate reference system." However, this is different from the requirements in OGC API - Features - Part 2 where the coordinates would be in the order specified in the CRS. Reusing the GeoJSON structure, but changing the rules would likely cause more confusion than help.

The GeoJSON standard states:

Note: the use of alternative coordinate reference systems was specified in [GJ2008], but it has been removed from this version of the specification because the use of different coordinate reference systems -- especially in the manner specified in [GJ2008] -- has proven to have interoperability issues.

A fresh start (option 2) could be as simple as:

  "crsId": "http://www.opengis.net/def/crs/OGC/1.3/CRS84"

This would be consistent with the use of CRS identifiers in OGC API - Features - Part 2: Coordinate Reference Systems by Reference.

Note that in a "fresh start" we should use a different key than "crs" to avoid name collisions for clients implementing the GeoJSON 2008 structure.

Context of the CRS declaration

In general, it should be possible to declare the CRS in a geometry, feature or feature collection object. A declaration would override a declaration in a parent.

At the same time, we probably should restrict the use in the first edition/part of OGC Features and Geometries JSON to declaring the CRS in the top-level object. This is the main use case and what is needed to support OGC API - Features - Part 2: Coordinate Reference Systems by Reference.

GeoJSON "prior arrangement" provision in the OGC API standards

GeoJSON states

The coordinate reference system for all GeoJSON coordinates is a geographic coordinate reference system, using the World Geodetic System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units of decimal degrees. [...] However, where all involved parties have a prior arrangement, alternative coordinate reference systems can be used without risk of data being misinterpreted.

Currently, OGC API Features leverages this provision when a client explicitly requests GeoJSON and a CRS that is not WGS 84 longitude/latitude (link). We probably should not prohibit this, but going forward we may discourage it. For example, we could recommend that GeoJSON and the media type application/geo+json are only be used with the standard coordinate reference system and feature data encoded in another CRS should use the future media type of OGC Features and Geometries JSON.

Extensions

In addition to the starting point, we should also consider extensibility, known extension needs are discussed below. We may discuss, what should be included in the first edition and what should be left for the future.

Use of a CRS description

This could in general be either WKT, PROJJSON or a potential JSON CRS encoding developed by OGC. In a JSON encoding the natural choice would be a JSON CRS encoding, supported by a new "type" (option 1) or by an object-valued JSON member like "crsObject" (option 2).

Compound CRS

While there are ways to specify an identifier for a compound CRS, the existing URIs are not easy to create or use, so an option would be the use of an array (of string identifiers or of PROJJSON objects).

Coordinate Epoch

Depending on the accuracy requirements, for data that uses a dynamic coordinate reference system like WGS84, it may be also required to specify the coordinate epoch of the geometries in addition to the CRS through an additional, numeric JSON member. The epoch is expressed as a decimal year in the Gregorian calendar, e.g., 2017-03-25 in the Gregorian calendar is epoch 2017.23.

OGC API - Features - Part 2: Coordinate Reference Systems by Reference adds a member "storageCrsCoordinateEpoch" in the Collection resources.

There is a GDAL proposal for adding a "coordinate_epoch" member at the GeoJSON FeatureCollection level.

[cportele]

Meeting 2021-06-14: The following aspects were raised in the discussion:

• We must avoid name clashes with GeoJSON keys.
• Avoid the need for oneOf constructs in JSON Schema (like in the GeoJSON geometry member).
• Mixing GeoJson geometry and more flexible OGC geometry is non-trivial, e.g. polygon in non-WGS84 CRS converted to WGS84 for backwards-compat can invert winding order if not done carefully, so it's not trivial for JSON-FG creators to get right.
• What would break GeoJSON clients? Testbed-17 can do some tests and report to the SWG.
• The intention is to follow the axis order of the CRS (also required by OGC API Features Part 2).
• Do we include support for more than one spatial property per Feature? Not discussed yet, but in general it would be possible, if we use parallel structures. But we need to keep the capabilities of the clients in mind that we want to see supporting JSON-FG.

[cportele]

CRS support is included in the draft spec. We can close this issue and discuss new issues/comments on the draft.