Using GeometryCollection as a feature's place is underspecified

[IvanSanchez]

This is regarding sections 7.3 and 8.3 of the draft spec: the "Geometry" section of the FG building blocks and the Core Requirements class, respectively.

My current understanding is that I can use a GeometryCollection as the place property of a feature - nothing in the draft spec prevents me from doing so. I assume that, since JSON-FG must cover all use cases of GeoJSON, having GeometryCollections is an expected use case.

However, while there are extra restrictions on using GeoJSON geometries like Point, MultiPoint, LineString, MultiLineString, Polygon or MultiPolygon, there are no such restrictions on GeometryCollections. See 8.3.3 and 8.3.4.

---

GeometryCollections pose a challenge to the scoping rules of coordRefSys. Consider the following example, which joins together the centroid of the Madrid-Barajas airport with two of its runways:

{
	"type": "Feature",
	"properties": { "name": "Madrid-Barajas airport" },
	"geometry": null,
	"coordRefSys": "http://www.opengis.net/def/crs/EPSG/0/3995",
	"place": {
		"type": "GeometryCollection",
		"coordRefSys": "http://www.opengis.net/def/crs/EPSG/0/4903",
		"geometries": [
			{
				"coordRefSys": "http://www.opengis.net/def/crs/EPSG/0/25830",
				"type": "Point",
				"coordinates": [452023.7, 4482589.61]
			},
			{
				"coordRefSys": "http://www.opengis.net/def/crs/EPSG/0/4326",
				"type": "LineString",
				"coordinates": [ [-3.574719429016113, 40.49262129748309], [-3.57480525970459, 40.52286867251558] ]
			},
			{
				"type": "LineString",
				"coordinates": [ [0.12827676, 40.50123683], [0.12797635, 40.5281206] ]
			}
		]
	}
}

My current scoping scoping rules for coordRefSys say:

Used at the geometry level, the "coordRefSys" key asserts the CRS for the JSON-FG geometry object within which the key is contained.

My understanding is that, since every Geometry inside a GeometryCollection is... well, a geometry, then the scoping rule applies, and the above example makes sense.

My own client implementation of JSON-FG can easily deal with this case, but other client implementations might not have it so easy due to architectural constrains. In any case, I feel there's a need for clarification on how coordRefSys in GeometryCollections should work.

---

It s also unclear whether 3D geometries (Polyhedron, etc) can be part of a GeometryCollection.

[cportele]

Good points @IvanSanchez.

Maybe we should exclude GeometryCollection or add some restrictions.

On the last comment:

It s also unclear whether 3D geometries (Polyhedron, etc) can be part of a GeometryCollection.

Currently they cannot. GeometryCollection is the GeoJSON GeometryCollection. See https://github.com/opengeospatial/ogc-feat-geo-json/blob/main/core/schemas/geometry-objects.json.

[IvanSanchez]

Maybe we should exclude GeometryCollection or add some restrictions.

My personal stance is that any restrictions to "2D geometries" should scope into GeometryCollections.

e.g. a restriction on how a Point works when used as the place of a feature should also apply when the Point is part of a GeometryCollection which is used as the place of a feature.

3D geometries

I'll add: my stance is that GeometryCollections should allow 3D geometries as their members.

(of course this should only apply to the 3D conformance class)

[jratike80]

I think that we must not support mixed CRS in GeometryCollection. They are not allowed in the OpenGIS® Implementation Standard for Geographic information - Simple feature access - Part 1: Common architecture nor in Open GIS Consortium, Inc.
OpenGIS Simple Features Specification For SQL Revision 1.1 This quotation is from the Common:

6.1.3 GeometryCollection
6.1.3.1 Description
A GeometryCollection is a geometric object that is a collection of some number of geometric objects.
All the elements in a GeometryCollection shall be in the same Spatial Reference System. This is also the Spatial
Reference System for the GeometryCollection.
GeometryCollection places no other constraints on its elements. Subclasses of GeometryCollection may restrict
membership based on dimension and may also place other constraints on the degree of spatial overlap between
elements.

The GeoJSON RFC https://www.rfc-editor.org/rfc/rfc7946 defines "GeoJSON comprises the seven concrete geometry types defined in the OpenGIS Simple Features Implementation Specification for SQL". It does not define that when it comes to GeometryCollection then GeoJSON is more flexible than OGC.

[IvanSanchez]

[...] mixed CRS in GeometryCollection [are] not allowed in [OGC SFA]

That's a very convincing argument! I now fully agree that GeometryCollections shall have just one CRS/SRS for all the member geometries.

Can we please amend the JSON-FG spec so that it mentions that bit of the OGC SFA? That should clear things up.

[cportele]

I agree, good point. In addition, the OpenGIS Simple Features Implementation Specification is already a normative reference in the spec.

[cportele]

Meeting 2022-10-31:

• We should follow the constraints of Simple Features and restrict all geometries in a GeomtryCollection to a single CRS.
• Do we really need to also provide a GeometryCollection that includes the additional JSON-FG geometries? Are features with GeometryCollections as geometries really needed in practice and supported by clients? If we need one it should be added with a different type value to avoid conflicts with the GeoJSON GeometryCollection.

[cportele]

Meeting 2023-05-29: The first change is included in #89, but we want to keep the discussion about the need for a GeometryCollection that supports all JSON-FG geometries, too.