OGC Requests

The Open Geospatial Consortium (OGC) seeks public comment on a proposed update of the 3D Tiles Community Standard, which is used for sharing, visualizing, fusing, and interacting with massive heterogenous 3D geospatial content across desktop, web, mobile – and now metaverse – applications. 

The proposed v1.1 revision to the 3D Tiles Community Standard, planned for submission to OGC by Cesium, is designed for streaming high-resolution, semantically-rich 3D geospatial data to the metaverse. 3D Tiles 1.1 promotes several 3D Tiles 1.0 extensions to ‘core’ and introduces new glTF™ extensions for fine-grained metadata storage.

The primary enhancements proposed for OGC 3D Tiles 1.1 include:

• Semantic metadata at multiple granularities
• Implicit tiling for improved analytics and random access to tiles
• Multiple contents per tile to support layering and content groupings
• Direct references to glTF™ content for better integration with the glTF™ ecosystem

3D Tiles 1.1 is backwards compatible with 3D Tiles 1.0 – aside from version number itself, valid 1.0 tilesets are also valid 1.1 tilesets.

3D Tiles 1.1 is expected to be finalized by Cesium in May, 2022 and subsequently submitted to OGC for consideration as a revision to the existing Community Standard. Reference implementers are committed to updating their implementations with the final release of the specification. 

3D Tiles was first announced at SIGGRAPH in 2015, and was published as an OGC community standard in 2019. Since then, the community has built apps, exporters, APIs, and engines with 3D Tiles to grow an open and interoperable 3D geospatial ecosystem. This collective experience building with 3D Tiles, combined with the continued growth of 3D geospatial data availability, especially semantic metadata, and increasing user interest in digital twins and the metaverse, has led to this revision of the 3D Tiles specification.

A Community Standard is an official standard of OGC that is developed and maintained external to the OGC. The originator of the standard brings to OGC a “snapshot” of their work that is then endorsed by OGC membership as a stable, widely implemented standard that becomes part of the OGC Standards Baseline.

The Open Geospatial Consortium (OGC) seeks public comment on the candidate OGC API - Routes - Part 1: Core Standard and related candidate OGC Route Exchange Model Standard. The candidate OGC API - Routes Standard specifies the fundamental API building blocks for interacting with on-road route resources, and uses the Route Exchange Model to represent routes. 

Using geospatial information to plan routes for travel and logistics is among the most common uses of geospatial and location-based technologies, with countless routes being generated daily by smartphone users, logistics companies, and others. In support of this, road network data, routing & navigation algorithms, and route calculation services are now available from many different providers and sources. While this diversity in the marketplace is generally beneficial to consumers of route information, it makes accessing, integrating, overlaying, or comparing routes from different routing services overly complex.

The candidate OGC API - Routes - Part 1: Core Standard enables a simple method for an application to query any number of routing and/or data providers, even across multiple modes of transport, and present the resulting routes to the user in a single place. The capability for a client to request and retrieve routes from a routing API provider and share routes between applications will improve interoperability for many users, communities, and enterprises.

The candidate OGC API - Routes - Part 1: Core Standard provides the methods and apparatus for the execution of basic commands to retrieve, update, share, and delete routes, and will interface with other geospatial resources that use OGC APIs. Implementations of this candidate API standard leverage the OpenAPI specification for describing the resources and capabilities they offer. Complementing the API standard, the candidate Route Exchange Model standard provides a standardized method to share routes, regardless of the underlying proprietary data, routing engine software, or algorithms.

• For providers of routes, the API building blocks and the Route Exchange Model provide a simple model to publish and offer those routes as resources for use by other systems.
• For developers building infrastructures, the API building blocks provide an abstraction layer to leverage existing routing engines and algorithms using modern APIs - saving development and deployment time and costs.
• For users, applications, and enterprises, the capability to get routes across a common API, regardless of the underlying routing data, engines, or algorithms, represents a significant step forward in geospatial interoperability.

OGC recognizes that in addition to on-road routing there are many environments for implementing open routing, including off-road, air, sea, Smart Cities, and many others, which may be addressed as future work. In addition, some communities may require specialized parameters in their Routing API. Accordingly, any on-road routing API will accept two waypoints: the start and end position. APIs are, however, free to support additional waypoints between the start and end positions, and be extensible to support parameters required by diverse implementation communities. This too could be addressed as future work or extensions.

The Open Geospatial Consortium (OGC) is seeking public comment on the OGC API - Common - Part 2: Geospatial Data Candidate Standard. The purpose of OGC API - Common - Part 2: Geospatial Data is to provide a common connection between the API landing page and resource-specific details. 

OGC APIs are OGC’s Building Blocks for Location, and are ushering in a new age for location information on the web by enabling a much simpler, consistent, and familiar way to share and access location information. Through the OGC APIs, the OGC community is improving how location information can be integrated: by any developer, with any other type of information, and into any type of application.

OGC API - Common serves as a foundation upon which all OGC APIs can be built. OGC API - Common - Part 1: Core defines the resources and access mechanisms which are useful for a client seeking to understand the offerings and capabilities of an API. OGC API - Common - Part 2: Geospatial Data builds on Part 1 by providing a common connection between the API landing page and geospatial data collections.

Geospatial data is rarely considered as a single entity. Feature Collections, Coverages, Data Sets, etc. are all aggregations of Spatial or Temporal ‘Things’. It stands to reason that an OGC Web API would also expose its holdings as aggregates of spatial resources. The purpose of the OGC API - Common - Part 2 Standard, then, is to provide a means of organizing these aggregate collections and to define operations for the discovery and selection of individual collections.

The OGC API - Common - Part 2 Standard does not specify the nature of the geospatial data that make up a collection. Rather, it provides a basic capability that should be applicable to any geospatial resource type. Additional OGC Web API standards extend this foundation to define resource-specific capabilities.

In parallel to this public review, the OGC Naming Authority is assessing the naming conventions to be used in the Requirements Modules defined in the candidate Standard. These conventions are important in the continued modularization of the OGC APIs, so careful review by experts is welcomed.

The Open Geospatial Consortium (OGC) seeks public comment on the candidate OGC GeoPose Standard, which provides a standard for expressing and sharing  geographically-anchored poses (aka GeoPoses) of objects with six degrees of freedom and referenced to one or more standardized Coordinate Reference Systems. 

The combination of position (e.g. x, y, z or longitude, latitude, elevation) and orientation (e.g. pitch, roll, and yaw) with 6 degrees of freedom for objects in computer graphics and robotics is usually referred to as the object’s “pose.” Pose can be expressed as being in relation to other objects, a place, and/or to the user. When a pose is defined relative to the Earth, it is called a geographically anchored pose, or ‘GeoPose’ for short.

The ability to specify and express the GeoPose of any object will aid in interoperability between 3D spatial computing systems such as those for autonomous vehicles, augmented, virtual, and extended reality (AR/VR/XR), 3D map visualization, or any digital representation of the physical world or part therein, such as digital twins. Further, the ability to express the GeoPose of an object will aid applications involving Earth Observation from spacecraft and aircraft with sensors mounted on rotatable gimbals.

Prior to the OGC’s development of the GeoPose Standard, all geospatially anchored poses were proprietary. This has resulted in unnecessary difficulty when sharing GeoPose information between systems. With OGC GeoPose it will be possible to universally express any physical or digital object’s GeoPose in a manner that can be interpreted and used across the range of modern computing platforms and devices. Physical objects may include AR display devices (being a proxy for a user’s eyes), vehicles, robots, or even a park bench, while digital objects may include a BIM model, a computer game asset, the origin and orientation of the local coordinate system of an AR device, or a point-cloud dataset. 

The candidate OGC GeoPose Standard specifies eight standardization targets: two “Basic” forms with no configuration options, for common use cases, an “Advanced” form with more flexibility for more complex applications, and five composite structures that support time series plus chain and graph structures. The candidate GeoPose Standard is modular, flexible, and designed to suit a range of applications and use cases and enable the exchange of GeoPose information between them.