3D GeoVolumes SWG

Chair(s):

Boggess, Tom (Strategic Alliance Consulting Inc.) - Co-Chair,
Harrison, Jeff (US Army Geospatial Center) - Co-Chair

Group Charter:

Download Charter document

Group Description:

1.    Purpose of the 3D GeoVolumes Standards Working Group

 

The purpose of this Standards Working Group is to:

 

       Develop and maintain an OGC API – 3D GeoVolumes[1] core standard;

       Develop and maintain extensions of the OGC API – 3D GeoVolumes core standard; and

       Develop and maintain a 3D GeoVolumes resource model.

 

The formal proposed name of the new standard is "OGC API – 3D GeoVolumes - Part 1: Core." The short name “GeoVolumes SWG” or ‘GeoVolumes API” may also be used to refer to this effort in the charter and work products. The term “GeoVolumes” was derived from “3D geospatial volumes.”

 

2.    Business Value Proposition

In recent years several solutions and standards have emerged to access and transfer 3D geospatial content over the internet (e.g. 3D Tiles, I3S, glTF, CDB, CityGML). These solutions were developed for various technical and commercial reasons. They use different distribution mechanisms and are optimized for user requirements and bandwidth situations. As each of these co-existing solutions binds the user to an approach, it is challenging to access a variety of 3D content from different providers.

3D GeoVolumes address this challenge by providing a resource model and corresponding API to integrate various approaches into a single, open standards-based solution. The proposed API and resource model will allow efficient discovery and access of 3D content in multiple formats based on a space-centric perspective.

 

The proposed API will provide methods and apparatus to support:

 

       Executing basic commands to GET, PUT, PATCH, POST, and DELETE 3D GeoVolumes resources; and

       Interface with other resources using OGC API capabilities.

The goal of the proposed API and resource model is not to replace existing distribution methods and models for 3D content, but to extend and enable interoperability between them. For example, the proposed resource model will seek to extend OGC TileMatrixSet and TileSet Metadata to support additional dimensions, including defining fixed partitioning of 3D space.

 

For providers of 3D content, the API and resource model will provide simple methods to publish and offer that content as resources for use by other systems.

 

For developers building infrastructures, the API provides common methods to describe and leverage existing 3D content using modern APIs - saving development and deployment time and costs.

 

For users, applications, and enterprises, the capability to discover and access 3D content across a common API, regardless of the underlying distribution mechanism, represents a significant step forward in geospatial interoperability.

 

In general, the proposed API and resource model will follow a common conceptual organization of space applied by humans, which is a nested collection of spaces where every space contains either a number of sub-spaces or a set of objects. This representation of space is called the Bounding Volume, which is a closed volume containing the union of a set of geometric objects.

 

3.    Scope of Work

 

OpenAPI frameworks have helped to make both description and sharing of API definitions more suitable for standardization than previous solutions. For this reason, OpenAPI will be used for OGC API – 3D GeoVolumes. The concept of a GeoVolumes API was demonstrated in the OGC 3D Data Container and Tiles API Pilot and OGC Interoperable Simulation and Gaming Sprint.

 

The 3D GeoVolumes SWG will build on those efforts to more fully develop and document a 3D GeoVolumes API candidate standard that will provide a modernized, common and consistent interface to services that aligns with the current architecture of the Web and the Spatial Data on the Web Best Practices (https://www.w3.org/TR/sdw-bp/ ).

The 3D GeoVolumes SWG will develop a 3D GeoVolumes API candidate standard which is informed by emerging OGC API best practices and prior API standards examples (e.g., OGC API – Features, OGC API - Common) to define core API functions of GET, PUT, PATCH, POST, DELETE.

 

• Architecture:

 

The OGC API – 3D GeoVolumes standard will specify an implementation specification aligned with prior work in OGC for Web APIs. The proposed standard will define API building blocks to enable servers and clients to access 3D content in multiple formats. OGC API - 3D GeoVolumes will be consistent with HTTP and HTTPS.

 

• Encodings:

 

The first version of the GeoVolumes API will support JSON and HTML as encodings of the resources in the API. No encoding will be mandatory and other encodings may be used as well. The HTTP focus is designed to support the use of multiple formats and defines rules about how servers can return the encoding that the client can best handle (“content negotiation”). The SWG will consider requirements and conformance classes for supporting GeoVolumes resources in multiple encodings in the design of the GeoVolumes API.

 

• Basic information model:

 

The GeoVolumes API standard will conform to OpenAPI models and OGC API best practices.

 

• Reuse:

 

The use of unique GeoVolumes API resources or components will be minimized and, where available, existing industry-standards or patterns that are commonly used by developers will be used instead. The most important example for this is the use of an OpenAPI definition instead of OGC-specific "Capabilities" documents and the use of OGC API - Common components to the maximum extent practicable.

 

• Modularization:

 

OGC API – 3D GeoVolumes - Part 1: Core will define a basic set of capabilities organized in multiple conformance classes building on each other. The minimal conformance class will specify a simple interface to access GeoVolumes resources. The conformance class is sufficient for interfaces to exchange and perform basic web functions with GeoVolumes resources. Additional conformance classes will define additional capabilities based on the requirements and requirements classes defined in the core to meet the needs of use cases that require such capabilities.

 

Identified extensions to be worked within the initial scope of the SWG charter include extensions for community specific parameters. Other extensions may be proposed and addressed in revisions to this charter. The primary goal of the GeoVolumes SWG is to develop the core of "OGC API – 3D GeoVolumes" as quickly as possible and work on extensions after that, driven by community interest. An important aspect is to ensure that implementing the standard will lead to efficient implementations, happy developers of both server and client components, and satisfied users of such components.

 

Before finalizing parts of the future versions of the "OGC API – 3D GeoVolumes," completion of goals should be verified:

 

       Working implementations of all capabilities must be available and tested; and

       Implementation feedback must be considered.

 

A consequence of this verification is that the period between the availability of what is considered a mature draft and the finalization of the candidate standard may be longer than in the past, depending on the availability of evidence about the suitability of the candidate standard based on implementations.

 

Developers should be encouraged as early as possible to implement the draft API specification and provide feedback. An aspect of this is public access to drafts from the beginning. To this end, the SWG intends to use GitHub in the development of this standard, as this is the environment many developers are familiar with and use daily.

3.1    Statement of relationship of planned work to the current OGC standards baseline

This proposed standard is intended to be a major component of the OGC API framework. The proposed standard will take advantage of Web API patterns identified in OGC API standards (e.g., OGC API – Features) and consider ongoing API efforts (e.g., OGC API – Common, OGC API – Tiles and OGC API – Features) to better align with current and emerging IT practices. 

3.2    What is Out of Scope?

Standards are important for interoperability. At the same time, it is important that standards only state requirements that are important for a significantly large group of users. Proposals for new parts of OGC API – 3D GeoVolumes or change requests to existing parts must identify the user group that will benefit from the proposal and for each proposed conformance class; otherwise the proposal will be considered out-of-scope.

OGC API – 3D GeoVolumes is envisioned to be a modular, multi-part standard. Extensions and profiles not identified as in scope in the previous section will require addition of Tasks to the SWG charter prior to commencement of work. If a community has a need to develop a profile, the profile should be specified and governed by that community.

3.3    Specific Contribution of Existing Work as a Starting Point

 

The starting point for the work will be the OGC 20-030: OGC API - Tiles-3D (GeoVolumes)

Engineering Report, OGC 20-029: 3D Data Container Engineering Report, and OGC 20-031: 3D Data Container and Tiles API Pilot Summary Engineering Report. The work shall also be informed by the following specifications and by recommendations found in:

      OGC/W3C Spatial Data Working Group on the Web Best Practices (https://www.w3.org/TR/sdw- bp/);

      OGC Geospatial API White Paper [OGC 16-019r4]

      OGC API - Features - Part 1: Core standard, [OGC 17-069r3]

      OGC API – Coverages and OGC CoverageJSON

      Other OGC APIs such as OGC API – Common and emerging APIs as appropriate.

      OGC TileMatrixSet and TileSet Metadata Standard 2.0

 

Each of these documents recommends an emphasis on resource-oriented APIs in future OGC standards development including use of tools such as OpenAPI.

Please also see Section 8 below.

 

4.    Description of Deliverables

4.1    Initial Deliverables

The following deliverables will result from the initial work of this SWG:

     A final version of the “OGC API – 3D GeoVolumes - Part 1: Core” document for submission to the TC;

     Identification of at least three prototype implementations of the core based on the standard; and

     Zero or more additional parts as time and community interest permits. 

OGC API – 3D GeoVolumes - Part 1: Core” will cover basic capabilities to GET GeoVolume resources. Capabilities for richer interfaces or extension for unique resource considerations will be specified in additional parts.

Once this charter is approved, the targeted start date of this SWG is in July 2021. Initial GeoVolumes resource model and API specifications are anticipated by the end of calendar year 2021 with demonstrated implementations and formal approval of the core GeoVolumes API in 2022.

 

5.    Anticipated Participants

3D Geospatial resource providers.

Developers implementing 3D geospatial services and applications.

Users of 3D geospatial resources.

6.    Other Informative Remarks about this SWG

a.      Similar or Applicable Standards Work (OGC and Elsewhere).

The following standards work may be applicable to the work of the proposed SWG:

     17-069, OGC API - Features

     18-053r2, OGC 3D Tiles Community Standard 1.0

     17-014r5, OGC Indexed 3D Scene Layer (I3S) and Scene Package Format Specification 1.0

     17-014r7, OGC Indexed 3D Scene Layer (I3S) and Scene Package Format Specification 1.1

     15-001r4, OGC 3D Portrayal Service 1.0

 

Additionally, the proposed SWG will monitor other OGC API work ongoing in various Standards and Innovation Program activities.



[1] The general naming pattern that is agreed to in OGC is "OGC API - {resource type}.”