Open Geospatial Consortium |
Submission Date: <yyyy-mm-dd> |
Approval Date: <yyyy-mm-dd> |
Publication Date: <yyyy-mm-dd> |
External identifier of this OGC® document: http://www.opengis.net/doc/IS/json-fg-1/0.2 |
Internal reference number of this OGC® document: 21-045 |
Version: 0.2.2 |
Category: OGC® Implementation Standard |
Editor: Clemens Portele, Panagiotis (Peter) A. Vretanos |
OGC Features and Geometries JSON - Part 1: Core |
Copyright notice |
Copyright © 2023 Open Geospatial Consortium |
To obtain additional rights of use, visit https://www.ogc.org/legal/ |
Warning |
This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.
Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
Document type: OGC® Standard |
Document subtype: if applicable |
Document stage: Draft |
Document language: English |
License Agreement
Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.
If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.
THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.
- 1. Scope
- 2. Conformance
- 3. References
- 4. Terms, Definitions and Abbreviated Terms
- 5. Conventions
- 6. Introduction
- 7. JSON-FG building blocks
- 8. Requirements Class "Core"
- 8.1. Syntax
- 8.2. Metadata
- 8.3. Temporal information
- 8.4. Geometry
- 8.4.1. Coordinate dimension
- 8.4.2. "geometry" in longitude/latitude
- 8.4.3. "place" geometries are valid
- 8.4.4. No point, line string or polygon geometry in WGS 84 longitude/latitude in "place"
- 8.4.5. All coordinates in a geometry collection are in the same CRS
- 8.4.6. Fallback geometry in "geometry"
- 8.4.7. Axis order of coordinate values in "place"
- 8.4.8. Coordinate values in "place"
- 9. Requirements Class "3D"
- 10. Requirements Class "Feature Types and Schemas"
- 11. Media Types
- Annex A: Abstract Test Suite (Normative)
- Annex B: Schemas (Normative)
- B.1. JSON Schema of a JSON-FG feature collection
- B.2. JSON Schema of a JSON-FG feature
- B.3. JSON Schema of the "conformsTo" member
- B.4. JSON Schema of the "time" member
- B.5. JSON Schema of the "place" member
- B.6. JSON Schema of the "coordRefSys" member
- B.7. JSON Schema of the "geometry" member
- B.8. JSON Schema of geometry objects
- B.9. JSON Schema of the "featureType" member
- B.10. JSON Schema of the "featureSchema" member
- Annex C: Examples (Informative)
- Annex D: Links (Informative)
- Annex E: Considerations (Informative)
- Annex F: Revision History
- Annex G: Bibliography
i. Abstract
GeoJSON is a very popular encoding for feature data. GeoJSON is widely supported, including in most deployments of APIs implementing the OGC API Features Standard. However, GeoJSON has intentional restrictions that prevent or limit its use in certain geospatial application contexts. For example, GeoJSON is restricted to WGS 84 coordinates, does not support volumetric geometries and has no concept of classifying features according to their type.
OGC Features and Geometries JSON (JSON-FG) is a proposal for GeoJSON extensions that provide standard ways to support such requirements. The goal is to focus on capabilities that may require some geospatial expertise, but that are useful for many. Edge cases are considered out-of-scope of JSON-FG.
Since JSON-FG specifies extensions to GeoJSON that conform to the GeoJSON standard, valid JSON-FG features or feature collections are also valid GeoJSON features or feature collections.
The Open Geospatial Consortium (OGC) invites organisations and developers that have a need for the extensions specified by this specification to implement and test the extensions. Please submit feedback in the GitHub repository of the specification. Are these extensions useful for your use cases? Are they simple enough to implement?
Note
|
There are a number of open issues under discussion at the time of the release of this draft (version 0.2). Notes in this document link to related issues in the GitHub repository. |
Uptake in implementations and sufficient feedback from implementation experience will be a prerequisite for this specification to eventually progress towards an OGC Standard.
Caution
|
This is a DRAFT. The technical requirements specified in this document can change in future versions. |
ii. Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, OGC document, JSON, JSON-FG, GeoJSON, feature, geometry
iii. Preface
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
iv. Security Considerations
The security considerations for GeoJSON as specified in Section 10 of IETF RFC 7946 also apply to JSON-FG.
v. OGC Considerations
If and once the JSON-FG Standard is approved by the OGC Members, the following actions need to be taken by OGC before publication:
-
Annex Schemas (Normative) specifies the JSON-FG schema documents. The documents will be published in the OGC Schema Repository.
-
Annex Links (Informative) may be removed.
-
Annex Considerations (Informative) will be removed.
The following actions need to be taken after publication:
-
OGC will register the media type
application/fg+json
specified in Clause Media Types with IANA.
This section will be removed before the JSON-FG Standard is published.
vi. Submitting organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
-
CubeWerx
-
Esri
-
Geonovum
-
interactive instruments
vii. Submitters
All questions regarding this submission should be directed to the editor or the submitters:
Name |
Affiliation |
Clemens Portele (editor) |
interactive instruments |
Panagiotis (Peter) A. Vretanos (editor) |
CubeWerx |
Linda van den Brink |
Geonovum |
Satish Sankaran |
Esri |
1. Scope
The OGC Features and Geometries JSON (JSON-FG) Standard extends the GeoJSON format to support a limited set of additional capabilities that are out-of-scope for GeoJSON, but that are important for a variety of use cases involving feature data.
The JSON-FG Standard specifies the following minimal extensions to the GeoJSON format:
-
The ability to use Coordinate Reference Systems (CRSs) other than WGS 84 (OGC:CRS84);
-
The ability to use non-Euclidean metrics, in particular ellipsoidal metrics;
-
Support for solids and prisms as geometry types;
-
The ability to encode temporal characteristics of a feature; and
-
The ability to declare the type and the schema of a feature.
Geographic features, their properties, and their spatial extents that can be represented as GeoJSON objects are encoded as GeoJSON. Additional information not specified in the GeoJSON RFC is mainly encoded in additional members of the GeoJSON objects. The additional members use keys that do not conflict with existing GeoJSON keys. This was done so that existing and future GeoJSON clients can continue to successfully parse and understand GeoJSON encoded content. JSON-FG enabled clients will also be able to parse and understand the additional members.
JSON Schema is used to formally specify the JSON-FG syntax.
2. Conformance
This Standard defines three requirements classes. JSON documents are the standardization target for all requirements classes.
The requirements classes are:
-
"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.
JSON documents must, at a minimum, conform to the Core requirements class in order to use the JSON-FG media type.
Conformance with the JSON-FG Standard shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site.
In order to conform to this OGC® Standard, a software implementation shall choose to implement one or more of the conformance levels specified in Annex A (normative).
All requirements-classes and conformance-classes described in this document are owned by the Standard(s) identified.
3. References
The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.
Internet Engineering Task Force (IETF). RFC 3339: Date and Time on the Internet: Timestamps. Edited by G. Klyne, C. Newman. 2002. Available at https://www.rfc-editor.org/rfc/rfc3339.html
Internet Engineering Task Force (IETF). RFC 7946: The GeoJSON Format. Edited by H. Butler, M. Daly, A. Doyle, S. Gillies, S. Hagen, T. Schaub. 2016. Available at https://www.rfc-editor.org/rfc/rfc7946.html
Open Geospatial Consortium (OGC). OGC 06-103r4: OpenGIS® Implementation Standard for Geographic information - Simple feature access - Part 1: Common architecture. Edited by J. Herring. 2011. Available at https://portal.opengeospatial.org/files/?artifact_id=25355
Open Geospatial Consortium (OGC). OGC API - Features - Part 5: Schemas 1.0 (DRAFT). Edited by C. Portele, P. Vretanos. Available at https://docs.ogc.org/DRAFTS/23-058.html
4. Terms, Definitions and Abbreviated Terms
4.1. Terms and Definitions
This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this Standard and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.
This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the 'ModSpec'. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.
For the purposes of this document, the following additional terms and definitions apply.
- coordinate reference system
-
coordinate system that is related to an object by a datum [OGC Topic 2]
Note
|
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)'. |
- feature
-
abstraction of real world phenomena [ISO 19101-1:2014]
Note
|
More details about the term 'feature' may be found in the W3C/OGC Spatial Data on the Web Best Practice in the section 'Spatial Things, Features and Geometry'. |
- feature collection
-
a set of features from a dataset
- feature schema
-
schema that describes the properties of a feature type
- feature type
-
class of features having common characteristics [ISO 19156:2023]
- JSON document
-
an information resource (series of octets) described by the application/json media type [JSON Schema 2020-12]
Note
|
The terms "JSON document", "JSON text", and "JSON value" are interchangeable. |
- JSON-FG document
-
a JSON document that conforms to the Requirements Class "Core" of OGC Features and Geometries JSON - Part 1: Core
- <JSON> key
-
the name of a member
- <JSON> member
-
a name/value pair in a JSON object
- primary geometry
-
the geometry that the publisher considers as the most important spatial characteristic of a feature (OGC API - Features - Part 5: Schemas)
Note
|
A feature can be described by multiple spatial properties. For example, a radio tower can have a property with a point value that describes the location of the tower and another property with a multi-polygon value that describes the area of coverage. Some feature formats can represent only a single geometry per feature. In those cases, the primary geometry will be used when the feature is encoded in such a format. |
Note
|
The primary geometry of a feature can also vary depending on the zoom level. At a smaller scale, the primary geometry could be a point while a polygon could be used at a larger scale. |
- primary temporal information
-
the time instant or time interval that the publisher considers as the most important temporal characteristic of a feature (OGC API - Features - Part 5: Schemas)
Note
|
A feature can be described by multiple temporal properties. For example, an event can have a property with an instant or interval when the event occurred or will occur and another property when the event was recorded in the dataset. The primary temporal information can also be built from two properties, e.g., when the feature has two properties describing the start instant and end instant of an interval. |
- publisher
-
entity responsible for making a resource available (Dublin Core Metadata Initiative - DCMI Metadata Terms)
5. Conventions
5.1. Identifiers
The normative provisions in this Standard are denoted by the URI:
http://www.opengis.net/spec/json-fg-1/0.2
All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.
5.2. Use of JSON terminology
The following terms are used as specified in JSON. In particular:
-
"member" refers to a name/value pair of an object;
-
"key" refers to the name of a member;
-
"value" refers to the value of a member, which may be an object, array, string, number, boolean, or
null
.
For example, the GeoJSON "geometry" member has the key "geometry" and one of the GeoJSON geometry objects (or null
) as its value.
5.3. Use of JSON Schema
Where possible, JSON Schema is used to formally specify the JSON-FG syntax. Additional requirements are used where JSON-Schema is not sufficient to express aspects of the JSON-FG syntax such as the relationship between the JSON-FG place
member and the fallback GeoJSON geometry
member. All schemas are in Annex 'Schemas (Normative)'.
In addition, JSON Schema is used to describe the schema of feature types, see Feature schemas.
5.4. Use of CURIEs as a compact URI notation
JSON-FG uses CURIEs (Compact URIs) as a compact notation of OGC URIs, in particular for OGC URIs of coordinate reference systems.
The policy for using CURIEs in OGC standards is documented here.
This Standard also allows the use of CURIEs where an OGC URI is expected, such as in the "coordRefSys" member or the "conformsTo" member. To be unambiguous, the use of safe CURIEs is recommended.
5.5. Extensibility
JSON-FG is designed to be extensible. Extensions to the core, to any of the other conformance classes defined in this document or the addition of new capabilities can be specified in revisions to this Standard. Extensions can also be specified in additional documents that would become additional parts of the JSON-FG Standard. Finally, extensions can be specified by communities. However, such documents will not be vetted by the OGC.
Readers of JSON-FG documents should therefore be prepared to encounter unexpected keys or unexpected values. Keys that are not recognized should be ignored. Unexpected values of a known key should be mapped to null
.
The JSON Schemas are designed to support extensions. JSON-FG documents that include custom extensions, but conform to JSON-FG requirements classes will still validate against the normative JSON-FG schemas published in the OGC Schema Repository.
The "$id" member of the schemas does not include information about the version of the Standard or the part of the JSON-FG standard. Future revisions of this Standard or additional parts of JSON-FG will update and extend the JSON-FG schemas. Changes to the JSON-FG schemas should not invalidate existing JSON-FG documents without custom extensions.
Note
|
The "CustomGeometry" object specified in "geometry-objects.json" supports this evolution of the JSON-FG schemas over time. The schema will match any geometry objects that are not specified by GeoJSON or JSON-FG. If in the future additional geometry types are added to JSON-FG, the type names would be excluded from the "type" member in "CustomGeometry". See Geometry types Arc and Circle for an example. |
Note
|
The "$id" member identifies a schema resource with its canonical URI. The member is specified by JSON Schema. |
Custom extensions should use a URI in "$id" that is controlled by the community of interest. A HTTP GET request to the URI should return the JSON Schema document.
See Extending JSON-FG for examples of how future parts or communities could extend the schemas.
6. Introduction
6.1. Motivation
JavaScript Object Notation (JSON) is a popular encoding format for geospatial data. The light weight, simple syntax, and clear human and machine readability of JSON as well as universal support in all modern programming languages appeals to developers. The GeoJSON format as defined in IETF RFC 7946 is a very popular JSON encoding for geographic data. GeoJSON is supported by many commercial and open-source geospatial technology products and libraries. GeoJSON is also supported in most deployments of APIs implementing the OGC API Features Standard. However, GeoJSON has limitations that prevent or limit its use in certain cases, including:
-
WGS 84 is the only allowed Coordinate Reference System (CRS);
-
Geometries are restricted to points, curves, and surfaces with linear interpolation; and
-
No general capability is available to specify the schema of a feature, its type, or its temporal characteristics.
6.2. Scenarios
The following general scenarios are useful in understanding the principles that were used in the JSON-FG design:
-
In order to display features in a 3D scene, a client accesses a Web API that shares a building dataset and that implements the OGC API Features Standard. The scene uses a projected CRS, such as
EPSG:5555
. The API advertises support for both GeoJSON and JSON-FG as feature representations and support for the projected CRS in addition to WGS 84. -
A client accesses a JSON-FG file with building data that is stored locally or as a static file in the cloud (e.g., in an Object Storage or a GitHub repository). Again, the file is accessed to display features in a 3D scene and a time slider is used to suppress features outside of a user-specified time interval.
Note
|
The following descriptions use application/vnd.ogc.fg+json as the media type for JSON-FG.
|
6.2.1. Using a GeoJSON client
Consider the case where the client implementation only supports GeoJSON and not JSON-FG. An assumption is that the client does support CRS transforms.
In the first scenario (API access), the client requests the GeoJSON representation of the feature using Accept: application/geo+json
. This is because the client only supports a GeoJSON feature encoding. The response should not include the JSON-FG extensions. Further, the response is provided in the WGS 84 CRS with axis order longitude/latitude. The client can then transform the geometry to the projected CRS.
In the second scenario (file access), the client has no access to a media type and has to inspect the file to determine if the file is a GeoJSON document that it can process. While the document is a JSON-FG document it is also a valid GeoJSON document. Therefore, the client is still able to use and display the features. The client will, however, not understand the additional information introduced by JSON-FG. To avoid issues for GeoJSON clients parsing JSON-FG documents, the names of any JSON-FG extension members must not conflict with the names of existing GeoJSON members to avoid issues for GeoJSON clients parsing JSON-FG documents.
6.2.2. Using a JSON-FG client
The client implementation supports both GeoJSON and JSON-FG.
In the first scenario (API access), the client will typically request the JSON-FG representation of the feature using an HTTP header such as Accept: application/vnd.ogc.fg+json, application/geo+json;q=0.8
and a crs=http://www.opengis.net/def/crs/EPSG/0/5555
query parameter. The header states that the client prefers JSON-FG, but if JSON-FG is not available it will also accept GeoJSON. The response will include the headers Content-Type: application/vnd.ogc.fg+json
as well as Content-Crs: http://www.opengis.net/def/crs/EPSG/0/5555
and include the JSON-FG building blocks including the geometry in the requested projected CRS and temporal information.
In the second scenario (file access), the JSON-FG client is in the same position as the GeoJSON client. The client has no access to a media type and has to inspect the file to determine the type. The file could be GeoJSON, JSON-FG or some other kind of document that the client does not understand. JSON-FG documents include explicit declarations that conform to both GeoJSON and JSON-FG. Therefore, the client can identify the document as a JSON-FG document and process the content. Since the JSON-FG document provides spatial and temporal information about each feature, the client can zoom in on the features and, for example, provide a time slider so that the user can filter the features that are displayed.
7. JSON-FG building blocks
This Clause describes the JSON building blocks required to extend GeoJSON features and feature collections. The following clauses specify the formal requirements classes.
The Annex 'Considerations (Informative)' contains considerations for each of the JSON-FG building blocks.
Remarks and known open issues are included in notes.
7.1. Overview
The following JSON building blocks are specified by this Standard:
An additional discussion topic during the development of the JSON-FG Standard was the relationship between a feature and other web resources that are represented as links. The JSON-FG Standard does not mandate a specific approach for representing relationships as links. However, Annex 'Links (Informative)' documents and discusses patterns of how to represent relationships as links.
Annex 'Examples (Informative)' has examples of JSON-FG documents.
7.2. General Approach
The GeoJSON RFC clearly specifies in Clauses 6 and 7 that additional members can be added to the GeoJSON objects as long as they do not conflict with members as specified by GeoJSON ("foreign members").
JSON-FG extends GeoJSON in two ways:
-
By adding new JSON members to the "Feature" and "FeatureCollection" objects;
-
By specifying additional geometry objects.
As a result, JSON-FG does not place constraints on the information in the "properties" member (like GeoJSON) and JSON-FG readers do not have to parse the "properties" object. This approach avoids name clashes with existing feature properties in the "properties" object.
Some GeoJSON readers, however, only provide access to the pre-defined JSON members in GeoJSON features, such as "id", "geometry", "bbox" and "properties". If the target audience of JSON-FG documents uses such tools, it is recommended to also include the additional top-level members like "time", "place", "featureType", and "coordRefSys" in the "properties" object.
7.3. Metadata
To indicate that a JSON document is a JSON-FG document and to indicate the JSON-FG version and conformance classes implemented in the document, a conformsTo
member is required to be included in the JSON-FG document object.
The value of the member is an array of strings, where each string is a URI of a conformance class.
1
2
3
4
"conformsTo" : [
"http://www.opengis.net/spec/json-fg-1/0.2/conf/core",
"http://www.opengis.net/spec/json-fg-1/0.2/conf/3d"
]
As an alternative to URIs, the Compact URI (CURIE) [ogc-json-fg-1-{x.y}:{conformanceClassId}]
can also be used. {x.y}
is the version number (0.2
for this version), {conformanceClassId}
the local identifier of the implemented conformance class.
1
"conformsTo" : [ "[ogc-json-fg-1-0.2:core]", "[ogc-json-fg-1-0.2:3d]" ]
7.4. Temporal information
7.4.1. Overview
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. 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 future extensions.
7.4.2. Description
Features can have temporal properties. These properties will typically be included in the "properties" member.
-
In many datasets all temporal properties are instants (represented by a date or a timestamp) and intervals are described using two temporal instants, one for the start and one for the end.
-
Multiple temporal properties are sometimes used to describe different temporal characteristics of a feature. For example, the time instant or interval when the information in the feature is valid (sometimes called "valid time") and the time when the feature was recorded in the dataset (sometimes called "transaction time"). Another example is the Observations & Measurements Standard, where an observation has multiple temporal properties including "phenomenon time", "result time" and "valid time".
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 object (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 value of "time" is either null
(no temporal information) or an object.
Property | Type | Description |
---|---|---|
date |
string |
An instant with a granularity of a date. See below for more details about instants. |
timestamp |
string |
An instant with the granularity of a timestamp. See below for more details about instants. |
interval |
[ string ] |
An interval, described by an array of the two instants (start and end). See below for more details about intervals. |
If both values intersect, then including both an instant and an interval is valid. 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 an "instant" or "interval", a client may process the feature as a feature without temporal information.
Note
|
The data publisher decides how temporal properties inside the "properties" member are encoded. The schema for the "time" member does not imply a recommendation that temporal feature properties reuse the same schema. For example, it is expected that a date-valued feature attribute will in most cases be represented as string with an RFC 3339 date value. |
7.4.3. Instants
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:
-
full-date
(e.g.,"1969-07-20"
) -
date-time
(e.g.,"1969-07-20T20:17:40Z"
)
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.
Note
|
The JSON-FG Standard only provides guidance as to how to represent feature data in JSON. Providing guidance as to how to cast JSON-FG data to other data types is out of scope. The OGC Common Query Language (CQL2) Standard uses the same model of instants and intervals as JSON-FG and includes additional guidance how to compare values. |
1
"time" : { "date": "1969-07-20" }
1
"time" : { "timestamp": "1969-07-20T20:17:40Z" }
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 may ignore values that they do not understand.
7.4.4. Intervals
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.
Note
|
There is a proposal to use null instead of "..".
|
1
"time" : { "interval": [ "1969-07-16", "1969-07-24" ] }
1
"time" : { "interval": [ "1969-07-16T05:32:00Z", "1969-07-24T16:50:35Z" ] }
1
"time" : { "interval": [ "2014-04-24T10:50:18Z", ".." ] }
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 may ignore values that they do not understand.
7.5. Geometry
7.5.1. Overview
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 or OGC:CRS84h).
A key motivation for the development of the JSON-FG Standard is to support additional requirements, especially the ability to express other CRSs and solid geometries.
To avoid confusing existing GeoJSON readers, such geometries are provided in a new member in the feature object with the key "place".
Note
|
There is an ongoing discussion to use a different key instead of "place". This discussion has to be resolved and this note must be removed before finalizing the JSON-FG Standard. |
7.5.2. Description
The primary geometry of a feature is provided in the "geometry" and/or "place" members of the feature object as specified in the next sub-clause. The value of both members is an object representing a geometry - or null
.
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:
-
Extended by additional geometry objects (additional JSON-FG geometry types Polyhedron, MultiPolyhedron, Prism, and MultiPrism) as well as by the capabilities to declare the coordinate reference system of the coordinates.
-
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 include an unknown geometry type should be mapped to
null
.
Note
|
The JSON-FG standard does not add a new JSON-FG geometry collection that includes the new JSON-FG geometry types, because geometry collections are rarely used as feature geometries. |
Note
|
There is an ongoing discussion about which 3D geometries should be included in JSON-FG and how they should be grouped into conformance classes. This discussion has to be resolved and this note must be removed before finalizing the JSON-FG Standard. |
Note
|
There is an ongoing discussion on a proposal to add additional geometry types supporting curves with circular arc interpolation to JSON-FG. This discussion has to be resolved and this note must be removed before finalizing the JSON-FG Standard. |
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.
Use of "geometry" and/or "place"
If the geometry is a valid GeoJSON geometry (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
.
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 a JSON-FG document is indicated by a value "geojson" in the media type parameter "compatibility" (see application/fg+json).
Note
|
GeoJSON states that "geometry" is null , if the feature is "unlocated". A real-world entity is obviously not unlocated when "place" has a value. However, the GeoJSON representation of the feature can still considered to be "unlocated", if a representation in a WGS 84 CRS cannot be determined. Examples for such situations are: a local engineering CRS or a planetary CRS is used for the geometry in "place", or if the known consumers of the JSON-FG document do not need the fallback geometry.
|
Metrics
If the CRS uses longitude and latitude as coordinates, clients should perform geometrical computations - including computation of length or area on the curved surface that approximates the earth’s surface. Details are provided, for example, in the drafts of Features and Geometry - Part 2: Metrics.
Note that this differs from GeoJSON which states:
A line between two positions is a straight Cartesian line, the shortest line between those two points in the coordinate reference system.
In other words, every point on a line that does not cross the antimeridian between a point (lon0, lat0) and (lon1, lat1) can be calculated as F(lon, lat) = (lon0 + (lon1 - lon0) * t, lat0 + (lat1 - lat0) * t)
with t being a real number greater than or equal to 0 and smaller than or equal to 1. Note that this line may markedly differ from the geodesic path along the curved surface of the reference ellipsoid.
Note
|
Antimeridian: is the meridian 180° both east and west of the prime meridian in a geographical coordinate system. The longitude at this line can be given as either east or west. |
Polyhedron
A solid is defined by its bounding surfaces. Each bounding surface is a closed, simple surface, also called a shell.
Each solid has a unique exterior shell and any number of shells that are inside the exterior shell and that describe voids. The interior shells do not intersect each other and cannot contain another interior shell.
A polyhedron is a solid where each shell is a multi-polygon. 'Closed' means that the multi-polygon shell is watertight, it splits space into two distinct regions: inside and outside of the shell. 'Simple' means that the polygons that make up the shell do not intersect, they only touch each other along their common boundaries.
The JSON representation of the coordinates of a polyhedron is a non-empty array of multi-polygon arrays. Each multi-polygon array is a shell. The first shell is the exterior boundary, all other shells are voids.
Note
|
As in a GeoJSON Polygon, the first and last positions of each ring have identical values. |
The dimension of all positions is three.
The Cologne Cathedral with polyhedron geometries is provided as an example in Annex C.
MultiPolyhedron
A multi-polyhedron is a collection of polyhedron objects. These are arbitrary aggregations. There is no assumption regarding the topological relationships between the polyhedron objects, but in most cases the polyhedron objects will not intersect each other.
Note
|
According to ISO 19107:2020 ("Spatial schema"), the geometry of the multi-polyhedron is the set theoretic union of all polyhedron objects. For example, if there are overlapping polyhedron objects, the volume of the multi-polyhedron will be smaller than the sum of the polyhedron volumes. |
The collection of polyhedron objects is represented as a JSON array. The order of the polyhedron objects in the array is not significant.
Prism
A prism is defined by a base shape (e.g. Polygon or Circle) that is then extruded from some optional lower limit to an upper limit.
The limits are measured relative to a specified 3D CRS. That is either the default 3D CRS (OGC:CRS84h) or another 3D CRS specified using the coordRefSys key.
If the base shape is a point, then the extrusion is a line extending from the lower limit to the upper limit.
A pylon feature with a base shape of a point is provided as an example in Annex C.
If the base shape is a line string, then the extrusion is a ribbon following the path of the line string and extending from the lower limit to the upper limit.
A fence feature with a base shape of a line string is provided as an example in Annex C.
If the base shape is a polygon, then the extrusion is a solid whose footprint takes the shape of the specified polygon and extended from the lower limit to the upper limit. If the polygon base shape contains holes, these manifest as voids in the extruded shape.
MultiPrism
A multi-prism is an array of prism objects. The order of the prism geometry objects in the array is not significant.
The following figure shows a 3D rendering of Toronto City Hall. The feature with a MultiPrism geometry is provided as an example in Annex C.
7.6. Reference systems
7.6.1. Overview
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) orOGC:CRS84h
(3D) as registered with the OGC; -
Temporal CRS: DateTime in Gregorian calendar,
OGC:GregorianDateTime
.
Note
|
In OGC:GregorianDateTime , all granularities of ISO 8601 are valid values according to OGC Abstract Specification Topic 2: Referencing by coordinates, section D.3. That is, both dates and timestamps are valid values in the OGC:GregorianDateTime CRS.
|
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.
7.6.2. Description
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.
Reference system values
A reference system can be specified in a JSON-FG document using a "coordRefSys" member in one of three ways:
-
As a CRS reference using the URI or OGC CURIE of a simple CRS;
-
As a CRS reference using the URI or OGC CURIE of a simple CRS accompanied by an optional epoch value (for dynamic CRSs);
-
As an array of simple CRS references denoting an ad hoc compound reference system.
1
"http://www.opengis.net/def/crs/EPSG/0/3857"
1
"[EPSG:3857]"
The epoch is the point in time, expressed as a decimal year, to which coordinates in a dynamic coordinate reference system are referenced. The epoch 2017.23 is March 25, 2017 in the Gregorian calendar.
1
2
3
4
5
{
"type": "Reference",
"href": "http://www.opengis.net/def/crs/EPSG/0/4979",
"epoch": 2017.23
}
1
2
3
4
5
6
7
8
[
{
"type": "Reference",
"href": "http://www.opengis.net/def/crs/EPSG/0/4258",
"epoch": 2016.47
},
"http://www.opengis.net/def/crs/EPSG/0/7837"
]
1
2
3
4
5
6
7
8
[
{
"type": "Reference",
"href": "[EPSG:4258]",
"epoch": 2016.47
},
"[EPSG: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.
Coordinate order
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.
Additional coordinate reference systems
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).
7.7. Feature types
7.7.1. Overview
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 most cases, a feature is an instance of a single feature type, but in general, features can be instances of multiple types. JSON-FG also supports multiple feature types.
The related section Feature schemas specifies the schema for each feature type if such information is available.
7.7.2. Description
The "featureType" member
The feature types of a feature are declared in a member of the feature object with the key "featureType". The value is either a string (in the standard case of a single feature type) or an array of strings (to support features that instantiate multiple feature types). Each string 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).
Note
|
A feature type that "just" identifies a concept, but has no associated or no well-defined schema, will not include a schema reference in the "featureSchema" member (see below) for the feature type in the JSON-FG document. |
Note
|
The IANA link relations include a link relation "type" which can, in addition, be used to reference a resource that describes a feature type beyond the code in the "featureType" member. |
Homogeneous feature collections
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.
If the JSON document is a feature collection and all features in the feature collection 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 feature objects. Declaring the feature type(s) once signals to clients that the feature collection is homogeneous with respect to the type, which clients can use to optimize their processing.
If the JSON document is a feature collection and 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.
7.8. Feature schemas
7.8.1. Overview
A JSON-FG feature schema is metadata about a feature that clients can use to understand the content of JSON-FG feature objects, 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-FG 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.
The JSON-FG Standard provides guidance on how to include information about the feature schemas in a JSON-FG feature or feature collection.
7.8.2. Description
The "featureSchema" member
If all features in a JSON-FG document (either a single feature or a homogeneous feature collection) have the same feature schema, 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.
{
"type": "FeatureCollection",
"featureType": "Airport",
"featureSchema": "https://demo.ldproxy.net/zoomstack/collections/airports/schema",
"geometryDimension": 0,
"conformsTo": [ "[ogc-json-fg-1-0.2:core]", "[ogc-json-fg-1-0.2:types-schemas]" ],
"features": [ ... ]
}
If the features in the JSON-FG document reference multiple feature types, the value of "featureSchema" is an object, where each key is the feature type that the schema describes.
{
"type": "FeatureCollection",
"featureSchema": {
"Airport": "https://demo.ldproxy.net/zoomstack/collections/airports/schema",
"RailwayStation": "https://demo.ldproxy.net/zoomstack/collections/railway_stations/schema"
},
"conformsTo": [ "[ogc-json-fg-1-0.2:core]", "[ogc-json-fg-1-0.2:types-schemas]" ],
"features": [ ... ]
}
Referencing schema for JSON Schema validation
The JSON Schema specification recommends using a "describedby" link relation to a schema that can be used to validate a JSON document:
RECOMMENDATION: Instances described by a schema provide a link to a downloadable JSON Schema using the link relation "describedby" […].
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.
8. Requirements Class "Core"
The Requirements Class "Core" specifies provisions for encoding information about the primary geometry and temporal information of a feature in JSON.
Requirements Class |
|
Target type |
JSON documents |
Dependency |
|
Indirect Dependency |
|
Indirect Dependency |
A JSON-FG document is either a feature or feature collection that meets all requirements described in this clause and also meets all requirements stated in the GeoJSON standard for GeoJSON features or feature collections.
Note
|
This version only specifies provisions for embedding JSON-FG geometry objects as part of a feature or feature collection JSON-FG document. In general, it would be useful to specify rules for using JSON-FG geometry objects in another context, too. The JSON-FG working group agrees that this requirements class should be changed to support this, but this change was too late to be included in the draft version before the Public Comment period of this document. See Geometry objects in non-feature(collection) documents for more information. |
8.1. Syntax
Requirement 1 |
/req/core/schema-valid |
A |
The JSON document SHALL validate against the JSON Schema of a JSON-FG feature (a JSON-FG feature) or the JSON Schema of a JSON-FG feature collection (a JSON-FG feature collection). |
While every JSON-FG document must validate against the associated JSON-FG schema, executing the validation is only necessary when testing conformance. Implementations reading or writing JSON-FG do not have to perform validation. It is also not necessary to publish application- or community-specific schemas that describe the schema of the feature properties to conform to the Core requirements class.
Recommendation 1 |
/rec/core/properties |
A |
If a JSON-FG document is expected to be parsed by clients that only allow access to the JSON members in the GeoJSON Feature schema (in particular the id, the geometry, and the properties), any additional JSON members in the JSON-FG Feature schema ("time", "place", "coordRefSys", and "featureType") SHOULD also be included in the "properties" object. |
Note
|
There is an open discussion as to whether this recommendation should apply only in the "GeoJSON compatibility mode" (i.e., if the "compatibility" media type parameter is set). This discussion has to be resolved and this note must be removed before finalizing the JSON-FG Standard. |
8.2. Metadata
8.2.1. Conformance declaration
Requirement 2 |
/req/core/metadata |
A |
The JSON document SHALL include a "conformsTo" member. |
B |
The "conformsTo" member of the JSON document SHALL include at least one of the two following values:
|
C |
Only the root object of the JSON document SHALL include a "conformsTo" member. |
8.3. Temporal information
8.3.1. Instants
Requirement 3 |
/req/core/instant |
A |
If the "time" object in any JSON-FG feature in the JSON document includes a "date" member, the value SHALL conform to RFC 3339 (Date and Time on the Internet: Timestamps) and match the production rule |
B |
If the "time" object in any JSON-FG feature in the JSON document includes a "timestamp" member, the value SHALL conform to RFC 3339 (Date and Time on the Internet: Timestamps) and match the production rule |
8.3.2. Intervals
Requirement 4 |
/req/core/interval |
A |
If the "time" object in any JSON-FG feature in the JSON document includes an "interval" member, each array item SHALL be a string that is a double-dot ("..") or conforms to RFC 3339 (Date and Time on the Internet: Timestamps) and match one of the following production rules: |
B |
If the start is a date, the end SHALL be a date, too, or "..". |
C |
If the start is a timestamp, the end SHALL be a timestamp, too, or "..". |
8.3.3. Instants and intervals
Requirement 5 |
/req/core/instant-and-interval |
A |
If the "time" object in any JSON-FG feature in the JSON document includes both a "date" and a "timestamp" member, the |
B |
If the "time" object in any JSON-FG feature in the JSON document includes both a "timestamp" and an "interval" member with start/end dates, the interval SHALL contain the date of the timestamp. |
C |
If the "time" object in any JSON-FG feature in the JSON document includes both a "timestamp" and an "interval" member with start/end timestamps, the interval SHALL contain the timestamp. |
D |
If the "time" object in any JSON-FG feature in the JSON document includes both a "date" and an "interval" member with start/end dates, the interval SHALL contain the date. |
E |
If the "time" object in any JSON-FG feature in the JSON document includes both a "date" and an "interval" member with start/end timestamps, the interval SHALL include timestamps on the date. |
8.4. Geometry
8.4.1. Coordinate dimension
Requirement 7 |
/req/core/coordinate-dimension |
A |
All positions in a geometry object in the "geometry" or "place" members in any JSON-FG feature in the JSON document SHALL have the same dimension. |
8.4.2. "geometry" in longitude/latitude
Requirement 8 |
/req/core/geometry-wgs84 |
A |
If the "geometry" member in a JSON-FG feature in the JSON document is not |
B |
If the "geometry" member in a JSON-FG feature in the JSON document is not |
8.4.3. "place" geometries are valid
Requirement 9 |
/req/core/geom-valid |
A |
If the "place" member in any JSON-FG feature in the JSON document is not |
8.4.4. No point, line string or polygon geometry in WGS 84 longitude/latitude in "place"
Requirement 10 |
/req/core/place |
A |
If the "place" member in any JSON-FG feature in the JSON document is not |
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.
8.4.5. All coordinates in a geometry collection are in the same CRS
Requirement 11 |
/req/core/geometry-collection |
A |
If the "place" member in any JSON-FG feature in the JSON document is not |
For example, the "Prism" geometry specified in the Requirements Class "3D" includes an embedded 2D base geometry. The base geometry cannot include a "coordRefSys" member.
8.4.6. Fallback geometry in "geometry"
Requirement 12 |
/req/core/fallback |
A |
If both the "place" and the "geometry" member in a JSON-FG feature in the JSON document are not |
B |
If both the "place" and the "geometry" member in a JSON-FG feature in the JSON document are not |
8.4.7. Axis order of coordinate values in "place"
Requirement 13 |
/req/core/axis-order If the "place" member in any JSON-FG feature in the JSON document is not |
8.4.8. Coordinate values in "place"
Recommendation 2 |
/rec/core/place-crs |
A |
If the "place" member in any JSON-FG feature in the JSON document is not |
B |
If the "place" member in any JSON-FG feature in the JSON document is not |
See the description above how to determine the CRS of a geometry object.
Note
|
This is only a recommendation, and not a requirement. This is because there are often valid reasons to have coordinates outside of the range, for example outside of a UTM zone that covers most of the area of a dataset. |
9. Requirements Class "3D"
The "3D" Requirements Class adds provisions for geometries in a 3D CRS that may be of type Polyhedron, MultiPolyhedron, Prism, or MultiPrism.
Requirements Class |
|
Target type |
JSON documents |
Dependency |
9.2. Geometry
9.2.1. Coordinate dimension
Requirement 15 |
/req/3d/coordinate-dimension |
A |
All positions in a "Polyhedron" or "MultiPolyhedron" geometry object in the "place" member in any JSON-FG feature in the JSON document SHALL have a coordinate dimension of three (3). |
9.2.2. Geometries are valid
Requirement 16 |
/req/3d/geom-valid |
A |
If the "place" member in any JSON-FG feature in the JSON document is not
|
B |
If the "place" member in any JSON-FG feature in the JSON document is not |
C |
If the "place" member in any JSON-FG feature in the JSON document is not |
D |
If the "place" member in any JSON-FG feature in the JSON document is not |
Clients should, if possible, be tolerant and also accept shells with an incorrect orientation.
10. Requirements Class "Feature Types and Schemas"
The Requirements Class "Feature Types and Schemas" adds provisions for feature type classifications and schemas.
Requirements Class |
|
Target type |
JSON documents |
Dependency |
|
Indirect Dependency |
10.2. Feature type(s)
10.2.1. "featureType" is present
Requirement 18 |
/req/types-schemas/feature-type |
A |
If the JSON document is a JSON-FG feature, the feature object SHALL have a member "featureType". |
B |
If the JSON document is a JSON-FG feature collection, either the feature collection object SHALL have a member "featureType" or each feature object SHALL have a member "featureType". |
10.2.2. Value in "geometryDimension"
Requirement 19 |
/req/types-schemas/geometry-dimension |
A |
If the JSON document is a JSON-FG feature collection with a member "geometryDimension" that is not |
10.2.3. Homogeneous feature collections
Recommendation 3 |
/rec/types-schemas/homogeneous-collection |
A |
If the JSON document is a JSON-FG feature collection and each feature is of the same feature type, the feature type information SHOULD be specified in the feature collection. |
B |
If the JSON document is a JSON-FG feature collection and the primary geometry of each feature has the same dimension (0 for a Point/MultiPoint, 1 for a LineString/MultiLineString, 2 for a Polygon/MultiPolygon, 3 for a Polyhedron/MultiPolyhedron/Prism/MultiPrism), the feature collection object SHOULD contain a member "geometryDimension". |
10.3. Feature schema
10.3.1. Feature schemas conform to OGC API - Features - Part 5: Schemas
Requirement 20 |
/req/types-schemas/feature-schemas |
A |
If the JSON document is a JSON-FG feature or feature collection with a "featureSchema" member, all referenced schemas SHALL conform to OGC API - Features - Part 5: Schemas. |
10.3.2. Single feature schema implies one feature type
Requirement 21 |
/req/types-schemas/single-feature-schema |
A |
If the JSON document is a JSON-FG feature or feature collection with a "featureSchema" member where the value is a string (URI), all "featureType" members in the JSON document SHALL declare a single feature type and all SHALL have the same value. |
11. Media Types
Note
|
Implementations should use application/vnd.ogc.fg+json as a preliminary media type until this Standard is stable to avoid confusing future implementations accessing JSON documents from draft versions of this Standard. The media type application/fg+json will be registered for JSON-FG, if and once this Standard is approved by the OGC Members. This note will be removed before publishing the JSON-FG Standard.
|
Since a JSON-FG document also conforms to GeoJSON, both the GeoJSON and the JSON-FG media types can be used. APIs that provide feature data that conforms to both GeoJSON and JSON-FG should declare support for both media types in the API definition to support clients that know JSON-FG as well as those that only support GeoJSON.
11.1. application/fg+json
Type name: application Subtype name: fg+json Required parameters: n/a Optional parameters: "compatibility": If provided, the value "geojson" indicates that JSON-FG features with a "place" member that is not 'null' will also include a GeoJSON geometry in the "geometry" member (a point, line string, polygon or an aggregation of them in WGS 84). If the parameter is missing, the "geometry" member of a JSON-FG feature will be 'null', if the "place" member is not 'null'. For any other parameter value, the behavior is unspecified. Encoding considerations: binary Security considerations: The security considerations for GeoJSON as specified in Section 10 of IETF RFC 7946 also apply to JSON-FG. Interoperability considerations: The interoperability considerations for GeoJSON as specified in Section 11 of IETF RFC 7946 also apply to JSON-FG. Published specification: this document Applications that use this media type: No known applications currently use this media type. This media type is intended for applications currently using the "application/vnd.ogc.fg+json" media type, which include APIs for managing, publishing or processing geospatial data, tools for processing geospatial data, web mapping applications, etc. Additional information: Magic number(s): n/a File extension(s): .json, .jsonfg Macintosh file type code: TEXT Person to contact for further information: 1. Name: Scott Simmons 2. Email: ssimmons@ogc.org Intended usage: COMMON GeoJSON (IETF RFC 7946) is a popular encoding for geospatial data. GeoJSON is widely supported. However, GeoJSON has intentional restrictions that prevent or limit its use in certain geospatial application contexts. For example, GeoJSON is restricted to WGS 84 coordinates, does not support volumetric geometries and has no concept of classifying features according to their type. JSON-FG (OGC Features and Geometries JSON) specifies a set of GeoJSON extensions that provide standard ways to support such requirements. Restrictions on usage: n/a Change controller: Open Geospatial Consortium (OGC)
Annex A: Abstract Test Suite (Normative)
Note
|
An Abstract Test Suite will be added once the normative statements are stable. The primary test will be schema validation with additional tests for requirements that cannot be checked with validation. |
Annex B: Schemas (Normative)
Note
|
The JSON-FG Schema documents will only be published in the OGC Schema Repository, if and once the JSON-FG Standard has been approved. Until then, the schema documents will be made available in the OGC Schema Repository for drafts. This note will be removed before publishing the JSON-FG Standard. |
B.1. JSON Schema of a JSON-FG feature collection
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://beta.schemas.opengis.net/json-fg/featurecollection.json",
"title": "a JSON-FG Feature Collection",
"description": "This JSON Schema is part of JSON-FG version 0.2.2",
"type": "object",
"required": ["type", "features"],
"properties": {
"conformsTo": {
"$ref": "conformsto.json"
},
"type": {
"type": "string",
"enum": ["FeatureCollection"]
},
"featureType": {
"$ref": "featuretype.json"
},
"geometryDimension": {
"type": "integer",
"minimum": 0,
"maximum": 3
},
"featureSchema": {
"$ref": "featureschema.json"
},
"coordRefSys": {
"$ref": "coordrefsys.json"
},
"features": {
"type": "array",
"items": {
"$ref": "feature.json"
}
}
}
}
B.2. JSON Schema of a JSON-FG feature
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://beta.schemas.opengis.net/json-fg/feature.json",
"title": "a JSON-FG Feature",
"description": "This JSON Schema is part of JSON-FG version 0.2.2",
"type": "object",
"required": ["type", "time", "place", "geometry", "properties"],
"properties": {
"conformsTo": {
"$ref": "conformsto.json"
},
"type": {
"type": "string",
"enum": ["Feature"]
},
"id": {
"oneOf": [
{
"type": "number"
},
{
"type": "string"
}
]
},
"featureType": {
"$ref": "featuretype.json"
},
"featureSchema": {
"$ref": "featureschema.json"
},
"time": {
"$ref": "time.json"
},
"coordRefSys": {
"$ref": "coordrefsys.json"
},
"place": {
"$ref": "place.json"
},
"geometry": {
"$ref": "geometry.json"
},
"properties": {
"oneOf": [
{
"type": "null"
},
{
"type": "object"
}
]
}
}
}
B.3. JSON Schema of the "conformsTo" member
1
2
3
4
5
6
7
8
9
10
11
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://beta.schemas.opengis.net/json-fg/conformsto.json",
"title": "the conformsTo member",
"description": "This JSON Schema is part of JSON-FG version 0.2.2",
"type": "array",
"minItems": 1,
"items": {
"type": "string"
}
}
B.4. JSON Schema of the "time" member
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://beta.schemas.opengis.net/json-fg/time.json",
"title": "the time member",
"description": "This JSON Schema is part of JSON-FG version 0.2.2",
"oneOf": [
{
"type": "null"
},
{
"type": "object",
"properties": {
"date": {
"$ref": "#/$defs/date"
},
"timestamp": {
"$ref": "#/$defs/timestamp"
},
"interval": {
"$ref": "#/$defs/interval"
}
}
}
],
"$defs": {
"date": {
"type": "string",
"pattern": "^\\d{4}-\\d{2}-\\d{2}$"
},
"timestamp": {
"type": "string",
"pattern": "^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}(?:\\.\\d+)?Z$"
},
"interval": {
"type": "array",
"minItems": 2,
"maxItems": 2,
"items": {
"oneOf": [
{
"$ref": "#/$defs/date"
},
{
"$ref": "#/$defs/timestamp"
},
{
"type": "string",
"enum": [".."]
}
]
}
}
}
}
B.5. JSON Schema of the "place" member
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://beta.schemas.opengis.net/json-fg/place.json",
"title": "the place member",
"description": "This JSON Schema is part of JSON-FG version 0.2.2",
"oneOf": [
{
"type": "null"
},
{
"$ref": "geometry-objects.json#/$defs/Point"
},
{
"$ref": "geometry-objects.json#/$defs/MultiPoint"
},
{
"$ref": "geometry-objects.json#/$defs/LineString"
},
{
"$ref": "geometry-objects.json#/$defs/MultiLineString"
},
{
"$ref": "geometry-objects.json#/$defs/Polygon"
},
{
"$ref": "geometry-objects.json#/$defs/MultiPolygon"
},
{
"$ref": "geometry-objects.json#/$defs/Polyhedron"
},
{
"$ref": "geometry-objects.json#/$defs/MultiPolyhedron"
},
{
"$ref": "geometry-objects.json#/$defs/Prism"
},
{
"$ref": "geometry-objects.json#/$defs/MultiPrism"
},
{
"$ref": "geometry-objects.json#/$defs/CustomGeometry"
}
]
}
B.6. JSON Schema of the "coordRefSys" member
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://beta.schemas.opengis.net/json-fg/coordrefsys.json",
"title": "the coordRefSys member",
"description": "This JSON Schema is part of JSON-FG version 0.2.2",
"oneOf": [
{
"$ref": "#/$defs/single-refsys"
},
{
"type": "array",
"items": {
"$ref": "#/$defs/single-refsys"
},
"minItems": 2
}
],
"$defs": {
"single-refsys": {
"oneOf": [
{
"$ref": "#/$defs/refsys-simpleref"
},
{
"$ref": "#/$defs/refsys-byref"
},
{
"$ref": "#/$defs/refsys-custom"
}
]
},
"refsys-simpleref": {
"type": "string",
"description": "The value is either a URI or a CURIE."
},
"refsys-byref": {
"type": "object",
"required": ["type", "href"],
"properties": {
"type": {
"type": "string",
"enum": ["Reference"]
},
"href": {
"type": "string",
"description": "The value is either a URI or a CURIE."
},
"epoch": {
"type": "number"
}
}
},
"refsys-custom": {
"type": "object",
"required": ["type"],
"properties": {
"type": {
"type": "string",
"not": {
"enum": ["Reference"]
}
}
}
}
}
}
B.7. JSON Schema of the "geometry" member
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://beta.schemas.opengis.net/json-fg/geometry.json",
"title": "the geometry member",
"description": "This JSON Schema is part of JSON-FG version 0.2.2",
"oneOf": [
{
"type": "null"
},
{
"$ref": "geometry-objects.json#/$defs/Point"
},
{
"$ref": "geometry-objects.json#/$defs/MultiPoint"
},
{
"$ref": "geometry-objects.json#/$defs/LineString"
},
{
"$ref": "geometry-objects.json#/$defs/MultiLineString"
},
{
"$ref": "geometry-objects.json#/$defs/Polygon"
},
{
"$ref": "geometry-objects.json#/$defs/MultiPolygon"
},
{
"$ref": "geometry-objects.json#/$defs/GeometryCollection"
}
]
}
B.8. JSON Schema of geometry objects
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://beta.schemas.opengis.net/json-fg/geometry-objects.json",
"title": "the geometry objects",
"description": "This JSON Schema is part of JSON-FG version 0.2.2",
"$defs": {
"CustomGeometry": {
"title": "A custom geometry object",
"type": "object",
"required": ["type"],
"properties": {
"type": {
"type": "string",
"not": {
"enum": [
"Point",
"MultiPoint",
"LineString",
"MultiLineString",
"Polygon",
"MultiPolygon",
"Polyhedron",
"MultiPolyhedron",
"Prism",
"MultiPrism",
"GeometryCollection"
]
}
}
}
},
"Point": {
"title": "GeoJSON Point with additional 'coordRefSys' member",
"type": "object",
"required": ["type", "coordinates"],
"properties": {
"type": {
"type": "string",
"enum": ["Point"]
},
"coordRefSys": {
"$ref": "coordrefsys.json"
},
"coordinates": {
"$ref": "#/$defs/position"
},
"bbox": {
"$ref": "#/$defs/bbox"
}
}
},
"LineString": {
"title": "GeoJSON LineString with additional 'coordRefSys' member",
"type": "object",
"required": ["type", "coordinates"],
"properties": {
"type": {
"type": "string",
"enum": ["LineString"]
},
"coordRefSys": {
"$ref": "coordrefsys.json"
},
"coordinates": {
"type": "array",
"minItems": 2,
"items": {
"$ref": "#/$defs/position"
}
},
"bbox": {
"$ref": "#/$defs/bbox"
}
}
},
"Polygon": {
"title": "GeoJSON Polygon with additional 'coordRefSys' member",
"type": "object",
"required": ["type", "coordinates"],
"properties": {
"type": {
"type": "string",
"enum": ["Polygon"]
},
"coordRefSys": {
"$ref": "coordrefsys.json"
},
"coordinates": {
"type": "array",
"items": {
"type": "array",
"minItems": 4,
"items": {
"$ref": "#/$defs/position"
}
}
},
"bbox": {
"$ref": "#/$defs/bbox"
}
}
},
"MultiPoint": {
"title": "GeoJSON MultiPoint with additional 'coordRefSys' member",
"type": "object",
"required": ["type", "coordinates"],
"properties": {
"type": {
"type": "string",
"enum": ["MultiPoint"]
},
"coordRefSys": {
"$ref": "coordrefsys.json"
},
"coordinates": {
"type": "array",
"items": {
"$ref": "#/$defs/position"
}
},
"bbox": {
"$ref": "#/$defs/bbox"
}
}
},
"MultiLineString": {
"title": "GeoJSON MultiLineString with additional 'coordRefSys' member",
"type": "object",
"required": ["type", "coordinates"],
"properties": {
"type": {
"type": "string",
"enum": ["MultiLineString"]
},
"coordRefSys": {
"$ref": "coordrefsys.json"
},
"coordinates": {
"type": "array",
"items": {
"type": "array",
"minItems": 2,
"items": {
"$ref": "#/$defs/position"
}
}
},
"bbox": {
"$ref": "#/$defs/bbox"
}
}
},
"MultiPolygon": {
"title": "GeoJSON MultiPolygon with additional 'coordRefSys' member",
"type": "object",
"required": ["type", "coordinates"],
"properties": {
"type": {
"type": "string",
"enum": ["MultiPolygon"]
},
"coordRefSys": {
"$ref": "coordrefsys.json"
},
"coordinates": {
"type": "array",
"items": {
"type": "array",
"items": {
"type": "array",
"minItems": 4,
"items": {
"$ref": "#/$defs/position"
}
}
}
},
"bbox": {
"$ref": "#/$defs/bbox"
}
}
},
"Polyhedron": {
"title": "JSON-FG Polyhedron",
"type": "object",
"required": ["type", "coordinates"],
"properties": {
"type": {
"type": "string",
"enum": ["Polyhedron"]
},
"coordRefSys": {
"$ref": "coordrefsys.json"
},
"coordinates": {
"type": "array",
"minItems": 1,
"items": {
"type": "array",
"minItems": 1,
"items": {
"type": "array",
"minItems": 1,
"items": {
"type": "array",
"minItems": 4,
"items": {
"$ref": "#/$defs/position3d"
}
}
}
}
},
"bbox": {
"$ref": "#/$defs/bbox3d"
}
}
},
"MultiPolyhedron": {
"title": "JSON-FG MultiPolyhedron",
"type": "object",
"required": ["type", "coordinates"],
"properties": {
"type": {
"type": "string",
"enum": ["MultiPolyhedron"]
},
"coordRefSys": {
"$ref": "coordrefsys.json"
},
"coordinates": {
"type": "array",
"items": {
"type": "array",
"minItems": 1,
"items": {
"type": "array",
"minItems": 1,
"items": {
"type": "array",
"minItems": 1,
"items": {
"type": "array",
"minItems": 4,
"items": {
"$ref": "#/$defs/position3d"
}
}
}
}
}
},
"bbox": {
"$ref": "#/$defs/bbox3d"
}
}
},
"Prism": {
"title": "JSON-FG Prism",
"type": "object",
"required": ["type","base","upper"],
"properties": {
"type": {
"type": "string",
"enum": ["Prism"]
},
"coordRefSys": {
"$ref": "coordrefsys.json"
},
"base": {
"oneOf": [
{ "$ref": "#/$defs/Point" },
{ "$ref": "#/$defs/LineString" },
{ "$ref": "#/$defs/Polygon" },
{ "$ref": "#/$defs/MultiPoint" },
{ "$ref": "#/$defs/MultiLineString" },
{ "$ref": "#/$defs/MultiPolygon" }
]
},
"lower": {
"type": "number"
},
"upper": {
"type": "number"
},
"bbox": {
"$ref": "#/$defs/bbox3d"
}
}
},
"MultiPrism": {
"title": "JSON-FG Multi-Prism",
"type": "object",
"required": ["type","prisms"],
"properties": {
"type": {
"type": "string",
"enum": ["MultiPrism"]
},
"coordRefSys": {
"$ref": "coordrefsys.json"
},
"prisms": {
"type": "array",
"items": {
"$ref": "#/$defs/Prism"
}
},
"bbox": {
"$ref": "#/$defs/bbox3d"
}
}
},
"GeometryCollection": {
"title": "GeoJSON GeometryCollection with additional 'coordRefSys' member",
"type": "object",
"required": ["type", "geometries"],
"properties": {
"type": {
"type": "string",
"enum": ["GeometryCollection"]
},
"coordRefSys": {
"$ref": "coordrefsys.json"
},
"geometries": {
"type": "array",
"items": {
"oneOf": [
{
"$ref": "#/$defs/Point"
},
{
"$ref": "#/$defs/MultiPoint"
},
{
"$ref": "#/$defs/LineString"
},
{
"$ref": "#/$defs/MultiLineString"
},
{
"$ref": "#/$defs/Polygon"
},
{
"$ref": "#/$defs/MultiPolygon"
}
]
}
},
"bbox": {
"$ref": "#/$defs/bbox"
}
}
},
"position": {
"type": "array",
"minItems": 2,
"maxItems": 3,
"items": {
"type": "number"
}
},
"position3d": {
"type": "array",
"minItems": 3,
"maxItems": 3,
"items": {
"type": "number"
}
},
"bbox": {
"oneOf": [
{
"$ref": "#/$defs/bbox2d"
},
{
"$ref": "#/$defs/bbox3d"
}
]
},
"bbox2d": {
"type": "array",
"minItems": 4,
"maxItems": 4,
"items": {
"type": "number"
}
},
"bbox3d": {
"type": "array",
"minItems": 6,
"maxItems": 6,
"items": {
"type": "number"
}
}
}
}
B.9. JSON Schema of the "featureType" member
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://beta.schemas.opengis.net/json-fg/featuretype.json",
"title": "the featureType member",
"description": "This JSON Schema is part of JSON-FG version 0.2.2",
"oneOf": [
{
"type": "string"
},
{
"type": "array",
"items": {
"type": "string"
}
}
]
}
B.10. JSON Schema of the "featureSchema" member
1
2
3
4
5
6
7
8
9
10
11
12
13
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://beta.schemas.opengis.net/json-fg/featureschema.json",
"title": "the featureSchema member",
"description": "This JSON Schema is part of JSON-FG version 0.2.2",
"oneOf": [
{"type": "string", "format": "uri"},
{
"type": "object",
"additionalProperties": {"type": "string", "format": "uri"}
}
]
}
Annex C: Examples (Informative)
C.1. A building feature
The following feature instance is an example of a building feature that includes all new JSON-FG capabilities.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
{
"type": "Feature",
"id": "DENW19AL0000giv5BL",
"conformsTo": [
"[ogc-json-fg-1-0.2:core]" ,
"[ogc-json-fg-1-0.2:types-schemas]",
"[ogc-json-fg-1-0.2:3d]"
],
"featureType": "app:building",
"featureSchema": "https://example.org/data/v1/collections/buildings/schema",
"time": { "interval": ["2014-04-24T10:50:18Z", ".."] },
"coordRefSys": "http://www.opengis.net/def/crs/EPSG/0/5555",
"place": {
"type": "Polyhedron",
"coordinates": [
[
[
[
[479816.670, 5705861.672, 100],
[479822.187, 5705866.783, 100],
[479829.666, 5705858.785, 100],
[479824.155, 5705853.684, 100],
[479816.670, 5705861.672, 100]
]
],
[
[
[479816.670, 5705861.672, 110],
[479824.155, 5705853.684, 110],
[479829.666, 5705858.785, 120],
[479822.187, 5705866.783, 120],
[479816.670, 5705861.672, 110]
]
],
[
[
[479816.670, 5705861.672, 110],
[479816.670, 5705861.672, 100],
[479824.155, 5705853.684, 100],
[479824.155, 5705853.684, 110],
[479816.670, 5705861.672, 110]
]
],
[
[
[479824.155, 5705853.684, 110],
[479824.155, 5705853.684, 100],
[479829.666, 5705858.785, 100],
[479829.666, 5705858.785, 120],
[479824.155, 5705853.684, 110]
]
],
[
[
[479829.666, 5705858.785, 120],
[479829.666, 5705858.785, 100],
[479822.187, 5705866.783, 100],
[479822.187, 5705866.783, 120],
[479829.666, 5705858.785, 120]
]
],
[
[
[479822.187, 5705866.783, 120],
[479822.187, 5705866.783, 100],
[479816.670, 5705861.672, 100],
[479816.670, 5705861.672, 110],
[479822.187, 5705866.783, 120]
]
]
]
]
},
"geometry": {
"type": "Polygon",
"coordinates": [
[
[8.7092045, 51.5035285, 100],
[8.7093128, 51.5034570, 100],
[8.7093919, 51.5035030, 100],
[8.7092837, 51.5035747, 100],
[8.7092045, 51.5035285, 100]
]
]
},
"links": [
{
"href": "https://example.org/data/v1/collections/cadastralparcel/items/05297001600313______",
"rel": "http://www.opengis.net/def/rel/ogc/1.0/within",
"title": "Cadastral parcel 313 in district Wünnenberg (016)"
},
{
"href" : "https://inspire.ec.europa.eu/featureconcept/Building",
"rel" : "type" ,
"title": "This feature is of type 'building'"
}
],
"properties": {
"lastChange": "2014-04-24T10:50:18Z",
"built": "2012-03",
"function": "Agricultural building",
"height_m": 20.0,
"owners": [
{"href": "https://example.org/john-doe", "title": "John Doe"},
{"href": "https://example.org/jane-doe", "title": "Jane Doe"}
]
}
}
C.2. Simple prism geometries
The following are simple examples of prism geometries.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
{
"type": "Feature",
"id": "pylon.1",
"conformsTo" : [ "[ogc-json-fg-1-0.2:core]", "[ogc-json-fg-1-0.2:3d]" ],
"featureType": "pylon",
"time": {
"interval": [
"2022-07-12T16:47:18Z",
".."
]
},
"geometry": null,
"coordRefSys": "http://www.opengis.net/def/crs/EPSG/0/7415",
"place": {
"type": "Prism",
"base": {
"type": "Point",
"coordinates": [
81220.15,
455113.71
]
},
"lower": 2.02,
"upper": 8.02
},
"properties": null
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
{
"type": "Feature",
"id": "fence.1",
"conformsTo" : [ "[ogc-json-fg-1-0.2:core]", "[ogc-json-fg-1-0.2:3d]" ],
"featureType": "fence",
"time": {
"interval": [
"2022-07-12T16:55:18Z",
".."
]
},
"geometry": null,
"coordRefSys": "http://www.opengis.net/def/crs/EPSG/0/7415",
"place": {
"type": "Prism",
"base": {
"type": "LineString",
"coordinates": [
[
81220.15,
455113.71
],
[
81223.15,
455116.71
]
]
},
"lower": 2.02,
"upper": 3.22
},
"properties": null
}
C.3. Toronto City Hall
The following object is a feature representing the Toronto City Hall with the geometry as a MultiPrism (extruded polygons).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
{
"type": "Feature",
"id": "CWFID.Toronto3D.0.177482",
"bbox": [-79.384481,43.653199,90.848,-79.383449,43.653866,190.348],
"conformsTo" : [ "[ogc-json-fg-1-0.2:core]", "[ogc-json-fg-1-0.2:3d]" ],
"time": null,
"geometry": null,
"coordRefSys": "http://www.opengis.net/def/crs/OGC/0/CRS84h",
"place": {
"type": "MultiPrism",
"prisms": [
{
"type": "Prism",
"base": {
"type": "Polygon",
"coordinates": [ [
[ -79.38420744, 43.65327075 ], [ -79.38426426, 43.65334167 ],
[ -79.38426868, 43.65334677 ], [ -79.38427927, 43.65336015 ],
[ -79.38428875, 43.65337394 ], [ -79.38429712, 43.65338812 ],
[ -79.38430433, 43.65340262 ], [ -79.38431036, 43.65341741 ],
[ -79.3843152, 43.65343242 ], [ -79.38431883, 43.65344762 ],
[ -79.38432123, 43.65346294 ], [ -79.3843224, 43.65347834 ],
[ -79.38432233, 43.65349376 ], [ -79.38432102, 43.65350915 ],
[ -79.38431948, 43.6535188 ], [ -79.38431595, 43.65353474 ],
[ -79.3843112, 43.65355051 ], [ -79.38430524, 43.65356607 ],
[ -79.3842981, 43.65358135 ], [ -79.3842898, 43.65359633 ],
[ -79.38428036, 43.65361094 ], [ -79.38426981, 43.65362515 ],
[ -79.38425819, 43.65363892 ], [ -79.38424553, 43.65365219 ],
[ -79.38423187, 43.65366492 ], [ -79.38421725, 43.65367709 ],
[ -79.38417654, 43.65371806 ], [ -79.38420552, 43.65373513 ],
[ -79.38418786, 43.65375189 ], [ -79.38421657, 43.65378312 ],
[ -79.38421681, 43.65378352 ], [ -79.38421977, 43.6537872 ],
[ -79.38422373, 43.65379035 ], [ -79.38422563, 43.6537915 ],
[ -79.38422976, 43.6537931 ], [ -79.38423433, 43.65379387 ],
[ -79.38423901, 43.65379374 ], [ -79.38424349, 43.65379273 ],
[ -79.38424744, 43.65379091 ], [ -79.38425571, 43.65378517 ],
[ -79.38427731, 43.65376936 ], [ -79.38429803, 43.65375295 ],
[ -79.38430275, 43.65374947 ], [ -79.38432397, 43.653733 ],
[ -79.38434429, 43.65371593 ], [ -79.38436365, 43.6536983 ],
[ -79.38438204, 43.65368012 ], [ -79.38439942, 43.65366142 ],
[ -79.38441576, 43.65364224 ], [ -79.38443105, 43.65362261 ],
[ -79.38444525, 43.65360255 ], [ -79.38445834, 43.6535821 ],
[ -79.38446164, 43.65357546 ], [ -79.38446789, 43.65356096 ],
[ -79.38447295, 43.65354621 ], [ -79.3844768, 43.65353127 ],
[ -79.38447942, 43.65351619 ], [ -79.38448082, 43.65350103 ],
[ -79.38448097, 43.65348583 ], [ -79.38447989, 43.65347065 ],
[ -79.38447757, 43.65345554 ], [ -79.38447403, 43.65344056 ],
[ -79.38446927, 43.65342576 ], [ -79.38446331, 43.65341119 ],
[ -79.38445913, 43.65340284 ], [ -79.38444852, 43.65338352 ],
[ -79.38443676, 43.65336456 ], [ -79.38442389, 43.65334598 ],
[ -79.38440993, 43.65332782 ], [ -79.3843949, 43.65331011 ],
[ -79.38437883, 43.65329289 ], [ -79.38429148, 43.65320376 ],
[ -79.38428751, 43.6532014 ], [ -79.38428284, 43.65319977 ],
[ -79.38427777, 43.65319898 ], [ -79.3842726, 43.65319909 ],
[ -79.38426761, 43.65320009 ], [ -79.38426308, 43.65320192 ],
[ -79.38425928, 43.65320447 ], [ -79.38422428, 43.6532376 ],
[ -79.38423947, 43.65325843 ], [ -79.38420744, 43.65327075 ] ] ]
},
"lower": 90.848,
"upper": 170.248
},
{
"type": "Prism",
"base": {
"type": "Polygon",
"coordinates": [ [
[ -79.38425596, 43.65347139], [ -79.38425407, 43.65345755],
[ -79.38425095, 43.65344382], [ -79.3842466, 43.65343028],
[ -79.38424107, 43.65341696], [ -79.38423436, 43.65340393],
[ -79.38422651, 43.65339124], [ -79.38421754, 43.65337895],
[ -79.38420749, 43.6533671], [ -79.38419641, 43.65335576],
[ -79.38418435, 43.65334495], [ -79.38417134, 43.65333473],
[ -79.38415745, 43.65332515], [ -79.38415032, 43.65332085],
[ -79.38413487, 43.65331243], [ -79.38411871, 43.65330474],
[ -79.38410191, 43.65329781], [ -79.38408454, 43.65329169],
[ -79.38406665, 43.65328639], [ -79.38404834, 43.65328193],
[ -79.38402966, 43.65327833], [ -79.38401072, 43.65327561],
[ -79.38399156, 43.65327377], [ -79.38397229, 43.65327284],
[ -79.38395297, 43.6532728], [ -79.38393369, 43.65327366],
[ -79.38391453, 43.65327542], [ -79.38389555, 43.65327806],
[ -79.38387686, 43.65328158], [ -79.38385851, 43.65328597],
[ -79.38384059, 43.6532912], [ -79.38382316, 43.65329726],
[ -79.38377823, 43.65331886], [ -79.38377272, 43.65332226],
[ -79.38375815, 43.65333206], [ -79.38374445, 43.6533425],
[ -79.38373217, 43.65335314], [ -79.38372086, 43.65336434],
[ -79.38371058, 43.65337604], [ -79.38370136, 43.6533882],
[ -79.38369325, 43.65340077], [ -79.38368627, 43.65341369],
[ -79.38368046, 43.65342692], [ -79.38367585, 43.65344039],
[ -79.38367245, 43.65345405], [ -79.38367027, 43.65346784],
[ -79.38366933, 43.65348171], [ -79.38366963, 43.65349559],
[ -79.38367117, 43.65350943], [ -79.38367394, 43.65352316],
[ -79.38367793, 43.65353674], [ -79.38368312, 43.6535501],
[ -79.38368949, 43.65356319], [ -79.38369702, 43.65357595],
[ -79.38370567, 43.65358833], [ -79.38371541, 43.65360028],
[ -79.38372619, 43.65361174], [ -79.38373797, 43.65362268],
[ -79.38375071, 43.65363304], [ -79.38376434, 43.65364277],
[ -79.38377882, 43.65365185], [ -79.38379407, 43.65366022],
[ -79.38381004, 43.65366786], [ -79.38382665, 43.65367473],
[ -79.38384384, 43.65368081], [ -79.38386154, 43.65368607],
[ -79.38387968, 43.65369048], [ -79.38389816, 43.65369403],
[ -79.38391693, 43.6536967], [ -79.3839359, 43.65369849],
[ -79.38395498, 43.65369938], [ -79.3839741, 43.65369937],
[ -79.38399318, 43.65369846], [ -79.38401214, 43.65369666],
[ -79.3840309, 43.65369396], [ -79.38404938, 43.65369039],
[ -79.3840675, 43.65368596], [ -79.38408519, 43.65368069],
[ -79.38409529, 43.65367711], [ -79.38411206, 43.65367038],
[ -79.3841282, 43.65366288], [ -79.38414363, 43.65365464],
[ -79.38415829, 43.65364569], [ -79.38417213, 43.65363606],
[ -79.38418508, 43.65362582], [ -79.38419709, 43.65361498],
[ -79.38420811, 43.6536036], [ -79.3842181, 43.65359173],
[ -79.384227, 43.65357941], [ -79.38423479, 43.65356671],
[ -79.38424143, 43.65355366], [ -79.3842469, 43.65354033],
[ -79.38425116, 43.65352677], [ -79.38425421, 43.65351304],
[ -79.38425603, 43.65349919], [ -79.38425662, 43.65348529],
[ -79.38425596, 43.65347139] ] ]
},
"lower": 90.848,
"upper": 110.443
},
{
"type": "Prism",
"base": {
"type": "Polygon",
"coordinates": [ [
[ -79.38359865, 43.65342466 ], [ -79.38360028, 43.65340244 ],
[ -79.38360314, 43.65338028 ], [ -79.38361027, 43.65333574 ],
[ -79.38357134, 43.6533332 ], [ -79.38357522, 43.65331185 ],
[ -79.38352233, 43.65329164 ], [ -79.38352003, 43.65329026 ],
[ -79.38351644, 43.65328911 ], [ -79.38351253, 43.65328884 ],
[ -79.38350869, 43.65328945 ], [ -79.3835053, 43.6532909 ],
[ -79.3835037, 43.65329218 ], [ -79.38349774, 43.65329778 ],
[ -79.38349274, 43.65330386 ], [ -79.38348879, 43.65331035 ],
[ -79.38348459, 43.65332514 ], [ -79.38347433, 43.65336425 ],
[ -79.3834653, 43.65340352 ], [ -79.38345749, 43.65344293 ],
[ -79.3834509, 43.65348245 ], [ -79.38344964, 43.65349816 ],
[ -79.38344911, 43.65351849 ], [ -79.38344982, 43.65353881 ],
[ -79.38345176, 43.65355909 ], [ -79.38345495, 43.65357929 ],
[ -79.38345936, 43.65359937 ], [ -79.38346498, 43.65361929 ],
[ -79.38347182, 43.653639 ], [ -79.38347233, 43.65364019 ],
[ -79.38347929, 43.6536548 ], [ -79.38348742, 43.65366908 ],
[ -79.38349667, 43.653683 ], [ -79.38350702, 43.65369651 ],
[ -79.38351844, 43.65370955 ], [ -79.38353088, 43.65372209 ],
[ -79.3835443, 43.65373409 ], [ -79.38355866, 43.65374549 ],
[ -79.38357392, 43.65375627 ], [ -79.38357791, 43.65375872 ],
[ -79.38359719, 43.65376982 ], [ -79.38361722, 43.6537802 ],
[ -79.38363794, 43.65378983 ], [ -79.3836593, 43.6537987 ],
[ -79.38368125, 43.65380677 ], [ -79.38370373, 43.65381403 ],
[ -79.38372669, 43.65382046 ], [ -79.38375006, 43.65382605 ],
[ -79.38376671, 43.65383005 ], [ -79.38380024, 43.65383742 ],
[ -79.38383412, 43.65384392 ], [ -79.38386829, 43.65384954 ],
[ -79.38390271, 43.65385428 ], [ -79.38393734, 43.65385814 ],
[ -79.38397213, 43.65386111 ], [ -79.38400705, 43.65386317 ],
[ -79.38406372, 43.65386581 ], [ -79.38406875, 43.65386502 ],
[ -79.38407338, 43.65386338 ], [ -79.38407734, 43.65386098 ],
[ -79.3840804, 43.65385798 ], [ -79.3840824, 43.65385452 ],
[ -79.38408321, 43.65385082 ], [ -79.38408279, 43.65384708 ],
[ -79.38407132, 43.65380444 ], [ -79.38404493, 43.65379985 ],
[ -79.38405299, 43.65377541 ], [ -79.3839733, 43.65376425 ],
[ -79.38395719, 43.65376204 ], [ -79.38393186, 43.65375781 ],
[ -79.38390684, 43.65375271 ], [ -79.38388219, 43.65374674 ],
[ -79.38385795, 43.65373994 ], [ -79.38383418, 43.65373229 ],
[ -79.38381095, 43.65372384 ], [ -79.3837883, 43.65371459 ],
[ -79.38376628, 43.65370457 ], [ -79.38374494, 43.6536938 ],
[ -79.38373894, 43.65369035 ], [ -79.3837226, 43.65368021 ],
[ -79.38370709, 43.6536694 ], [ -79.38369246, 43.65365795 ],
[ -79.38367876, 43.65364592 ], [ -79.38366605, 43.65363333 ],
[ -79.38365435, 43.65362023 ], [ -79.38364371, 43.65360666 ],
[ -79.38363417, 43.65359267 ], [ -79.38362576, 43.6535783 ],
[ -79.38361849, 43.65356361 ], [ -79.38361241, 43.65354864 ],
[ -79.38360908, 43.65353548 ], [ -79.38360453, 43.65351348 ],
[ -79.38360121, 43.65349135 ], [ -79.38359912, 43.65346915 ],
[ -79.38359826, 43.65344691 ], [ -79.38359865, 43.65342466 ] ]
]
},
"lower": 90.848,
"upper": 190.348
}
]
},
"properties": {
"common_name": "Toronto City Hall",
"address": "100 Queen St. West",
"perimeter": 497.009462084,
"poly_area": 3553.573425347
}
}
C.4. Cologne Cathedral
The file cologne-cathedral.json is a JSON-FG feature collection that contains a CityGML building feature with 87 building part features representing the Cologne Cathedral in Level of Detail 2. Each building part has a Polyhedron geometry. The building part feature also contain additional geometries in the "properties" section. Due to the size of the example, it is not embedded, but referenced.
C.5. A homogeneous feature collection
The following feature collection consists of airport features from the Zoomstack dataset of Ordnance Survey Great Britain. All features have the same feature type ("Airport") with a point geometry (geometry dimension: 0).
The feature collection has been reduced to the first two and the last feature to reduce the size of the example.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
{
"type": "FeatureCollection",
"conformsTo" : [ "[ogc-json-fg-1-0.2:core]", "[ogc-json-fg-1-0.2:types-schemas]" ],
"coordRefSys": "http://www.opengis.net/def/crs/EPSG/0/27700",
"featureType": "Airport",
"featureSchema": "https://demo.ldproxy.net/zoomstack/collections/airports/schema",
"geometryDimension": 0,
"features": [
{
"type": "Feature",
"id": 1,
"geometry": { "type": "Point", "coordinates": [-1.6930015, 60.3216821] },
"properties": {"name": "Papa Stour Airstrip"},
"place": { "type": "Point", "coordinates": [417057.93, 1159772.2] },
"time": null
},
{
"type": "Feature",
"id": 2,
"geometry": { "type": "Point", "coordinates": [-1.2922268, 59.8782666] },
"properties": {"name": "Sumburgh Airport"},
"place": { "type": "Point", "coordinates": [439723.69, 1110559.95] },
"time": null
},
{
"type": "Feature",
"id": 46,
"geometry": { "type": "Point", "coordinates": [0.9384272, 50.9556174] },
"properties": {"name": "Lydd Airport"},
"place": { "type": "Point", "coordinates": [606468.75, 121465.11] },
"time": null
}
]
}
C.6. Extending JSON-FG
This section illustrates how JSON-FG can be extended with
-
new geometry types Arc and Circle;
-
a new temporal data type for a time series;
-
the capability to provide a coordinate reference system definition as a PROJJSON object.
If the extension would be specified in a hypothetical part 2 of JSON-FG, the extension could update the JSON Schema definitions as described in the following sub-sections.
If the same extensions are specified by a community, they would copy the relevant JSON-FG schemas and extend them as described in the sub-sections. Unchanged schemas like the JSON Schemas for the "geometry" and "featureType" members or for a link do not need to be copied and can reference the JSON-FG schemas.
C.6.1. Geometry types Arc and Circle
The schema definition for the new geometry objects "Arc" and "Circle" shown below could be added as #/$defs/Arc
and #/$defs/Circle
in the JSON Schema of geometry objects ("geometry-objects.json").
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
"title": "Arc",
"description": "A circular arc by three points. The arc starts at the first position, passes through the second position and ends at the third position.",
"type": "object",
"required": ["type", "coordinates"],
"properties": {
"type": { "type": "string", "enum": ["Arc"] },
"coordinates": {
"type": "array",
"minItems": 3,
"maxItems": 3,
"items": {"$ref": "#/$defs/position"}
},
"bbox": {"$ref": "#/$defs/bbox"}
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
"title": "Circle",
"description": "A closed circular arc, where the first and the last position are identical. The circle starts at the first position, passes through the second and third position and ends at the fourth position, which is the same as the first position.",
"type": "object",
"required": ["type", "coordinates"],
"properties": {
"type": { "type": "string", "enum": ["Circle"] },
"coordinates": {
"type": "array",
"minItems": 4,
"maxItems": 4,
"items": {"$ref": "#/$defs/position"}
},
"bbox": {"$ref": "#/$defs/bbox"}
}
}
"Arc" and "Circle" would also be added to #/$defs/CustomGeometry/properties/type/not/enum
to declare the two new JSON-FG geometry types.
C.6.2. A temporal data type for a time series;
The schema definition for the time series object shown below could be added as #/$defs/timeSeries
in the JSON Schema of the "time" member.
1
2
3
4
5
6
7
8
{
"type": "array",
"minItems": 1,
"items": {
"type": "string",
"format": "date-time"
}
}
The following member would then be added to #/oneOf/1/properties
.
1
2
3
"timeSeries": {
"$ref": "#/$defs/timeSeries"
}
C.6.3. Coordinate reference system as PROJJSON
The schema definition for the by-value CRS object shown below could be added as #/$defs/refsys-byvalue
in the JSON Schema of the "coordRefSys" member.
1
2
3
4
5
6
7
8
9
{
"type": "object",
"required": ["valueType", "value"],
"properties": {
"type": { "type": "string", "enum": ["PROJJSON"] },
"value": {"$ref": "https://proj.org/schemas/v0.4/projjson.schema.json#/definitions/crs"},
"epoch": {"type": "string"}
}
}
"PROJJSON" would also be added to #/$defs/refsys-custom/properties/type/not/enum
and { "$ref": "#/$defs/refsys-byvalue" }
would be added to #/$defs/single-refsys/oneOf
.
Annex D: Links (Informative)
Note
|
This annex may be removed from the document before publication. |
There are multiple ways how to encode feature properties that are relationships with other features or resources like codelists and where the value is not embedded, but represented as a link. This annex discusses the topic.
D.1. A sample feature
In this annex a cadastral parcel feature is used as the sample feature resource. The hypothetical parcel has the following properties:
-
a (multi-)polygon geometry (ignored in the JSON examples to keep the examples short);
-
a parcel identifier ("foo");
-
its area (2000 square meters);
-
a set of ownership records (two owners, each with 50% share);
-
a set of buildings on the parcel (one building on the parcel);
-
information about land use (using a national classification system) and the area for each applicable land use type (500 square meters with residential use, 1500 square meters with commercial use).
The owners, buildings and land use types are web resources, too, and have URIs as identifiers.
D.2. Scope discussion
The related resources can be referenced or embedded in the feature representation (embedding is only sensible, if the resource can be represented as a JSON object). This proposal only discusses the case where a related resource is referenced and where the related resources are web resources, i.e. resources that are identified by HTTP(S) URIs. If resources are embedded, they will be embedded as a value in a member in the "properties" object.
Relationships will often be direct properties of the feature, but they may also occur in embedded JSON objects.
Like all other properties, properties that are relationships may have a maximum multiplicity greater than one. That is, the JSON representation may be an array of relationships.
A GeoJSON feature that is encoded by a Web API implementing OGC API standards will often already include a "links" member with an array of OGC API Link objects. The OGC API Link object is a JSON implementation of web links according to RFC 8288. As discussed above, the OGC API Features standard currently only specifies requirements for links to resources in the API to support clients navigating the API.
D.3. Patterns
Three patterns for representing relationships with other features or resources are discussed below. They all address different use cases.
D.3.1. Pattern 1: Add all relationships to a "links" member of the JSON object that is the link anchor
This pattern is consistent with the general approach in the OGC API standards. It uses Web linking and a consistently named JSON member with an array of OGC API Link objects.
The semantics of the relationship / association role is expressed via the link relation type. Where possible, link relation types registered with IANA or OGC should be used, but the data publisher can also define their own link relation types. Note that this introduces overhead, because it requires minting persistent URIs for the link relation types. Where this is too much, an existing link relation type should be used and "related" could be used as a fallback.
Note that the examples use Safe CURIEs for better readability in cases where the link relation type is a URI.
The parcel feature could look like the following example, which uses the "anchor" link attribute to specify the link context. The building relationship has been mapped to a hypothetical "http://www.opengis.net/def/rel/ogc/1.0/contains" link relationship based on the topological relationship "contains" from the Simple Features standard.
Note
|
Link relation types for the topological interval relationships as specified in OWL Time are already registered with IANA. The registration of the named spatial topological relationships specified in the Simple Feature Access standard could be considered, either in the IANA or the OGC register. Such link relation types are useful for cases where relationships are pre-computed or are computed on the fly but are presented, because the clients cannot easily compute them. |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
{
"type":"Feature",
"geometry": null,
"links" : [ {
"title" : "123 Main St., Atlantis",
"href" : "https://example.com/building/123",
"rel" : "[ogc:contains]"
}, {
"anchor": "#/properties/owners/0",
"href": "https://example.com/person/foo",
"title": "John Doe",
"rel": "[app:owner]"
}, {
"anchor": "#/properties/owners/1",
"href": "https://example.com/company/bar",
"title": "Acme Inc",
"rel": "[app:owner]"
}, {
"anchor": "#/properties/landUse/0",
"href": "https://example.com/landuse/residential",
"title": "residential use",
"rel": "[app:land-use]"
}, {
"anchor": "#/properties/landUse/1",
"href": "https://example.com/landuse/commercial",
"title": "commercial use",
"rel": "[app:land-use]"
} ],
"properties": {
"registerId": "foo",
"area_m2": 2000,
"owners": [
{ "share_%": 50 },
{ "share_%": 50 }
],
"use": [
{ "area_m2": 500 },
{ "area_m2": 1500 }
]
}
}
A variation of this approach would be to separate the API navigation links ("links") from the feature properties and place those links in another member (e.g. "associations").
Another variation would be to not use anchors, but specify the links in JSON object that is the link context:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
{
"type":"Feature",
"geometry": null,
"links" : [ {
"rel" : "[contains]",
"title" : "123 Main St., Atlantis",
"href" : "https://example.com/building/123"
} ],
"properties": {
"registerId": "foo",
"area_m2": 2000,
"owners": [ {
"share_%": 50,
"links": [ {
"href": "https://example.com/person/foo",
"title": "John Doe",
"rel": "[app:owner]"
} ],
}, {
"share_%": 50,
"links": [ {
"href": "https://example.com/company/bar",
"title": "Acme Inc",
"rel": "[app:owner]"
} ],
} ],
"use": [ {
"area_m2": 500,
"links": [ {
"href": "https://example.com/landuse/residential",
"title": "residential use",
"rel": "[app:land-use]"
} ]
}, {
"area_m2": 1500,
"links": [ {
"href": "https://example.com/landuse/commercial",
"title": "commercial use",
"rel": "[app:land-use]"
} ]
} ]
}
}
D.3.2. Pattern 2: Encode links like other feature properties - using a link object
This pattern treats the relationships like other properties and uses a simplified OGC API Link object without a "rel" attribute, since the semantics of the link is already expressed by the property.
A variation could be to require the use of a valid link relation type as the key of the JSON member, which would basically move the link relation type to a key to group all links with the same link relation type.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
{
"type":"Feature",
"geometry": null,
"properties": {
"registerId": "foo",
"area_m2": 2000,
"buildings": [ {
"title" : "123 Main St., Atlantis",
"href" : "https://example.com/building/123"
} ],
"owners": [ {
"share_%": 50,
"owner": {
"href": "https://example.com/person/foo",
"title": "John Doe"
}
}, {
"share_%": 50,
"owner": {
"href": "https://example.com/company/bar",
"title": "Acme Inc"
}
} ],
"use": [ {
"area_m2": 500,
"landUse": {
"href": "https://example.com/landuse/residential",
"title": "residential use"
}
}, {
"area_m2": 1500,
"landUse": {
"href": "https://example.com/landuse/commercial",
"title": "commercial use"
}
} ]
}
}
A variation of this pattern would be to flatten the link objects. I.e., instead of
1
2
3
4
"owner": {
"href": "https://example.com/company/bar",
"title": "Acme Inc"
}
the link could be encoded as
1
2
"owner.href": "https://example.com/company/bar",
"owner.title": "Acme Inc"
D.3.3. Pattern 3: Only use the URI
This pattern is similar to pattern 2, but the link objects are reduced to the href value. As a result, this approach is more concise, but it lacks information that would be useful for the human (unless the URIs are dereferenced to fetch a label/title). In addition, since this approach does not use web linking according to RFC 8288, no link relation types for the links are available.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
{
"type":"Feature",
"geometry": null,
"properties": {
"registerId": "foo",
"area_m2": 2000,
"buildings": [
"https://example.com/building/123"
],
"owners": [ {
"share_%": 50,
"owner": "https://example.com/person/foo"
}, {
"share_%": 50,
"owner": "https://example.com/company/bar"
} ],
"use": [ {
"area_m2": 500,
"landUse": "https://example.com/landuse/residential"
}, {
"area_m2": 1500,
"landUse": "https://example.com/landuse/commercial"
} ]
}
}
D.4. Summary
Pattern 1 seems best suited, if the intended use of the data benefits from a consistent place where links are included in the JSON document.
Pattern 2 seems best suited, if the JSON features should closely reflect the application schema of the features (in case a schema is available).
The same also applies to pattern 3, but pattern 3 seems mainly useful in combination with JSON-LD. Also, the information is not sufficient to render a useful HTML representation from the JSON representation without fetching the linked resources.
Depending on the data and how the data is expected to be used, the preferences of data publishers for one or the other patterns will vary.
Annex E: Considerations (Informative)
Note
|
This is a temporary annex developed during the development of the document that will be removed from the document before publication. |
This annex includes considerations for each of the JSON-FG building blocks.
E.1. Primary temporal information ("time")
The following aspects were discussed:
-
The current specification of the "time" member could be extended with minimal extensions beyond the RFC 3339 timestamps to support additional use cases, but this would be left to a future extension:
-
Supporting instant values of a year (e.g., "1969") or a month (e.g., "1967-07") in addition to dates and timestamps could be useful for extents that cover a complete month or year.
-
Supporting instant values of the proleptic Gregorian calendar (i.e., dates before 1582 including negative years) could be useful for historic information.
-
-
An alternative interval encoding would be to use ISO 8601-1/8601-2 and represent intervals as a string, too, instead of an array. In this case, the value of "interval" would be encoded as:
-
"1969-07-16/1969-07-24"
-
"1969-07-16T05:32:00Z/1969-07-24T16:50:35Z"
-
"2019-10-14/.."
The main reason for the current design is that this is easier to parse. In a structured language like JSON it is natural to be explicit and use the structures. For example, GeoJSON does not represent the geometry as a Well-Known Text (WKT) string, but as a JSON structure. The JSON encoding of the candidate OGC Common Query Language (CQL2) Standard also follows that approach for spatial and temporal literals.
Another reason for the current design is that an object-based approach can support additional temporal types in the future besides instants and intervals. An example is a time series with an array of timestamps.
-
-
The current proposal only specifies the use of "time" in the context of a feature. Other contexts could also be supported in the future. For example, temporal information for each geometry in a geometry collection, for properties where the value changes over time or a summary information in the feature collection.
-
The SpatioTemporal Asset Catalog (STAC) specification defines a property datetime that is included in the "properties" member. This approach was not followed for two reasons:
-
Like the feature identifier and the primary geometry of a feature, the primary temporal information of a feature should be a "first-class" citizen in the JSON encoding of the feature.
-
The use of reserved property names might conflict with existing features that include a "datetime" property with a different specification.
-
-
Currently there is no information about the semantics of the temporal information. Is it the validity in time of a feature that is a version of a real-world entity and there are potential predecessor/successors features of the same entity? Or, in case of a bitemporal dataset, is it the valid time or the transaction/record time? Etc. One potential approach could be the use of a JSON-LD context to associate the "time" member with a property definition in a vocabulary. It was decided to keep the JSON-FG core simple and leave support for more complex requirements to extensions. Support for versioned feature data is one of the planned future work items of the Features API SWG.
-
There is an existing initiative for a temporal GeoJSON extension ("GeoJSON-T"). The GeoJSON-T design supports more complex use cases that go beyond the scope of the proposal. To avoid confusion, the SWG is using a different key ("time").
E.2. Primary geometry ("place", "coordRefSys", "geometry")
The following aspects were discussed:
-
JSON-FG will not support multiple geometries per feature (note that multiple geometries can be included inside the "properties" member) or any hints about the semantics of the geometry. The latter could potentially be addressed using JSON-LD contexts where this is important.
-
During the November 2021 OGC Code Sprint, the participants also tested JSON-FG data with draft OGC API Features building blocks to access feature data suitable for display at a certain map scale / zoom level. This included API building blocks for simplifying geometries that are not points as well as filtering features that are typically not shown in maps at the scale or zoom level. This was validated with multiple implementations (a JSON-FG client and three OGC API Features servers).
E.3. Feature type ("featureType")
The following aspects were discussed:
-
Initial experiments used JSON-LD
@type
member to identify the feature type(s) of the feature. This approach, however, was changed to the current approach for the following reasons:-
In many cases, feature types are specified by communities or data publishers without a persistent URI.
-
There is demand for feature type tokens that can be processed and filtered with simple string comparisons, with URI expansions.
-
While JSON-FG can be used with additional JSON-LD annotations, it is a design goal to avoid normative dependencies on JSON-LD.
If JSON-LD is used, the "featureType" member can be mapped to "@type".
-
-
This approach is similar to the approach taken by OGC API Records to identify the type of a record.
-
In a JSON-FG extension to OGC API Features (or maybe in the new part "Schemas"), the Collection resources should be extended to include (optional) information about the feature types and geometry types included in the collection. There could be a recommendation for "featureType" and "geometryDimension" as queryables for such collections.
E.4. Feature Schemas ("featureSchema")
The following aspects were discussed:
-
Originally the schema was meant for validation of JSON-FG documents. However, consistent with discussions in the context of OGC API Features, the primary value of a feature schema is not validation, but information about the properties of a feature. Since the same feature will be encoded differently in GeoJSON and JSON-FG (e.g., the same property may be represented in the "properties" member in GeoJSON, but in a "time" member in JSON-FG) instead of having different feature schemas for GeoJSON and JSON-FG, a single JSON Schema describing the logical feature schema with additional annotations to specify the mapping to GeoJSON and JSON-FG was considered more valuable for clients.
-
The JSON Schemas specified for GeoJSON and JSON-FG can be used to validate instance documents against the general requirements of the standards. These schema, however, will not validate the contents of the "properties" member.
E.5. Links
The following aspects were discussed:
-
A GeoJSON feature that is encoded by a Web API implementing OGC API standards will often already include a "links" member with an array of OGC API Link objects. The OGC API Link object is a JSON implementation of web links according to RFC 8288. The OGC API Features standard currently only specifies requirements for links to resources in the API to support clients navigating the API.
-
Are links part of the resource or metainformation? There is a general, somewhat philosophical discussion topic related to links between resources.
In general, the links of a web resource are considered metainformation, and strictly the links do not have to be part of the cachable representations of the resource. RFC 8288 (Web linking) supports this by supporting that links are only represented as HTTP headers, outside of the representations. Changes to a link would not impact the ETag or Last-Modified headers of the resource.
The links in feature (collection) resources specified in OGC API Features ("self", "alternate", "next", "collection") or in JSON Schema ("describedby") are a good example. A change in any of those links does not indicate a change in the resource itself, but it indicates a technical change in the implementation. For example, another alternate representation has been added or the schema has moved to a different URI.
However, because the OGC API standards include the links in the JSON representation - like most of the existing approaches to JSON-based Web APIs, a change in the links will also invalidate cached representations of the resource (and update the ETag and Last-Modified headers). A conscious decision is to include the links in the JSON representation. This approach seems to meet the expectations of developers today.
The same applies to many of the explicit or implicit relationships that are expressed in geospatial datasets today. Whether a second building is erected on the parcel or not does not really change the parcel. It could be argued that the relationship between the parcel and the building is metainformation and a change to a relation does not change the parcel - and should not invalidate any cached representations. Links between the resources could be managed - and accessed - as separate resources (e.g. linksets).
Nevertheless, many users and developers will prefer a more "traditional" way of sharing geospatial features with relationships included in the resource representation and the discussion below is based on this assumption.
-
An extension to CQL2 to properly support filtering links should be considered by the Features API SWG.
Annex F: Revision History
Date | Release | Editor | Primary clauses modified | Description |
---|---|---|---|---|
2022-01-07 |
0.0 |
C. Portele |
all |
initial version |
2022-08-08 |
0.1 |
C. Portele, P. Vretanos |
all |
first draft release |
2022-09-19 |
0.1.1 |
C. Portele |
Annex B, Annex C |
#65: correct examples, use pattern for date/time validation, reorganize example files |
2023-10-10 |
0.2 |
C. Portele, P. Vretanos |
all |
second draft release; for submission to the OGC Architecture Board for review |
2023-10-25 |
0.2.1 |
C. Portele |
all |
address comments from OGC Architecture Board review; add link to draft of OGC API Features Part 5: Schemas |
2024-02-20 |
0.2.2 |
C. Portele |
all |
address comments from OGC October 2023 Code Sprint; upgrade to new CRSs registered by the OGC Naming Authority |
Annex G: Bibliography
Internet Engineering Task Force (IETF). RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format. Edited by T. Bray. 2017. Available at https://www.rfc-editor.org/rfc/rfc8259.html
JSON Schema: A Media Type for Describing JSON Documents. Edited by A. Wright, H. Andrews, B. Hutton, G. Dennis. 2022. Available at https://json-schema.org/draft/2020-12/json-schema-core
JSON Schema Validation: A Vocabulary for Structural Validation of JSON. Edited by A. Wright, H. Andrews, B. Hutton. 2022. Available at https://json-schema.org/draft/2020-12/json-schema-validation
Open Geospatial Consortium (OGC). OGC 18-005r4: OGC Abstract Specification Topic 2: Referencing by coordinates. Edited by R. Lott. 2019. Available at https://docs.ogc.org/as/18-005r4/18-005r4.html
Open Geospatial Consortium (OGC). OGC 20-070: Geographic information - Features and geometry — Part 2: Metrics. Edited by J. Herring. 2019. Available at https://portal.ogc.org/files/?artifact_id=94178 (access requires OGC membership)
Open Geospatial Consortium (OGC). OGC 21-018: OGC Testbed-17: Features and Geometries JSON CRS Analysis of Alternatives ER. Edited by P. Vretanos. 2021. Available at http://docs.opengeospatial.org/per/21-018.html
Open Geospatial Consortium (OGC) / World Wide Web Consortium (W3C): Spatial Data on the Web Best Practices [online]. Edited by J. Tandy, L. van den Brink, P. Barnaghi. 2017 [viewed 2020-03-16]. Available at https://www.w3.org/TR/sdw-bp/
Open Geospatial Consortium (OGC) / World Wide Web Consortium (W3C). Time Ontology in OWL [online]. Edited by S. Cox, C. Little. 2020 [viewed 2020-11-22]. Available at https://www.w3.org/TR/owl-time