Collection: "children" and "content" properties

[cportele]

The "children" and "content" properties are just links. The links should be in the "links" property, the relevant links should be identifiable by inspecting the link relation type and not be in separate properties.

[jerstlouis]

Outcome of discussion at session in 127th members meeting in Singapore:

The children property related not to the relationship between BVH nodes, but to relationship between different collections as per hierarchical collections discussed in #5 as well as opengeospatial/ogcapi-common#11 and opengeospatial/ogcapi-common#298 . Since we agreed that we can resolve this in common (likely with a parent property specifying the parent {collectionId}), we can get rid of children here.

The content property with links was redundant with the link relation directly in the links object, we agreed to follow the approach which is the outcome of opengeospatial/ogcapi-common#140 whereas each access mechanism (such as 3D GeoVolumes) would have a dedicated media type.

This was part of the spec at one point as [ogc-rel:bvh], but currently this does not appear in the spec.
Instead, the links in content used either original or alternate. If applied directly in the collection links, these would be odd as the way to offer a BVH access mechanism.

My opinion is that this original vs. alternate distinction is not meaningful. It is unlikely that either i3s or 3D Tiles really reflect in any way the original data capture. The way this was used in the pilot was that a i3s to 3D Tiles converter was used. If the converter was ideal, the different representation should make no difference. Instead, these are just different representations like PNG vs. JPEG, netCDF vs. CoverageJSON.

Therefore I propose that we adopt again [ogc-rel:bvh] or [ogc-rel:bvh-root] as the link relation type for 3D GeoVolumes to access a BVH root node.

In addition to i3s and 3D Tiles, the content section mentions CityGML, CDB and 2D Features.
2D Features already has OGC API - Features specifying items as the link relation type to use for features.
For CDB, each component data layer will be an indepedent collection (that could use the parent property if multiple CDB datasets are available form the same end-point to organize them from the same API). The access mechanism for the CDB data can include BVH as i3s and/or 3D Tiles, and can also include OGC API - Tiles access as defined in the new requirements class for "Direct access by tile coordinates" which would provide a most direct access to the CDB data. Additional access mechanisms can be defined later e.g., to provide direct access to larger multi-tiles CDB 2.0 GeoPackages for more efficient bulk access to whole data stores.

For CityGML, for Testbed 18 Building Energy ( ER ), interactive instruments implemented support for CityJSON using a Features items link relation type, with the "application/city+json-seq" media type (see this collection of Montreal buildings). There is also a GML ( "application/gml+xml" ) items link. Possibly a media type exists specific to CityGML and this approach could be used for that as well?

In any case, it seems that CityGML / CityJSON are more geared towards an OGC API - Features access mechanism for the collection, whereas CDB fits more with the "access by tile indices" requirements class based on OGC API - Tiles (which will use the [ogc-rel:tilesets-vectors] for vector data including points referencing 3D models, [ogc-rel:tilesets-map] for RGB(A) imagery, [ogc-rel:tilesets-coverage] for elevation models, and possibly a new [ogc-rel:tilesets-meshes] for integrated 3D meshes / batched 3D models.

[jerstlouis]

In addition we agreed to get rid of contentExtent, itemType and collectionType.

itemType is specific to Features and Records ( see opengeospatial/ogcapi-common#310 , opengeospatial/ogcapi-features#539) and should not be used here
collectionType should also be removed since a collection can be accessible using multiple access mechanisms, 3D GeoVolumes as BVH and/or direct tiles access being two of them

We should also review the various links that need to be included

• self should still be needed as per Common - Part 2
• [ogc-rel:bvh] or [ogc-rel:bvh-root] should be added as per discussion above if i3s or 3D Tiles are available
• parent probably should be removed in favor of parent property proposed in Hierarchical Collections ogcapi-common#298
• root should be removed
• scheme should be clarified and is not an IANA link relation. We have [ogc-rel:tiling-scheme], however the definition currently requires that this be a 2DTMS. Per the 2DTMS definition of tiling scheme, a tiling scheme is not necessarily a 2DTMS, so we could potentially extend the definition to other types of tiling scheme and use this in this context for tiling schemes that are not 2DTMS. Howver, this information is also likely already included in the 3D Tiles tileset root node, so is this really necessary?
• affinemap currently says:

link from a 3D-Container with 2D content to a 3D-Container with 2.5D content (surface, point cloud) to which the 2D content should S be texture-mapped).

I am not sure I understand what this means, and do not recall how this was used. We should review.