Assess Building Blocks Described in OGC API - Records

[jeffharrison]

The OGC API – 3D GeoVolumes organizes access to a variety of 3D content according to a hierarchy of 3D geospatial volumes (GeoVolumes). While the key focus of the API is on indexing 3D content according hierarchies of 3D geospatial volumes, it may be useful to assess the role of discovery via building blocks described in OGC API – Records.

Accordingly, on 3 May 2022 the SWG agreed to review OGC API – Records for applicable building blocks and methods that may enable access to a variety of 3D content according to hierarchies of 3D geospatial volumes.

Best Regards,
Jeff

[jerstlouis]

@jeffharrison Sorry for not being able to join this meeting today.

Related to #4 meeting discussions.

the basic resource the 3D GeoVolumes API is based on is a Bounding Volume Hierarchy (BVH)

That is definitely true, but those BVHs are already fully described by i3s resource hierarchies and linked 3D Tiles tilesets.
The use case for the hierarchical collections in the 3DC&T was for the top-level resource (the overall collection of 3D data /bounding volumes).

I think discovery (possibly within a smaller locally served dataset), or organization of different 3D collections/datasets, is indeed the use case that this was about (e.g., organize 3D datasets by continents / country / state / municipality). Records may offer a solution, but I think it would involve setting up a separate catalog that is itself its own collection.

I still very much think there is value in a simple hierarchical relationship between collections, and there are several use cases for them. All that is needed is a parent property for collection objects where another {collectionId} can be specified, and a ?parent={collectionId} query parameter on /collections to retrieve only immediate children of that parent. I wish I was there to argue for it this morning :)

Thank you.

@pvretano @cportele @tomkralidis

See also
opengeospatial/ogcapi-common#11
opengeospatial/ogcapi-common#298

[jeffharrison]

@jerstlouis This seems like a productive path to explore if others agree...

"... still very much think there is value in a simple hierarchical relationship between collections, and there are several use cases for them. All that is needed is a parent property where another {collectionId} is specified, and a parent query parameter on /collections to retrieve only immediate children of that parent."

I guess that would replace the use of children in the current drafts (?)

[jerstlouis]

@jeffharrison Yes, that is the idea.

[jeffharrison]

opengeospatial/ogcapi-common#298

[jeffharrison]

I guess part of me wants to say that ...

• if the OGC API – 3D GeoVolumes organizes access to a variety of 3D content according to a hierarchy of 3D geospatial volumes (GeoVolumes),

• and the key focus of the API is on indexing 3D content according to those hierarchies of 3D geospatial volumes,

• and those BVHs are already fully described by i3s resource hierarchies and linked 3D Tiles tilesets...

• why not just use them ;-)

Best Regards,
Jeff

[jerstlouis]

@jeffharrison

why not just use them ;-)

For sure we should.

But the Hierarchical Collections is really a completely separate topic (hierarchy of completely different things) from the Bounding Volume Hierarchy.

Hierarchical Colllections is e.g., for a hierarchy of top-level 3D Tiles tilesets organized by Continent / Countries / State / City.

Internal BVH in 3D Tiles / i3s is for a hierarchy of bounding boxes providing coarser to finer resolutions of models within those top-level tilesets for a given city.

Hierarchical Colllections apply to other types of data as well, not only 3D data / BVHs (quite common for coverages).

[jeffharrison]

Guess we should cut over to the new Issue for this topic ; - )