Add geoDataClass parameter to input description. #474
Conversation
| @@ -157,6 +157,26 @@ The following JSON Schema fragment illustrates the use of the `format` key to in | |||
| } | |||
| ---- | |||
|
|
|||
| ==== Data classes | |||
|
|
|||
| One common input type that a process might accept is a https://docs.ogc.org/is/17-069r4/17-069r4.html#_collection_[feature collection] indicating that the process will somehow operate over the items of the collection. This implies that the process will have certain expections about the structure of the collection with regard to which properties the collection contains, their types, etc. In order to properly handle any arbitrary input collection a process would need to inspect the structure of the 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 step this Standard introduces the concept of the _Data Class_ via the `dataClasses` parameter. | |||
There was a problem hiding this comment.
I'm guessing the "type" mentioned here refers to the geometry type (point, polygon, etc.)? I think that might lead to confusion considering "type" could be interpreted as the media-types or data-type (uint16, float32, etc.). Maybe consider using "geometries" or another word that doesn't have as much overloaded definitions as "type" does.
There was a problem hiding this comment.
The type is not limited to the type of the geometry, but the type of all the properties (integer, real, text...) and any other JSON Schema validation. The geometry type is also part of that as restriction on the "geometry" property.
There was a problem hiding this comment.
Yes. That is my understanding of dataClass. It is a conceptual requirement that goes beyond the way the data is encoded, and allows a complicated combination of property prerequisites. This is why I want to be careful about using terms like "type" that misguide readers about the intent.
There was a problem hiding this comment.
@fmigneault type here refers to the type as defined in the schema of the data resource. That could be the data type (i.e. integer, string, object, etc.) but it could also mean the spatial type (polygon, linestring, etc.). Not sure how to say that succinctly. Perhaps I can add a note right after the information indicating that in this context "type" means type as defined by the schema but also spatial type? Would that help?
There was a problem hiding this comment.
But it also means more, no? It is more a "concept" than a "type".
I agree it is hard to explain succinctly when the description remains abstract.
I think the extended example (where it talks about GeoJSON/Shapefile) helps the most.
| @@ -157,6 +157,26 @@ The following JSON Schema fragment illustrates the use of the `format` key to in | |||
| } | |||
| ---- | |||
|
|
|||
| ==== Data classes | |||
|
|
|||
| One common input type that a process might accept is a https://docs.ogc.org/is/17-069r4/17-069r4.html#_collection_[feature collection] indicating that the process will somehow operate over the items of the collection. This implies that the process will have certain expections about the structure of the collection with regard to which properties the collection contains, their types, etc. In order to properly handle any arbitrary input collection a process would need to inspect the structure of the 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 step this Standard introduces the concept of the _Data Class_ via the `dataClasses` parameter. | |||
There was a problem hiding this comment.
But it also means more, no? It is more a "concept" than a "type".
I agree it is hard to explain succinctly when the description remains abstract.
I think the extended example (where it talks about GeoJSON/Shapefile) helps the most.
Closes #38