Add new Collection Description properties

[jerstlouis]

Possibly add (optional) properties to the collection schema properties that are already defined elsewhere (e.g., in OGC API - Features - Part 2: CRS, OGC API - Maps, OGC API - Tiles):

• storageCrs
• clarify the meaning of the crs property (list of available CRS -- it already appear in a schema fragment, but without any explanation anywhere)
• geometryDimension
• minScaleDenominator
• maxScaleDenominator
• minCellSize
• maxCellSize
• dataType
• geoDataClasses

[chris-little]

Some of the proposed properties are clearly common to many, if not all, APIs. However:
minScaleDenominator, maxScaleDenominator, minCellSize, maxCellSize
seem to be specific to maps and gridded coverages and therefore should be defined in those standards, not an API- Common Part.

[jerstlouis]

@chris-little

The rationale behind including these properties in the schema of Common is that:

• The relevant object schema (the collection description) is defined in Common - Part 2, for a resource defined in Common part 2 (/collections/{collectionId})
• Multiple standards already already define these same properties (with the same meaning):
  • OGC API - Tiles: https://schemas.opengis.net/ogcapi/tiles/part1/1.0/openapi/schemas/common-geodata/collectionInfo.yaml (where these properties are also intended to qualify dataset of vector features, non-gridded coverages, glTF 3D meshes tles, point clouds, and any other kind of tiles)
  • OGC API - Coverages: https://github.com/opengeospatial/ogcapi-coverages/blob/master/standard/openapi/schemas/common-geodata/collectionInfo.yaml#L77 (not limited to gridded coverages specifically, including e.g. point clouds)
  • OGC API - Maps: https://github.com/opengeospatial/ogcapi-maps/blob/master/openapi/schemas/common-geodata/collectionInfo.yaml#L77
• Although the Common schema are extensible (the JSON schema do not say additionalProperties: false), we want to ensure that these properties are reserved for the same purpose how they are already used in these standards, and prevent potential future clashes and conflicts.
• We want to facilitate the implementation of "Common" regardless of the access mechanism by finding relevant common properties / schema in one place
• The purpose of Common is to highlight these commonalities, making it easier for other standards in development to be aware of their existence and encourage re-use.
• Since these properties are not required, implementations of OGC APIs and OGC API Standards depending on Common that do not explicitly reference these properties are free to completely ignore their existence.

Although it is less obvious / more controversial, these specific properties are meaningful for non-gridded data, including vector features, 3D buildings, point clouds, and just about any other dataset.

In CDB, we have the concept of significant size, which applies to vector features, 3D meshes and imagery alike.

In 2DTMS, each tile matrix has a specific resolution that corresponds to both a specific scaleDenominator as well as a cellSize.
2D Tile Matrix Sets can be used to organize multi-resolution data of all kinds (vector features, gridded and non-gridded coverages including point clouds, 3D meshes, and so on...).

So although some might find it a bit of a stretch, these properties are an indication of the resolution of the data i.e., how closely you can look at the data and still see something meaningful, regardless of the data type. They are a very Common concept, and a core one at that.

Whether discovering or requesting data, the resolution is a key aspect. Global data at 1:10,000,000 / 2500 m resolution data is intended for completely different use cases than super high-resolution data at 1:30 / 1 cm. These properties provide an easy way to obtain this information.

[chris-little]

@jerstlouis I think using ...cellSize and ...scaleDenominator to denote more general concepts of resolution or Level of Detail is confusing for non-geospatial developers and creating future legacy problems. And as they are very specifically named, reserving them to prevent potential future clashes and conflicts is a weak argument.

[chris-little]

On a more positive note, dataType is potentially very useful in a wide range of API scenarios. We suggest that it is declared not as a string but as an object, so that there could be a link to a formal definition or Building Block. E.g. a datatype of Float32 could actually point to the IEEE754 definition, or some other if it is archived data from an IBM mainframe.
An object would also enable the useful declaration of vectors rather than scalars, such as wind velocity (=speed and direction, or u and v components of speed) or a 3D stress tensor with 9 components.

[jerstlouis]

@chris-little regarding your interpretation of dataType, the description of the vector components etc. would rather be found in the logical schema that would be defined at /collections/{collectionId}/schema in the Schema requirement class (which follows Features - Part 5), which also corresponds more or less to the "Parameter Names" in EDR, or the "RangeType" in CIS.

Here dataType is more of a high-level kind of data you're dealing with in the form an (extensible) enumeration.
So far the values are:

• map (ready to be visualized (A)RGB images
• vector
• coverage
• pointCloud
• mesh

See also Table 13 in 2DTMS & Tileset metadata and Figure 13 above where all this was initially introduced.

[chris-little]

Thank you @jerstlouis for the explanation. So it is more of a Discovery Metadata description, especially considering the semantic overlap of map / coverage / mesh. And PointCloud and Vector !

[jerstlouis]

@chris-little Yes, it probably actually is possible to offer the same collection as a map, a coverage, a 3D mesh, a point cloud and features all at once through different access mechanisms (OGC API - Maps, Coverages, EDR, 3D GeoVolumes, Features...).