OGC Requests

The Open Geospatial Consortium (OGC) seeks public comment on a revision to the OGC API - Processes Standards Working Group (SWG) Charter, which introduces new work items for the SWG. 

The OGC API - Processes SWG is the group within the OGC membership responsible for the development and maintenance of the OGC API - Processes core standard and its extensions, as well as for maintaining the WPS standard.

OGC API - Processes provides organizations the opportunity to make available on the web geospatial software libraries and utilities that, up until now, had only been available as standalone desktop products. It forms a crucial part of OGC’s “user-to-the-data” architecture that allows users to not only mine intelligence from their cloud-based data through streamlined analysis, but also to create value-added products for others to use.

OGC API - Processes, like its predecessor (WPS), achieves this by providing a standardized mechanism for computational geospatial processes to be deployed and offered as services within Cloud Computing environments. 

With the initial development of the OGC API - Processes standard now complete, the OGC API - Processes SWG will begin to address extensions that will simplify the deployment and execution of geospatial processing packages and chained processing workflows.

Specifically, the SWG will begin work on the following extensions to Part 1 Core (final names TBA):

Part 2: Transactions for deployment
This extension will enable the dynamic deployment and execution of processes as application packages. An application package is a file that provides a description of a process(es) to be deployed, including the inputs and outputs of the process(es) as well as other ancillary metadata (e.g. reference to a containerized execution unit) necessary for the process to be deployed. An application package can take many forms (e.g. Jupyter notebook, workflow execution document, etc.) and so this extension will not mandate any specific form but will instead include one or more optional conformance classes for application package formats that have been developed via OGC Innovation Program Initiatives (e.g. CWL, MOAW, OGC Application Package, etc.). 

Part 3: Workflows and Chaining
This extension will provide the ability to:

• chain nested processes,
• refer to external processes and collections accessible via OGC API standards, and
• trigger execution of processes through OGC API data delivery specifications (such as OGC API - Features, Tiles, Maps and Coverages).

The SWG will look at different solutions for workflows and chaining to ensure validation of the defined architecture across multiple approaches.

OGC Members interested in staying up-to-date on the progress of this standard, or contributing to its development, are encouraged to join the SWG via this link on the OGC Portal.

The Open Geospatial Consortium (OGC) seeks public comment on the draft updated charter for the GeoTIFF Standard Working Group (SWG), which introduces several new tasks for the SWG. 

The Geographic Tagged Image File Format (GeoTIFF) specification, as an extension to the public domain TIFF format, has been used for sharing geographic image data successfully for years across many platforms and software environments. GeoTIFF defines a set of TIFF tags that describe the "cartographic" information associated with TIFF imagery originating from satellite imaging systems, scanned aerial photography, scanned maps, digital elevation models, or as a result of geographic analyses. 

The initial scope of the GeoTIFF SWG was to incorporate the GeoTIFF specification into the OGC standards suite by updating the specification to bring it into conformance with current OGC practices. The resulting Standard, GeoTIFF v1.1 was adopted as an OGC Standard in 2019. The original scope of the GeoTIFF also specified that the SWG would: provide a forum for evolving the standard in the future; maintain compatibility with existing geoTIFF community implementations and practices; and that future evolution would be done in close cooperation with the existing geoTIFF community.

As a result of that cooperation, the GeoTIFF SWG has updated its charter to include the following additional tasks to support the evolution of this popular standard:

• GeoTIFF 1.2 - This task will address open issues which were out of scope for version 1.1 but not significant enough for a major revision. GeoTIFF 1.2 shall maintain backward compatibility with GeoTIFF 1.1.
• BigTiff support - The TIFF file format uses 32 bit offsets. This limits TIFF files to four gigabytes. The BigTIFF format resembles TIFF but uses 64 bit offsets instead. GeoTIFF 1.1 will be extended to enable bigTIFF (in addition to TIFF).
• Standardize Cloud-Optimized GeoTIFF (COG) - The COG community would like to turn-over management of the COG specification to OGC. OGC shall establish a GeoTIFF/TIFF standard or best practice that fully documents the COG format in the manner of an OGC specification.
• GeoTIFF / LAS harmonization - This task will examine the overlap between GeoTIFF and LAS. The deliverable will be recommendations on how to keep these two standards synchronized.
• Data Cubes - This task will explore the potential of GeoTIFF to support analytics including coverages and data cubes.
• GeoTIFF 2.0 - This task will examine issues which cannot be addressed within the scope of a minor update (GeoTIFF 1.2).

The Open Geospatial Consortium (OGC) seeks public comment on the proposal for a revision to the OGC Indexed 3D Scene Layers (I3S) Community Standard. The proposed revision is defined in the I3S Version 1.2 Community Standard Work Item Justification document. 

I3S enables the streaming and storage of arbitrarily large amounts of 3D geographic data. An I3S dataset, referred to as a Scene Layer, can consist of millions of discrete 3D objects with attributes, integrated surface meshes, symbolized points, or billions of point cloud data covering vast geographic areas. Designed for performance and scalability, a scene layer enables the efficient encoding and transmission of various types of geospatial content for an interactive visualization experience on web browsers, mobile, and desktop apps for both offline and online access. A Scene Layer can be accessed in the form of a web service or Scene Layer Package (SLPK) – a file-based exchange format.

I3S is web and cloud friendly and is rooted in modern standards and technological advancements in the areas of 3D graphics, data structuring, and mesh and texture compression. I3S is accessible for efficient client-side filtering. I3S empowers city and local governments, content providers, and GIS professionals to share scene layers consisting of terabytes of nation-wide point cloud coverage, city and site scale 3D mesh data collected at frequent intervals, 3D planning scenarios fusing both ‘as built’ and modeled information, and more. The increased accessibility and ease of consumption of geospatial content by both domain experts as well as casual users is being rapidly accelerated by standards such as I3S.

The proposed revisions for I3S version 1.2 include:

• Introduction of paged node access pattern – which significantly reduces the client-server traffic by bundling individual node metadata resources into compact pages of nodes.
• Introduction of a more compact geometry layout for 3D Object and Integrated Mesh layers binary geometry payloads – using a well-known quantization encoding (Draco).
• Introduction of an advanced material definitions property such as physically based materials.
• More optimal selection strategy – standardizes on Oriented Bounding Boxes (OBBs) based node selection criterion.
• Editorial updates/corrections.

These new enhancements are based on the Esri I3S version 1.7 product release.  OGC I3S v1.2 is backwards compatible with OGC I3S v1.1.

The Open Geospatial Consortium (OGC) seeks public comment on its adoption of CityJSON as an OGC Community Standard.

CityJSON is a JSON-based encoding for a subset of the OGC CityGML data model (version 2.0.0). CityJSON defines ways to describe most of the common 3D features and objects found in cities (such as buildings, roads, rivers, bridges, vegetation, and city furniture) and the relationships between them. It also defines different standard levels of detail (LoDs) for the 3D objects, which allows different resolutions of objects for different applications and purposes.

A CityJSON file describes both the geometry (an object’s form) and the semantics (an object’s function) of the features in a given area, such as the buildings, roads, rivers, vegetation, and city furniture.

The aim of CityJSON is to offer an alternative to the GML encoding of CityGML, which can be verbose and complex to read and manipulate. CityJSON aims at being easy-to-use, both for reading datasets and for creating them. It was designed with programmers in mind, so that tools and APIs supporting it can be quickly built.

The differences between the CityJSON v1.0 implementation and the XML-based implementation are described in more detail on this webpage.

Please note that the CityGML 3.0 Conceptual Model specification is also currently open for public comments. CityGML 3.0 is a data model that has been re-structured to be independent of particular encodings; it may have a JSON encoding in the future. CityJSON 1.0 provides a directly implementable JSON encoding based on the CityGML 2.0 data model, an OGC standard since 2012. GML encodings and JSON encodings address different use cases – different communities looking to achieve different things, each useful in their own right. Hence, the OGC community sees value in offering both CityGML 3.0 and CityJSON 1.0.

CityJSON has been submitted to OGC for adoption as a Community Standard by the following organizations: Geonovum, Delft University of Technology, Kadaster International, virtualcitySYSTEMS, National University of Singapore, Forum Virium Helsinki Oy, and Ordnance Survey.

An OGC Community Standard is an official Standard of OGC that is considered to be a widely used, mature specification, but was developed outside of OGC’s standards development process. The originator of the standard brings to OGC a “snapshot” of their work that is then endorsed by OGC membership so that it can become part of the OGC Standards Baseline.