Many features have a geometry property that provides information about the primary spatial characteristics of the feature. In GeoJSON, this information is encoded in the "geometry" member. Features often have temporal information, too. In most cases, time is either an instant (e.g., an event) or an interval (e.g., an activity or a temporal validity). In the OGC API Features Standard the temporal property is reflected in the parameter "datetime" for temporal filtering of features that is supported by all compliant Feature API instances.

JSON-FG adds support for the most common case: Associating a feature with a single temporal instant or interval in the Gregorian calendar.

More complex cases and other temporal coordinate reference systems are out-of-scope for this Standard and might be specified in extensions.

Features can have temporal properties. These properties will typically be included in the "properties" member.

As GeoJSON does, JSON-FG does not place constraints on the information in the "properties" member. JSON-FG specifies a new JSON member in a feature (key: "time"). The member describes temporal information (an instant or an interval) that can be used by clients without a need to inspect the "properties" member or to understand the schema of the feature. Clients that are familiar with a dataset can, of course, inspect the information in the "properties" member instead of inspecting the "time" member.

The publisher of the data needs to decide which temporal feature properties are used in the "time" member.

The "time" member is either missing or null (no temporal information) or an object with at least one member.

Providing multiple members is valid, if all values intersect. In this case, clients should use the "interval" property and may use the "date" or "timestamp" property to determine the temporal characteristics of the feature.

The "time" object may be extended with additional members. Clients processing a "time" object must be prepared to parse additional members. Clients should ignore members that they do not understand. For example, in cases where the "time" member neither includes a "date," "timestamp," or "interval," a client may process the feature as a feature without temporal information.

An instant is a value that conforms to RFC 3339 (Date and Time on the Internet: Timestamps) and is consistent with one of the following production rules of the ISO 8601 profile specified in the RFC:

Conceptually, an instant is a "temporal entity with zero extent or duration" [Time Ontology in OWL]. In practice, the temporal position of an instant is described using data types where each value has some duration or granularity. The value should be described with a granularity that is sufficient for the intended use of the data.

In the case of a timestamp the granularity is a second or smaller. All timestamps must be in the time zone UTC ("Z").

In the case of a date the granularity is a day. Dates as instants will be used when a granularity of a day independent of its timezone is sufficient for the intended use of the data. If that is not the case and the timezone is important for the intended use, the temporal information should be provided as an interval with start and end timestamps.

Dates and timestamps are the initial range of instant values. The range may be extended in the future to support additional use cases. Clients processing values of time must be prepared to receive other values. Clients should ignore values that they do not understand.

An interval is described by start and end instants. Both start and end instants are included in the interval, i.e., the interval is closed.

The unbounded end of an interval is represented by a double-dot string ("..") for the start/end. This follows the convention of ISO 8601-2 for an open start or end.

The options described above are the initial range of interval values - the granularity is either days or (sub-)seconds and interval ends may be unbounded. The value range may be extended in the future to support additional use cases. Clients processing values of time must be prepared to receive other values. Clients should ignore values that they do not understand.

Features typically have a geometry that provides information about the primary spatial characteristics of the feature.

In GeoJSON, geometry information is encoded in the "geometry" member. Geometries are encoded according to the OGC Simple Features Standard (2D or 2.5D points, line strings, polygons or aggregations of them) using a WGS 84 CRS (OGC:CRS84 for 2D or OGC:CRS84h for 2.5D).

A key motivation for the development of the JSON-FG Standard is to support additional requirements, especially the ability to represent geometries in other CRSs and in additional geometry types.

To avoid confusing existing GeoJSON readers, such geometries are provided in a new member in the feature with the key "place."

The primary geometry of a feature is provided in the "geometry" and/or "place" members of the feature as specified in the next sub-clause. The value of both members is an object representing a geometry - or null. The "place" member can also be omitted, if the member has no value.

The valid values of the "geometry" member are specified in the GeoJSON standard.

The value range of the "place" member is an extended and extensible version of the value range of the GeoJSON "geometry" member:

Only the capability to declare the coordinate reference system is considered a Core capability. The other capabilities are added by additional building blocks described in subsequent sections.

Future parts of Features and Geometries JSON or community extensions may specify additional members or additional geometry types. JSON-FG readers should be prepared to parse values of "place" that go beyond the schema that is implemented by the reader. Unknown members should be ignored and geometries that use an unknown geometry type should be mapped to null.

All coordinates in a "place" member are in the same coordinate reference system. This includes GeometryCollection geometries, where all geometries must be in the same coordinate reference system.

If the geometry is a valid GeoJSON geometry (that is, one of the GeoJSON geometry types, in WGS 84), the geometry is encoded as the value of the "geometry" member. The "place" member then has the value null or is omitted.

If the geometry cannot be represented as a valid GeoJSON geometry, the geometry is encoded as the value of the "place" member.

In addition, a valid GeoJSON geometry may be provided as the value of the "geometry" member in the WGS 84 CRS as specified in the GeoJSON standard. Otherwise, the "geometry" member is set to null. If present, the geometry that is the value of the "geometry" member is a fallback for readers that support GeoJSON, but not JSON-FG. This fallback geometry could be a simplified version of the value of the "place" member - like the building footprint in the example "building with a polyhedron geometry and the polygon footprint" which is the polygon projection of the solid geometry. The fallback geometry can also be the same point/line string/polygon geometry that is the value of the "place" member, but in a WGS 84 CRS (potentially with fewer vertices to reduce the file size). It is the decision of the publisher, how the fallback geometry in a WGS 84 CRS is derived from the geometry that is the value of the "place" member. In the example, this is the footprint of the building, but it also could be a representative point (to reduce the data volume) or a 3D MultiPolygon representing the outer shell of the polyhedron (for clients that support visualizations in 3D).

The presence of such fallback geometries in JSON-FG features is indicated by a link from the JSON document to the "http://www.opengis.net/def/profile/OGC/0/jsonfg-plus" profile (see Requirements Class "GeoJSON Profiles").

Without any other information, the following coordinate reference system (CRS) defaults apply to JSON-FG objects:

In the JSON-FG Standard, a new key "coordRefSys" is defined and can be used to assert the CRS of a JSON-FG geometry at the feature collection, feature, or geometry levels.

The "coordRefSys" key does not apply to the GeoJSON "geometry" member. This key only applies to geometries in the "place" member and those that may appear in the "properties" member.

If a CRS is asserted for a JSON-FG object, that assertion will typically be made at the root level of JSON-FG objects, either at the feature collection level or the feature level depending on the contents.

Spatio-temporal objects are specified relative to some reference system.

GeoJSON (both the most recent RFC 7946 and the obsolete version) fixed the CRS for geometries to the "WGS84 datum, and with [an axis order of] longitude and latitude [and coordinate] units of decimal degrees". The obsolete version supported other CRSs through defining the key "crs" for specifying the CRS. In RFC 7946 the "crs" member was removed, but a prior arrangement provision was added that if all parties agree, coordinates could be represented in a different reference system. 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.

It is also important to note that the "crs" member applied to the geometry in the "geometry" member, while the "coordRefSys" member from JSON-FG does not apply to the geometry in the "geometry" member.

Additional JSON-FG building blocks like the "place" member are not bound by the restrictions in GeoJSON and so the JSON-FG Standard provides for handling CRSs in JSON-FG objects 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 provide enhanced CRS support.

A reference system can be specified in a JSON-FG object using a "coordRefSys" member in one of three ways:

Used at the feature collection level, the "coordRefSys" key asserts the CRS for JSON-FG geometries found anywhere in the feature collection that are not otherwise tagged with CRS information in the feature or geometry.

Used at the feature level, the "coordRefSys" key asserts the CRS for JSON-FG geometries found anywhere in the feature that are not otherwise tagged with CRS information in the geometry.

Used at the geometry level, the "coordRefSys" key asserts the CRS for the JSON-FG geometry 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 geometries 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:

Features are often categorized by type. Typically, all features of the same type have the same schema and the same properties.

Many GIS clients depend on knowledge about the feature type when processing feature data. For example, when associating a style with a feature in order to render that feature on a map display.

GeoJSON is schema-less in the sense that it has no concept of feature types or feature schemas.

In JSON-FG, a feature is an instance of a single feature type. If a feature is associated with multiple feature types, the primary type should be declared.

The related section Feature schemas: the "featureSchema" member specifies the schema for each feature type, if such information is available.

The feature type of a feature is declared in a member of the feature with the key "featureType". The value is a string, which should be a code, convenient for the use in filter expressions.

Data specifications often specify codes for feature types. Where data is based on such a data specification, those code will in general be used. An example is the DIGEST 2.1 Feature and Attribute Coding Catalogue (FACC) Data Dictionary of the Defence Geospatial Information Working Group (DGIWG).

Some clients will process feature collections differently depending on whether the collection is homogeneous with respect to the feature type or the geometry type. These clients will benefit from information that declares the feature and/or geometry type for all features in a collection.

For a feature collection where all features have the same "featureType" value, the "featureType" member can and should be added once for the feature collection. The "featureType" member can then be omitted in the features. Declaring the feature type once signals to clients that the feature collection is homogeneous with respect to the type, which clients can use to optimize their processing.

For a feature collection where all features in the feature collection have the same geometry type as their primary geometry (point, curve, surface, solid, including homogeneous aggregates), a "geometryDimension" member can and should be added once for the feature collection with the dimension of the geometry (0 for points, 1 for curves, 2 for surfaces, 3 for solids, null/not set for mixed dimensions or unknown). Declaring the geometry dimension once signals to clients that the feature collection is homogeneous with respect to the dimension, which clients can use to optimize their processing.

A JSON-FG feature schema is metadata about a feature that clients can use to understand the content of JSON-FG features, such as a textual description of the feature properties or their value range.

JSON-FG follows the approach of OGC API - Features - Part 5, that is, the feature schema is a logical schema. It can not be used to directly validate a JSON document. However, a schema for validation of a JSON-FG feature or feature collection can be derived from the logical schema, if needed. The schemas of the feature properties in the logical schemas can be reused when constructing a JSON Schema for validation.

This Standard provides guidance on how to include information about the feature schemas in a JSON-FG feature or feature collection.

If all features in the JSON document have the same feature schema (either a single feature or a homogeneous feature collection), the URI of the feature schema can and should be provided in a top-level JSON member "featureSchema" with the feature schema URI as the value.

If the features in the JSON document reference multiple feature types, the value of "featureSchema" is an object, where each key is the feature type that the schema describes.

The JSON Schema specification recommends using a "describedby" link relation to a schema that can be used to validate a JSON document:

Where JSON Schema validation is important, such links can be added. For example, OGC API Features already specifies a general "links" member with an array of link objects based on RFC 8288 (Web linking) and feature responses from APIs implementing OGC API Features will already include a "links" member.