jerstlouis
commented
11 months ago 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 https://github.com/opengeospatial/ogcapi-common/issues/11 and https://github.com/opengeospatial/ogcapi-common/issues/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 https://github.com/opengeospatial/ogcapi-common/issues/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.
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.