You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: