Merge pull request #63 from opengeospatial/issue-59

cportele · web-flow · commit ed7b870ec464 · 2022-09-07T14:46:35.000+02:00
Final edits before v0.1.0
diff --git a/core/21-045.adoc b/core/21-045.adoc
@@ -22,7 +22,7 @@
 |Publication Date:   <yyyy-mm-dd>
 |External identifier of this OGC(R) document: http://www.opengis.net/doc/IS/{standard}/{m_n}
 |Internal reference number of this OGC(R) document:    21-045
-|Version: {m_n} (Editor's Draft)
+|Version: {m_n}
 |Category: OGC(R) Implementation Standard
 |Editor:   Clemens Portele, Panagiotis (Peter) A. Vretanos
 |===
diff --git a/core/annex-history.adoc b/core/annex-history.adoc
@@ -6,5 +6,5 @@
 |===
 |Date |Release |Editor | Primary clauses modified |Description
 |2022-01-07 |0.0 |C. Portele |all |initial version
-|2022-0x-xx |0.1 |C. Portele, P. Vretanos |all |first draft release
+|2022-08-08 |0.1 |C. Portele, P. Vretanos |all |first draft release
 |===
diff --git a/core/clause_7_building_blocks.adoc b/core/clause_7_building_blocks.adoc
@@ -256,8 +256,6 @@ GeoJSON (both the current https://tools.ietf.org/html/rfc7946[RFC] and the https
 
 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 can avail themselves of enhanced CRS support.
 
-NOTE: TODO - Check original proposal for another alternative how to disambiguate between different JSON objects that represent a CRS by-reference, by-value, etc.?
-
 ===== Reference system values
 
 A reference system can be specified in a JSON-FG document using a "coordRefSys" member in one of three ways:
@@ -407,7 +405,7 @@ Additional link attributes may be added to the Link object.
 
 A schema is metadata about a JSON document that clients can use to validate the JSON document or to derive additional information about the content of the JSON document, such as a textual description of the feature properties or their value range.
 
-NOTE: As of 2021, the OGC Features API Standards Working Group is working on a https://github.com/opengeospatial/ogcapi-features/tree/master/proposals/schemas[specification in the OGC API Features series] for using JSON schemas to describe the schema of features.
+NOTE: As of 2022, the OGC Features API Standards Working Group is working on a https://github.com/opengeospatial/ogcapi-features/tree/master/proposals/schemas[specification in the OGC API Features series] for using JSON schemas to describe the schema of features.
 
 This Standard provides guidance on how to include information about the schema of a JSON document that is a JSON-FG feature or feature collection.
 
@@ -452,8 +450,6 @@ A JSON-FG feature must contain a link to the JSON-FG feature schema at `\https:/
 
 NOTE: These are (or will be) canonical URIs. Clients can identify that a JSON document is a GeoJSON and JSON-FG feature collection or feature by string comparisons.
 
-NOTE: TODO - Check stability of the GeoJSON URIs with the GeoJSON maintainers.
-
 [NOTE]
 ====
 If features are accessed using building blocks from OGC API Features, a collection can be comprised of features with different feature types. The Features API SWG should include guidance in the Schema extension how to construct a feature schema for such a collection. Multiple options exist, including:
@@ -463,6 +459,6 @@ If features are accessed using building blocks from OGC API Features, a collecti
 - A separate schema per feature type.
 ====
 
-NOTE: TODO - JSON Schema is a rich language and it should be considered limiting the language constructs that should be used in describing the properties in the feature schema. A potential starting point is the current proposal for https://docs.ogc.org/DRAFTS/19-079r1.html#rec_filter_queryables-schema[a JSON Schema profile for queryable feature properties].
+NOTE: JSON Schema is a rich language and it should be considered limiting the language constructs that should be used in describing the properties in the feature schema. A potential starting point is the current proposal for https://docs.ogc.org/DRAFTS/19-079r1.html#rec_filter_queryables-schema[a JSON Schema profile for queryable feature properties].
 
-NOTE: TODO - The schema of a feature type will typically specify the details of the feature properties, but it can also profile the feature-level members including the "geometry", "place" and "time" members. A typical example is to restrict the list of allowed geometry types. To simplify parsing the feature schemas it could be discussed, if canonical schemas for well-known types should be used in "$ref" members. For example, if the geometry is restricted to points, the "geometry" and "place" members could reference `\https://geojson.org/schema/Point.json` or some other canonical URI.
+NOTE: The schema of a feature type will typically specify the details of the feature properties, but it can also profile the feature-level members including the "geometry", "place" and "time" members. A typical example is to restrict the list of allowed geometry types. To simplify parsing the feature schemas it could be discussed, if canonical schemas for well-known types should be used in "$ref" members. For example, if the geometry is restricted to points, the "geometry" and "place" members could reference `\https://geojson.org/schema/Point.json` or some other canonical URI.
diff --git a/core/clause_8_core.adoc b/core/clause_8_core.adoc
@@ -25,6 +25,8 @@ A JSON-FG document is either a feature or feature collection that meets all requ
 ^|A |The JSON document SHALL validate against <<schema-feature>> (a JSON-FG feature) or <<schema-feature-collection>> (a JSON-FG feature collection).
 |===
 
+While every JSON-FG document has to 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.
+
 === Temporal information
 
 :req: instant
diff --git a/core/clause_9_3d.adoc b/core/clause_9_3d.adoc
@@ -20,7 +20,7 @@ The Requirements Class "3D" adds provisions for geometries in a 3D CRS and that
 [width="90%",cols="2,7a"]
 |===
 ^|*Requirement {counter:req-num}* |/req/{req-class}/{req}
-^|A |All positions in a geometry object in the "place" member in any JSON-FG feature in the JSON document SHALL have coordinate dimension 3.
+^|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 coordinate dimension 3.
 |===
 
 :req: geom-valid
diff --git a/core/schemas/place.json b/core/schemas/place.json
@@ -30,6 +30,12 @@
     {
       "$ref": "geometry-objects.json#/$defs/MultiPolyhedron"
     },
+    {
+      "$ref": "geometry-objects.json#/$defs/Prism"
+    },
+    {
+      "$ref": "geometry-objects.json#/$defs/MultiPrism"
+    },
     {
       "$ref": "geometry-objects.json#/$defs/CustomGeometry"
     }
diff --git a/implementations/README.adoc b/implementations/README.adoc
@@ -2,17 +2,17 @@
 
 This page lists endpoints that implement draft versions of JSON-FG.
 
-The current list is from OGC Testbed-17:
+The current list is from OGC Testbed-17. All implementations are supporting version 0.0 from January 7, 2022. It is planned to update some implementations to version 0.1 during the [September 2022 Code Sprint](https://www.ogc.org/ogcevents/2022-joint-ogc-isotc-211-code-sprint-aka-metadata-code-sprint).
 
-[cols="2h,2a,2a,4a",options="header",grid="rows",stripes="hover"]
+[cols="2h,2a,2a,4a,1",options="header",grid="rows",stripes="hover"]
 |===
-| Type | Software Tool | Provider | URL
-| OGC Web API | CubeServ | CubeWerx Inc. | https://test.cubewerx.com/cubewerx/cubeserv/tb17
-| OGC Web API | ldproxy | interactive instruments | https://t17.ldproxy.net/
-| OGC Web API | pygeoapi | Skymantics | https://fgjson.skymantics.com/
-| Web client | MapStore | GeoSolutions | https://geosolutions-it.github.io/mapstore-testbed/fgjson-app/dist/#/
-| Web client | LuciadRIA | Hexagon | https://demo.luciad.com/tb17
-| Desktop client | GNOSIS Cartographer | Ecere | n/a
+| Type | Software Tool | Provider | URL | Version
+| OGC Web API | CubeServ | CubeWerx Inc. | https://test.cubewerx.com/cubewerx/cubeserv/tb17 | 0.0
+| OGC Web API | ldproxy | interactive instruments | https://t17.ldproxy.net/ | 0.0
+| OGC Web API | pygeoapi | Skymantics | https://fgjson.skymantics.com/ | 0.0
+| Web client | MapStore | GeoSolutions | https://geosolutions-it.github.io/mapstore-testbed/fgjson-app/dist/#/ | 0.0
+| Web client | LuciadRIA | Hexagon | https://demo.luciad.com/tb17 | 0.0
+| Desktop client | GNOSIS Cartographer | Ecere | n/a | 0.0
 |===
 
 ## Contribute

Original file line number	Diff line number	Diff line change
`@@ -30,6 +30,12 @@`
`30`	`30`	`{`
`31`	`31`	`"$ref": "geometry-objects.json#/$defs/MultiPolyhedron"`
`32`	`32`	`},`
	`33`	`+ {`
	`34`	`+ "$ref": "geometry-objects.json#/$defs/Prism"`
	`35`	`+ },`
	`36`	`+ {`
	`37`	`+ "$ref": "geometry-objects.json#/$defs/MultiPrism"`
	`38`	`+ },`
`33`	`39`	`{`
`34`	`40`	`"$ref": "geometry-objects.json#/$defs/CustomGeometry"`
`35`	`41`	`}`