Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OGC – 3D GeoVolumes SWG meeting notes (3MAY2022) #4

Open
jeffharrison opened this issue May 3, 2022 · 0 comments
Open

OGC – 3D GeoVolumes SWG meeting notes (3MAY2022) #4

jeffharrison opened this issue May 3, 2022 · 0 comments

Comments

@jeffharrison
Copy link
Collaborator

OGC – 3D GeoVolumes SWG meeting (3MAY2022)

Meeting Attendees: Jeff Harrison, Tom Boggess, Clemens Portele, Tom Myers, Peter Vretanos, Ryan Gauthier, Vince Fazio, Ignacio (Nacho) Correas, Volker Coors, Clement Colin

The meeting focused on a discussion of access mechanisms to be included in the OGC – API 3D GeoVolumes candidate specification. Currently, there are 2 access mechanisms identified in the Core document. These are: Static access from a web server and using a Bounding Box query method. A third access method has been proposed. This is a tile coordinate access method. To maintain a clean and concise specification, the current recommendation of the SWG Chair is to identify the third method as an “Extension” to the existing draft specification.

There was a lengthy discussion during the meeting today about whether the 3D GeoVolumes API should follow OGC API - Records (https://docs.ogc.org/DRAFT/20-004.html#record-schema-overview), but it was pointed out that Records are a Cataloging structure that can be used as a discovery mechanism, while 3D GeoVolumes is an index into 3D content (which is not intended to be a discovery mechanism).

During the OGC API - Records discussion it was pointed out that Records could accommodate capabilities to include link following (parent/child) relationships, but the real question is whether the current concise 3D GeoVolumes candidate specification should be expanded to include capabilities that do not align cleanly with the definition of a Bounding Volume Hierarchy resource.

On this topic, the session also discussed how the SWG should keep in mind that the basic resource the 3D GeoVolumes API is based on is a Bounding Volume Hierarchy (BVH). In essence the BVH is an index allowing access to 3D content with the API providing a common access method regardless of the structure of the 3D content.

There was a suggestion that the Cesium 3D Tiles Next, or 3D Tiles v1.1, standard be reviewed. There was also a question of whether the 3D GeoVolumes specification should include an Implicit Tiling access mechanism.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant