OGC Requests

OGC API - Features - Part 2: Coordinate Reference Systems by Reference

Status: 
Please note:  This Request is scheduled to close on 28 April 2020.
Open Date: 
Fri, 02/28/2020
Closing Date: 
Tue, 04/28/2020 (All day)
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the OGC API - Features - Part 2: Coordinate Reference Systems candidate standard.

OGC APIs usher in a new age for location information on the web, enabling a much simpler way to share and access location information that is consistent with the architecture of the Web. The OGC API family of standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OpenAPI specification is used to define the API building blocks.

OGC API - Features provides the fundamental API building blocks to create, modify, and query ‘features’ on the Web (features are simply the digital representations of objects of interest in the real world). OGC API - Features is comprised of multiple parts, with each part being a separate standard. OGC API - Features - Part 2 extends the core capabilities specified in Part 1: Core with the ability to use coordinate reference systems (CRS) other than WGS 84.

A key advantage to the OGC API - Features standard is the direct, fine-grained access to the data at the feature (object) level, providing greater flexibility for linking of resources on the Web. This OGC standard is consistent with the OGC/W3C Spatial Data on the Web Best Practices.

Specifically, the OGC API - Features - Part 2 standard specifies:

  • How, for each offered feature collection, a server advertises the list of supported CRS identifiers;
  • How the coordinates of geometry valued feature properties can be accessed in one of the supported CRS;
  • How features can be accessed from the server using a bounding box specified in one of the supported CRS; and
  • How a server can declare the CRS used to present feature resources, and optionally the coordinate axis order used.

 

Downloads: 
Comment: 

Comments should be submitted via the OGC API - Features Issues Tracker on GitHub for this standard. Issues may be submitted for consideration through 28 April, 2020. All Issues will be assessed by the editing team.

Subscribe: 

To view comments as they are submitted, follow the  OGC API - Features Issues Tracker on GitHub.

OGC Requests: 
OGC Requests

OGC API - Common

Status: 
Please note:  This Request is scheduled to close on 28 March 2020.
Open Date: 
Thu, 02/27/2020
Closing Date: 
Sat, 03/28/2020 (All day)
Description: 

 

The Open Geospatial Consortium (OGC) is seeking public comment on the candidate OGC API - Common standard.

OGC APIs usher in a new age for location information on the web, enabling a much simpler way to share and access location information that is consistent with the architecture of the Web. OGC API standards define modular API building blocks to spatially enable Web APIs in a consistent way.

In the course of developing OGC’s new suite of OGC API standards, some elements proved to be common across all OGC API standards. OGC has documented these common elements in the form of the OGC API - Common candidate standard.

OGC API - Common serves as a foundation upon which all OGC APIs will be built. The candidate standard identifies resources, captures compliance classes, and specifies requirements that are applicable to all OGC API standards.

Since OGC API-Common is the foundation for OGC API standards, a stable baseline is required prior to developing those standards. Yet the OGC API - Common standard cannot be finalized until it has been validated against those same standards. Therefore, OGC API-Common will go through at least two OGC Public Comment periods. This initial request seeks to establish a “beta” version that is stable enough for use by other OGC API standardization efforts. A final request will be issued once there is sufficient implementation experience to move API - Common forward as an OGC standard. Additional requests for public comment may be issued if changes to the candidate specification justify them.

Downloads: 
Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 
OGC Requests

Indoor Mapping Data Format (IMDF) Candidate Community Standard Work Item Justification

Status: 
Please note:  This Request is scheduled to close on 17 March 2020.
Open Date: 
Tue, 02/25/2020
Closing Date: 
Tue, 03/17/2020 (All day)
Description: 

 

The Open Geospatial Consortium (OGC) is in the process of ratifying Apple’s Indoor Mapping Data Format (IMDF) as a Community Standard. OGC Members Autodesk, Esri, Google, New York City Department of Information Technology and Telecommunications (DOITT), Ordnance Survey Limited, and Safe Software support the submission and welcome public comment ahead of the voting period for the Work Item Justification on March 17, 2020.

Apple designed IMDF to deliver indoor maps for thousands of airports and shopping centers around the world, making it possible for users of the Maps app to find their way indoors and discover places to shop and eat. IMDF provides a mobile-friendly, compact, and human-readable data model for any indoor space, providing a basis for orientation, navigation, and discovery. 

IMDF enables many use cases such as multi-level indoor mapping, indoor way-finding, indoor routing, hyper-local search, and indoor positioning. Using Apple MapKit and MapKitJS for cross platform rendering of IMDF, the free, online IMDF Sandbox, and the Indoor Survey app tool for self-enabling indoor positioning, the format has been adopted by many companies and organizations for use in private and public applications. 

Adoption of IMDF by OGC and the wider mapping community would make it possible to create apps and services using the same highly accurate and detailed map data on any app, website, or operating system. Examples include government agencies using an electronic standard of indoor maps data for efficient response to events, hospitals providing mapping guidance to patients, doctors, and visitors, and airports creating a single map that can be easily styled by partners without altering the accuracy of the underlying data.

An OGC Community Standard is an official standard of OGC that was already available as a widely used, mature specification, but was developed outside of OGC’s standards development and approval 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.

Downloads: 
Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 
OGC Requests

TimeseriesML v1.3 request for comment

Status: 
Please note:  This Request is scheduled to close on 19 March 2020.
Open Date: 
Tue, 02/18/2020
Closing Date: 
Thu, 03/19/2020 (All day)
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on version 1.3 of the TimeseriesML standard. TimeseriesML is an XML Encoding of the Timeseries Profile of Observations and Measurements, and is used for the representation of observations as ‘timeseries’ - that is, a sequence of data values that are ordered in time. TimeseriesML supports observations tagged with location, but is equally useful for applications that aren’t concerned with location.

The core aspect of the Timeseries Profile of Observations and Measurements is the correct, precise description of timeseries. The intent of TimeseriesML is to enable the exchange of precise timeseries datasets across information systems. 

Through the use of existing OGC standards, TimeseriesML provides an interoperable exchange format that may be re-used to address a range of data exchange requirements and scenarios. Example areas of usage are: cross-border exchange of observational and/or forecast data; release of data for public dissemination; enhancing disaster management through data exchange; and exchange in support of national reporting.

Version 1.3 of TimeseriesML adds an optional ‘TimeseriesMetadata’ property as a specific count of the number of time steps in a timeseries, or each homogeneous (regularly spaced) segment of an irregularly spaced whole timeseries. For example, a timeseries containing temperature forecasts: 

  • every 1 hour for the 1st 36 hours of the time series;
  • every 3 hours from forecast hour 36 to 72; and
  • every 6 hours from forecast hour 72 out to 7 days.

 

Downloads: 
Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 
OGC Requests

Public comment requested: CityJSON Community Standard Work Item

Status: 
Please note:  This Request is scheduled to close on 5th March 2020
Open Date: 
Thu, 02/13/2020
Closing Date: 
Thu, 03/05/2020 (All day)
Description: 

 

The Open Geospatial Consortium (OGC) is considering CityJSON for adoption as an official OGC Community Standard. A new Work Item justification to begin the Community Standard endorsement process is available for public comment.

CityJSON is a JSON-based encoding for a subset of the OGC CityGML data model, which is an open standardized data model and exchange format to store digital 3D models of cities and landscapes. 

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. CityJSON considerably simplifies the storage and exchange of 3D city models.

The purpose of CityJSON is to offer an alternative to the GML encoding of CityGML, which can be verbose and therefore complex to work with. The design objective for CityJSON is ease of use for both reading datasets and for creating them. CityJSON was designed with programmers in mind, therefore tools and APIs supporting it can be quickly built. It was also designed to be compact - using CityJSON typically compresses publicly available CityGML files by a factor of 6x - while at the same time being friendly for web and mobile development.

CityJSON was developed, and is maintained, by the 3D geoinformation group at TU Delft. Others have since joined its development, especially virtualcitySYSTEMS and Claus Nagel.

Downloads: 
Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 
OGC Requests

Public comment requested: Core Tiling Conceptual and Logical Models Abstract Specification Topic

Status: 
Please note:  This Request is scheduled to close on 20th February 2020
Open Date: 
Tue, 01/21/2020
Closing Date: 
Thu, 02/20/2020 (All day)
Description: 

 

The Open Geospatial Consortium (OGC) is seeking public comment on the Abstract Specification Topic ‘Core Tiling Conceptual and Logical Models.’ The Abstract Specification defines a tiling conceptual model as well as a logical model for tiling 2-D planar space based on the conceptual model.

Numerous OGC standards specify some type of tiling scheme. These standards include Web Map Tiling Service (WMTS), CDB, and GeoPackage. There have also been a number of OGC Innovation Initiatives focused on tiling and tiling schemes. However, a general tiling conceptual model and related logical model for two-dimensional Euclidean (aka planar) space - the most common tiling approach for geospatial technologies - have not been defined. 

The general tiling conceptual model described in the Abstract Specification is applicable to space with any number of dimensions. The conceptual model makes no assumptions regarding content, use cases, implementation scenarios, or how the space is to be tiled. 

As one or more logical models are required to provide the requirements and structure necessary for implementation, the Abstract Specification also specifies a core logical model for the two-dimensional Euclidean use case. 

Across geospatial technologies, the tiling of two-dimensional Euclidean space is the most common approach for partitioning space. However, there are common elements and semantics across any approach to partitioning a space of any number of dimensions. The logical model described in the Tiling Abstract Specification therefore defines this set of common required elements and then follows with more specific requirements for the two-dimensional case.

Other Parts that specify additional logical models, such as for three-dimensional Euclidean space, may be added in the future.

Downloads: 
Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 
OGC Requests

Public comment requested: IndoorGML v1.1

Status: 
Please note:  This Request is scheduled to close on 29th November 2019.
Open Date: 
Wed, 10/30/2019
Closing Date: 
Fri, 11/29/2019 (All day)
Description: 

 

The Open Geospatial Consortium (OGC) is seeking public comment on the v1.1 update to the IndoorGML standard.

The goal of IndoorGML is to represent and allow for exchange of the location information required to build and operate indoor spatial services such as indoor navigation systems. Several standards, such as CityGML, KML, and IFC, have been published to describe 3D geometry and semantics of buildings for outdoor/indoor spaces, but they lack some important features that are specific to indoor spaces. IndoorGML aims to provide complementary and additional encoding features for indoor space. In this respect, IndoorGML is a complementary standard to CityGML, KML, and IFC.

IndoorGML v1.1 introduces a new feature for level (i.e. storey or floor) information as an additional attribute of cell space to respond to the requirements from many indoor spatial applications. IndoorGML v1.1 is fully compatible with the previous version IndoorGML v1.0.

The OGC IndoorGML Encoding Standard was developed to provide a common schema framework for interoperability between indoor spatial applications. These cover a broad spectrum of application areas such as indoor location services, indoor web map services, indoor emergency control, indoor IoT sensors, guiding services for visually handicapped persons in indoor space, and indoor robotics. Cross-platform, vendor-neutral communication of indoor spatial information is essential to meet the market demands of these applications.

Downloads: 
Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 
OGC Requests

Public comment: OpenFlight Scene Description Specification as an OGC Community Standard

Status: 
Please note:  This Request is scheduled to close on 28th November 2019.
Open Date: 
Tue, 10/29/2019
Closing Date: 
Thu, 11/28/2019 (All day)
Description: 

The Open Geospatial Consortium (OGC) is considering the OpenFlight Scene Description Database Specification (v16.0) for adoption as an official OGC Community Standard. Public comment is sought before approval.

The OpenFlight Scene Description Database Specification, commonly referred to as simply “OpenFlight,” is a 3D scene description file format used for real-time visual simulation of 3D terrain features and moving models, such as ground and air vehicles.

OpenFlight was submitted to OGC for consideration as a community standard by its creator and maintainer, Presagis. While OpenFlight databases are often created and edited using Presagis software tools, the format is widely adopted and, as a result, many tools exist in the marketplace that are able to seamlessly read and write OpenFlight files.

The OpenFlight file format supports both simple and relatively sophisticated real-time software applications. The full implementation of OpenFlight supports variable levels of detail, degrees of freedom, sound, instancing (both within a file and to external files), replication, animation sequences, bounding volumes for real-time culling, scene lighting features, light points and light point strings, transparency, texture mapping, material properties, and many other features.

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

Downloads: 
Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 
OGC Requests

Public comment requested: OGC JSON Encoding Extension to Moving Features Standard

Status: 
Please note:  This Request is scheduled to close on 21st November 2019.
Open Date: 
Tue, 10/22/2019
Closing Date: 
Thu, 11/21/2019 (All day)
Description: 

The Open Geospatial Consortium (OGC) is seeking public comment on the new OGC Moving Features Encoding Extension - JSON candidate standard. Comments are due 21 November, 2019.

This candidate standard defines how to encode and share the various movements of geographic features by using JavaScript Object Notation (JSON). Such a ‘moving feature’ is one whose location changes over time. For example, a car, a pedestrian, an airplane, a ship, etc.

OGC Moving Features Encoding Extension - JSON provides an IETF GeoJSON encoding for OGC Moving Features as an alternative to XML Core or Simple CSV. A moving feature contains a temporal geometry, whose location continuously changes over time, as well as dynamic non-spatial attributes whose values vary with time. The JSON Encoding Extension supports, 0- (point trajectories), 1- (lines), 2- (polygons), and 3-dimensional (polyhedrons) objects with locations and/or properties that vary over time.
The ability to attribute time-varying properties to an object (rather than just varying its location or trajectory), has utility and value in many current application areas, including: Location Based Services, Intelligent Transportation Systems, Disaster Risk Management Systems, and Smart City Applications. For example, the traffic congestion on roads and ‘hotspots’ of air pollution are typical moving features seen in the real world.

The representation of the following phenomena in a spatiotemporal domain is within the scope of this Encoding Standard:

  • Discrete phenomena, which exist only on a set of instants, such as road accidents;
  • Step phenomena, where the changes of locations are abrupt at an instant, such as administrative boundaries;
  • Continuous phenomena, whose locations move continuously for a period in time, such as vehicles, typhoons, or floods.
Downloads: 
Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments). Please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 
OGC Requests

OGC 3D streaming Community Standard, I3S, receives update: public comment sought before approval

Status: 
Please note:  This Request is scheduled to close on 7th November 2019
Open Date: 
Tue, 10/08/2019
Closing Date: 
Thu, 11/07/2019 (All day)
Description: 

 

The Open Geospatial Consortium (OGC) seeks public comment on v1.1 of the candidate OGC Community Standard Indexed 3d Scene Layer (I3S) and Scene Layer Package Format Specification. I3S v1.0 was approved as an OGC Community standard in 2017 Since then new features have been developed and implemented by the I3S community. The candidate Community Standard was submitted by Esri.

I3S is used to stream large three-dimensional (3D) datasets and is designed for performance and scalability. I3S supports 3D geospatial content as well as the requisite coordinate reference systems and height models in conjunction with a rich set of layer types. I3S is designed to be cloud, web, and mobile friendly, and is based on modern web standards.

A single I3S dataset, referred to as a Scene Layer, is a container for arbitrarily large amounts of heterogeneously distributed 3D geographic data. Scene Layers are designed to be used in mobile, desktop, and server-based workflows and can be accessed over the web or as local files.

The delivery format and persistence model for Scene Layers, referred to as Indexed 3d Scene Layer (I3S) and Scene Layer Package (SLPK) respectively, are specified in detail in the OGC Community Standard now available for public review and comment.

The changes included in v1.1 of the OGC I3S Community Standard include:

  • Addition of the Point Cloud Scene Layer (PCSL) type. A PCSL is designed to quickly display large volumes of symbolized and filtered point cloud data. A PCSL is scalable similar to Mesh-Pyramids and Point profiles that are currently supported in I3S V1.0. A PCSL relies on principles of bounding volume driven tree hierarchy, to organize a multi-LOD (Level of Detail) representation of the point cloud data structure. This in turn, allows for a quick discovery and selection of the appropriate LOD by a client application, whether its consumed on a mobile, web, or desktop platform.
  • For existing layer types, the addition of: Oriented Bounding Boxes; Attribute Domain Rules; Service Update Timestamp, and; Index hash table for improved performance.
  • Numerous editorial updates/corrections to improve readability.

 

Downloads: 
Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 
OGC Requests

Pages