Support for OGC Features and Geometries JSON : Core

[navispatial]

Support for OGC Features and Geometries JSON.

The spec defines:

• include the ability to use Coordinate Reference Systems (CRSs) other than WGS84
• allow the use of non-Euclidean metrics, in particular ellipsoidal metrics
• support solids and multi-solids as geometry types
• provide guidance on how to represent feature properties, e.g., including temporal properties

First - as described in this issue - add support for core conformance / requirement class. Support for 3D and Feature Types and Schemas could be implemented later in the future.

[navispatial]

draft spec for OGC Features and Geometries JSON - Part 1: Core

[navispatial]

On standard GitHub page see also latest editor's draft.

Some copied snippets from the standard editorial draft to help analyzing needs.. Implementing these properly is NOT a trivial task for any clients or servers maybe??

Requirement / conformance classes

"Core": The Core conformance class extends GeoJSON with additional members that specify how Temporal information, extended Geometry information and Reference systems information can be encoded in a JSON-FG document. In addition, Metadata is added to declare the JSON-FG conformance classes that the JSON document conforms to. The Core conformance class has a dependency on GeoJSON. This means that a JSON-FG document that conforms to Core must also conform to GeoJSON.

"3D": The 3D conformance class adds support for Polyhedron, MultiPolyhedron, Prism, and MultiPrism geometries in a 3D CRS. The 3D conformance class has a dependency on the Core conformance class. This means that a JSON-FG document that conforms to the 3D conformance class must also conform to the Core conformance class.

"Feature Types and Schemas": The Feature Types and Schemas conformance class adds support for Feature types and Feature schemas. Features are often categorized by type. This requirements class adds members to a JSON-FG document so that contained features can be tagged with a type value. This conformance class includes guidance about how to include information about the feature schema in a JSON-FG document. The Feature Types and Schemas conformance class has a dependency on the Core conformance class. This means that a JSON-FG document that conforms to the Feature Types and Schemas conformance class must also conform to the Core conformance class.

Background - coordinate reference systems

Spatio-temporal objects are specified relative to some reference system

GeoJSON (both the current RFC and the legacy version) fixed the reference system for geometric values to the "WGS84 datum, and with [an axis order of] longitude and latitude [and coordinate] units of decimal degrees". The legacy version included a "prior arrangement" provision to allow other reference systems to be used and to also defined the "crs" key for specifying the reference system. This prior arrangement mechanism survived into the RFC but the accompanying "crs" key did not. The result is that there is no interoperable way to unambiguously specify a different CRS in GeoJSON. As such, the only safe approach is to continue using OGC:CRS84(h) for GeoJSON and ignore the prior arrangement provision and the old "crs" key.

Additional JSON-FG building blocks like the "place" member are not bound by these restrictions and so this Standard provides for handling reference systems in JSON-FG documents in a way that does not interfere with anything, past or present, defined in any of the GeoJSON specifications. The GeoJSON building blocks can continue to operate as always but JSON-FG building blocks provides enhanced CRS support.

Requirements for coordinate reference systems

• Core specifies how reference systems information can be encoded in a JSON-FG document.
• More information about coordinate reference systems and common problems when dealing with coordinates may be found in the W3C/OGC Spatial Data on the Web Best Practice in the section 'Coordinate Reference Systems (CRS)'
• Without any other information, the following coordinate reference system (CRS) defaults apply in a JSON-FG document:
  • Spatial CRS: WGS 84 with axis order longitude, latitude and optional ellipsoidal height, either OGC:CRS84 (2D) or OGC:CRS84h (3D) as registered with the OGC;
  • Temporal CRS: DateTime in Gregorian calendar, OGC:GregorianDateTime.
• In this JSON-FG Standard, a new key "coordRefSys" is defined and can be used to assert the CRS of a JSON-FG geometry object at the collection, feature, or value levels.
• The "coordRefSys" key does not apply to the GeoJSON geometry member. This key only applies to geometry objects in the "place" member and those that may appear in the "properties" member.
• If a CRS is asserted for a JSON-FG document, that assertion will typically be made at the top level of the document, either at the collection level or the feature level depending on the contents of the document.

A reference system can be specified in a JSON-FG document using a "coordRefSys" member...:

• URI: "http://www.opengis.net/def/crs/EPSG/0/3857"
• Safe CURIE: "[EPSG:3857]"
• A reference system value by reference (URI) and with an epoch:

  {
  "type": "Reference",
  "href": "http://www.opengis.net/def/crs/EPSG/0/4979",
  "epoch": 2017.23
  }

• A ad hoc compound reference system value (using URIs):

  [
  {
  "type": "Reference",
  "href": "http://www.opengis.net/def/crs/EPSG/0/4258",
  "epoch": 2016.47
  },
  "http://www.opengis.net/def/crs/EPSG/0/7837"
  ]

Scoping rules

• Used at the feature collection level, the "coordRefSys" key asserts the CRS for JSON-FG geometry objects found anywhere in the document that are not otherwise tagged with CRS information in the feature or geometry object.
• Used at the feature level, the "coordRefSys" key asserts the CRS for JSON-FG geometry objects found anywhere in the feature that are not otherwise tagged with CRS information in the geometry object.
• Used at the geometry level, the "coordRefSys" key asserts the CRS for the JSON-FG geometry object within which the key is contained. For a GeometryCollection, all geometries in the collection must be in the same CRS (this constraint is "inherited" from the OGC Simple Feature Access Standard) and cannot include a "coordRefSys" member.
• Where all objects on the same level are in the same CRS, declaring the CRS on the parent level instead of declaring it in all parallel objects is recommended.

The order in which coordinates for JSON-FG geometry objects are expressed is defined in the OGC Axis Order Policy and shall be in the axis order defined by the closest-to-scope CRS metadata.

For unknown coordinate reference systems, such as with CAD engineering drawings, the following CRS identifiers can be used:

• OGC:Engineering2D for 2D coordinates (x, y);
• OGC:Engineering3D for 3D coordinates (x, y, z).

The CRS of a "place" geometry object is determined as follows:

• If the geometry object has a member "coordRefSys", the CRS is identified by the value.
  • Otherwise inspect the parent object and repeat until the root object.
• If no "coordRefSys" member has been found, the CRS has WGS84 longitude/latitude as the first two coordinate axes (that is, the requirement above is not met).
• Otherwise inspect the CRS URI, CRS CURIE or CRS object to determine the datum and the first two coordinate axes.

If the "place" member in any JSON-FG feature in the JSON document is not null and the geometry type (member "type") is "GeometryCollection" or any other geometry type that has embedded geometry objects, no embedded geometry object SHALL include a "coordRefSys" member.