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.
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.