Consider an OGC API - Common hierarchy mechanism

[jerstlouis]

Organization by type of features or geo-political regions is not at all specific to 3D content, and is completely unrelated to the purpose of a Bounding Volume Hierarchy to facilitate culling to optimize both data transmissions, management (e.g. memory usage) and visualization performance.

The related issue in OGC API - Common is https://github.com/opengeospatial/oapi_common/issues/11 .

The latest proposal is to use the : separator between hierarchichal components of a collection (aka GeoVolume / container), e.g. /collections/Buildings:Americas:UnitedStates:NewYork:NewYorkCity.

This is mainly related to Scenario #3.

[volkercoors]

I agree with "not at all specific to 3D content, and is completely unrelated to the purpose of a Bounding Volume Hierarchy". But you can have one bounding volume hierarchy containing buildings only. Another one containing terrain, etc. In fact, this is very common. I have not seen a bounding volume hierarchy containing both terrain and building models using 3D Tiles, for example. Example: Cesiums demo of 3D buildings from OSM, the bounding volume hierarchy contains buildings only, terrain is coming from another bounding volume hierarchy (optimized for terrain). From my point of view, we should test the pros and cons of the different approaches in this sprint.

[jerstlouis]

@volkercoors I agree that offering a 3D Tiles tileset (which is normally organized as a BVH) set up as containing "both buildings and terrain" and individual tilesets for buildings and terrain is something that can be explored.

If tilesets are generated on the fly recombining data layers, both options can easily be provided. I believe the most efficient way to deliver terrain via 3D Tiles currently is the quantized terrain mesh, which is a different type of 3D Tiles content altogether than the batched 3D models you would use for buildings. So that would be one argument for favoring separate layers by default, or if only one option is available.

However my suggestion to consider an OGC API - Common hierarchy mechanism is separate from and unrelated to all this. Regardless of how many layers define the dataset, the hierarchy of geo-political data organization above the root node of the BVH (BVHs are practically never organized per geo-political entity -- they're either following a fixed tiling scheme, or distributed according to data density), or of data layers organized by type of features, is a concept that is not specific to 3D data, entirely unrelated to bounding volume hierarchies, but totally the exact same problem that an OGC API - Common hierararchy extension aims to solve.

[volkercoors]

"the hierarchy of geo-political data organization above the root node of the BVH"

yes, I agree. That is in line with what we said in the ER. GeoVolume (aka 3D container) is above the BVH, BVH is the content of a GeoVolume / 3D container)

" currently is the quantized terrain mesh" yes.

[serich]

@jerstlouis if you want Write access to the repo (for example to assign this issue to somebody or upload your slide deck), don't forget to click through the Portal using the following instructions (copied from Slack).

---

To gain Write access to the ISG Sprint GitHub repo (so you can upload your Kickoff slide deck):

1. If you have not yet registered your GitHub ID with the OGC Portal, follow these step-by-step instructions.
2. Go to the ISG Sprint Portal project.
3. Click the link under the “Linked Github Repositories” heading (on the right side) that reads “opengeospatial/OGC-ISG-Sprint-Sep-2020".
4. This will enable you to gain Read access to the GitHub repo, and your GitHub ID will also become visible to me as repo administrator.
5. I’ll then upgrade your privilege to Write access... let me know if you’re waiting.
6. Upload your Kickoff slides.

Thanks.

[jerstlouis]

@serich I believe I have done all steps, but still waiting :) My slides are on the pull request https://github.com/opengeospatial/OGC-ISG-Sprint-Sep-2020/pull/6

[jerstlouis]

@volkercoors right.

hence why the hierarchy stuff could (should in my opinion) simply be https://github.com/opengeospatial/oapi_common/issues/11 , not something specific to the "GeoVolumes API".

[serich]

@serich I believe I have done all steps, but still waiting :) My slides are on the pull request #6

@jerstlouis I think (hope) that I just granted you Write access. Let me know if you're still experiencing any difficulty. Thanks.