Generating JSON Schema definitions for feature collections

[jechterhoff]

One topic that the specification does not address thus far is feature collections. The encoding rules create schema definitions for single features / types with identity. Thus far, we do not have requirements (classes) with which to define the schema for collections of such types. That may be ok, but let's discuss it here. There are different aspects to consider, which I've documented (with according labels) in the following:

scope and naming of collection definitions

In practice, uniform as well as mixed collections are possible. A uniform collection contains features of a single specific type, whereas a mixed collection can have objects of different type. JSON Schema definitions for uniform collections could be defined with name being {type name} + Collection, whereas a single definition with name FeatureCollection could cover the case of all mixed collections (at least for all types with identity defined by the application schema).

structure of collection definitions

The definition for a uniform collection would ensure that the collection members are all valid against a single type definition.

The definition for the general FeatureCollection would use either an anyOf or oneOf, with a choice of schema definitions for all types with identity. Cases in which an object is valid against more than one of these definitions can be problematic:

• In case of anyOf, maybe the schema definition for a more general type matches, causing the validator to stop the validation process, thus potentially not checking constraints for the specific schema definition for a given type.
• In case of oneOf, the validator does not stop at the first matching schema definition, but continues validation against all options, until it has ensured that either all other definitions do not match, or one more does match. The latter case would result in the overall validation to fail. However, that can easily happen in case of similar class structures, or in case of inheritance hierarchies, where an object matches the schema defined by a supertype as well as that of a subtype.

anyOf seems to be the better choice between the two evils. Right now I do not see a different solution for a general FeatureCollection, but am open for suggestions.

performance

Not sure how performant the validation against the general FeatureCollection would be in practice, in case of a large or complex application schema. Then again, validation time may not be that critical to an application that wants to ensure that data within a collection is valid.

abstract types

It is unclear if collection definitions should be created for or include abstract types. It may be useful to create such definitions for "uniform" collections of abstract types, even if that implies that actual collections may have objects of different subtypes of the abstract type. Definitions for abstract types should not be included in the general FeatureCollection.

base schemas

Another aspect is which base schema to use for the collections. GeoJSON and JSON-FG both define schemas for feature collections (see https://geojson.org/schema/FeatureCollection.json and https://github.com/opengeospatial/ogc-feat-geo-json/blob/main/core/schemas/featurecollection.json). These schemas should be used as base in according encodings. But what about the plain JSON encoding? I suggest to simply use a JSON array for encoding a collection in a plain JSON encoding.

requirements classes

We could define requirements for the generation in the three encoding requirements classes. However, it may be better to create additional requirements classes that depend on them, since communities may want to create different schema definitions for collections. We may even have separate requirements classes for uniform collections and the general collection, since communities may or may not want to use both types of collections.

[PalmJanssen]

@wilkoquak what do you recommend?

[lvdbrink]

From reading this it seems kind of tricky. I don't have a solution myself, because I don't know enough about the details of JSON schema validation. We do have UML models that define collections (e.g. IMGeluid, about noise regulations).

[jechterhoff]

Decision: Summarize the issue in the document, but do not create specific requirements (since this is a new topic, and an open discussion).

[jechterhoff]

Created new Annex D