Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add geoDataClass parameter to input description. #474

Merged
merged 5 commits into from
Jan 5, 2025
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions core/sections/clause_8_ogc-process-description.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -157,6 +157,14 @@ The following JSON Schema fragment illustrates the use of the `format` key to in
}
----

==== Data class

One common input type that a process might accept is a collection of data indicating that the process will somehow operate over the items of the specified collection. This implies that the process will have certain expections about the structure of the data collection with regard to which properties the data collection contains, their types, etc. In order to properly handle any arbitrary data collection input value a process would need to inspect the structure of the input collection to ensure that all the expected properties are present with the expected types, etc. To alleviate the server from having to perform such a tedious, and perhaps computationally expensive, schema validation process this Standard introduces the concept of the _Geo-Data Class_ via the `geoDataClass` parameter.
pvretano marked this conversation as resolved.
Show resolved Hide resolved
The value of the `geoDataClass` parameter is a URI that identifies a predefined set of properties or a sub-schema. Two data collections tagged with the same `geoDataClass` URI value can be assumed to contain all the properties defined by the class. This equivalence allows a server to quickly validate that a specified data collection input value meets the server's expections in terms of the properties available for processing, their types, etc. simply by comparing `geoDataClass` values. If the `geoDataClass` of the input data collection value matches the `geoDataClass` specified in the description of the input then the server can be assured that the process can operate on that collection. Of course data collections tagged with the same `geoDataClass` URI may contain additional properties not defined by the _Geo-Data Class_ but a process expecting an input value of a particular `geoDataClass` value would simply ignore those extraneous properties.

For example, a specific _Geo-Data Class_ might be defined to include a geometry property _fenceLine_ of type _polygon_. Thus, any input data collection tagged with this URI can be expected to include a _fenceLine_ property and its type can be assumed to be _polygon_.

NOTE: In order for the `geoDataClass` concept to be most effective a registry aking to that found at https://schema.org[Schema.org] would need to be created and maintained. The OGC definition server is likely the best place to maintain _Geo-Data Class_ URIs.
pvretano marked this conversation as resolved.
Show resolved Hide resolved

==== Cardinality

Expand Down
3 changes: 3 additions & 0 deletions openapi/schemas/processes-core/inputDescription.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,9 @@ allOf:
properties:
schema:
$ref: "schema.yaml"
geoDataClass:
type: string
pvretano marked this conversation as resolved.
Show resolved Hide resolved
format: uri
minOccurs:
type: integer
default: 1
Expand Down
Loading