OGC Requests

Public comment requested: Routing Standards Working Group Draft Charter

Status: 
Please note:  This Request is scheduled to close on 2 July 2020.
Open Date: 
Thu, 06/11/2020
Closing Date: 
Thu, 07/02/2020
Description: 

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 OGC API - Routes will enable 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.

  • For providers of routes, the API and route exchange model will provide a simple model to publish and offer those routes as resources for use by other systems.
  • For developers building infrastructures, the API will provide common methods to describe and leverage existing routing engines and algorithms using modern APIs - saving the time and costs associated with developing and deploying custom interfaces.
  • For users, applications, and enterprises, the capability to get routes via a common API, regardless of the underlying routing data, engines, or algorithms will provide a significant step forward in geospatial interoperability and modularity.

The proposed OGC API - Routes will provide 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. The proposed route exchange model will provide a method to share routes, regardless of the underlying proprietary data, routing engine software, or algorithms.

Draft specifications for a routing API and route exchange model were successfully demonstrated in the OGC Open Routing API Pilot, the OGC Smart City Interoperability Reference Architecture (SCIRA) Pilot, and other efforts. Coordination with W3C on OGC API - Routes has begun with discussions in the joint W3C/OGC Spatial Data on the Web Interest Group.

Comment: 

Please submit your comments using the following link: charter-requests [at] opengeospatial.org (Click here to submit comments) Please refer to the following template for the contents of your message: Comments Template.

Subscribe: 

Charter requests are not currently able to be subscribed to.

OGC Requests: 

Public Comment Requested: Standard SensorThings API Part 1 - Sensing V1.1

Status: 
Please note:  This Request is scheduled to close on 6 July 2020.
Open Date: 
Thu, 06/04/2020
Closing Date: 
Mon, 07/06/2020
Description: 

 

The OGC SensorThings API provides an open, geospatially enabled, unified way to interconnect Internet of Things (IoT) devices, data, and applications over the web. SensorThings is currently being used by organizations around the world in support of logistics, public safety, energy utilities, environmental monitoring, and more.

At a high level, the OGC SensorThings API provides two main functionalities, with each function handled by a specific part of the standard: Sensing and Tasking. 

Under public comment is a new version (v1.1) of the Sensing part, which provides a standard way to manage and retrieve observations and metadata from heterogeneous IoT sensor systems. The separate Tasking part provides a standard way for parameterizing - also called tasking - of taskable IoT devices, such as sensors or actuators.

Version 1.1 of the SensorThings API is mostly backwards compatible with v1.0. The main changes in v1.1 include:

  • An additional field for storing additional metadata that is useful for filtering. 
  • Additions to the service root page that allow users to easily see exactly which extensions and optional features a server implements. Additionally, the MQTT extension can now list the MQTT endpoints on the root page so that a user can discover those endpoints.
  • A fix for inconsistencies and incompatibilities surrounding the transmission of the specification version number in MQTT topics.

The first two changes should not impact clients implemented based on version 1.0. The third change, however, may cause some minor issues for some clients that are not using the version prefix in MQTT topics.

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 seeks public comment on Version 1.3 of GeoPackage Standard

Status: 
Please note:  This Request is scheduled to close on 4 June 2020.
Open Date: 
Tue, 05/05/2020
Closing Date: 
Thu, 06/04/2020
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the latest version of the GeoPackage Standard, v1.3.0. GeoPackage is an open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information. Comments are due by June 4, 2020.

GeoPackage version 1.3.0 is a minor revision to the current version 1.2.1. All of the changes were carefully considered for impact on existing implementations. Any changes considered to have a significant impact on reverse compatibility were rejected or recast in order to limit their impact.

In addition to a number of administrative changes to improve readability, clarity, and correctness, the following substantive changes were incorporated into the draft GeoPackage 1.3 release:

  • Enforce alignment of Spatial Reference System (SRS) Identifiers between tables.
  • Clarify use of views in user-defined tables.
  • Relax Requirement 104 to allow use of schemas with attributes and extensions.
  • Allow metadata scopes to be extended.
  • Create new Requirement 152 to describe empty geometries.

 

Comment: 

Comments can be submitted 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. There are three ways to provide input into the candidate standard:

  1. Edit the document on GitHub: if you are familiar with GitHub, please make your proposed changes directly. Instructions are in the README.md file in that repository.
  2. Submit an "issue" on GitHub: GitHub offers a simple interface for posting an issue/comment. Just click the green "New Issue" button.
  3. Submit your comments requests [at] lists.opengeospatial.org (via email. )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: 

Public comment requested: CDB Version 1.2

Status: 
Please note:  This Request is scheduled to close on 21 May 2020.
Open Date: 
Tue, 04/21/2020
Closing Date: 
Thu, 05/21/2020
Description: 

The CDB Standard defines a conceptual model, and rules for implementing that model, for the storage, access, and modification of a synthetic environment data store as required in high-fidelity simulation or mission rehearsal, such as battlefield simulation. The standard addresses the challenge of full plug-and-play interoperability and reuse of geospatial data in a modeling and simulation environment. CDB data stores can be made accessible via OGC web services, such as a Web Map Service (WMS) or Web Feature Service (WFS), to permit visualization and analysis of the content outside of the traditional simulator hardware environment.

CDB Version 1.2 includes numerous minor edits for clarity as well as three substantive changes:

  1. The definition of the Primary Alternate Terrain Elevation dataset has been changed to improve compatibility with standard open source libraries used to read and process elevation data. These changes address an issue that ground simulation has with CDB gridded terrain meshes.
  2. Additional metadata is now provided so that additional file formats or encodings, such as GeoPackage, can easily be incorporated and used. This enhancement also enables applications to much more easily determine which file formats are being used for a specific layer.
  3. Two new volumes are added to the CDB Standard suite that describe how to use the OGC GeoPackage Standard for vector data in a CDB data store.
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: 

Public comment requested: draft charter for proposed MUDDI SWG

Status: 
Please note:  This Request is scheduled to close on 5th May 2020
Open Date: 
Tue, 04/14/2020
Closing Date: 
Tue, 05/05/2020
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the draft charter for the new OGC MUDDI (Model for Underground Data Definition and Integration) Standards Working Group (SWG). Comments are due by the 5th May, 2020.

The vast majority of street excavations occurring around the world are adversely impacted by a lack of usable information about buried infrastructure. Large-scale construction projects are frequently stalled, incurring delay claims and change orders that significantly increase costs. This situation occurs because the locations of existing utility installations were never properly recorded or depicted. Worse than this, the lack of knowledge about underground built environment dependencies and vulnerabilities often stands in the way of effective disaster response and recovery, costing not just money, but lives.

These costs and risks could all be mitigated if accurate, comprehensive underground built environment information were available and shared between responsible parties for rapid integration and analysis. An essential first step towards achieving this capability involves developing geo-enabled utility data models with inbuilt capabilities for enabling data interoperability and integration. The development and adoption of such models would deliver significant benefits by improving data interchange, integration, and application readiness. 

As such, the MUDDI SWG aims to create models and standards that fully represent underground infrastructure assets. Additionally, the MUDDI SWG will create mappings to/from other geospatial data models that characterize the underground environment that contains said assets.

The models to be designed by the MUDDI SWG participants will focus on those attributes most important for specific use cases - such as safe digging, construction design, and disaster resilience. The models have the capacity for extension to accommodate more complex use cases as the business value of data sharing and interoperability is established.

An additional value of developing standardized data models for selected underground utility components and environmental characteristics will be the opportunity to connect with models such as CityGML or BIM/IFC that principally address above-ground features, or GeoSciML/WaterML that cover a broad range of geologic and hydrologic phenomena. 

Ultimately, the work of the MUDDI SWG will contribute to the maximum reuse of data between different domains and computing environments. It will achieve this by enabling the use of standardized, interoperable data to model the entire interconnected built and natural municipal environment, from top to bottom, and at every scale - from small local jurisdictions to regional and national extents.

Comment: 

Comments can be submitted to a dedicated email reflector for a twenty-one 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: charter-requests [at] opengeospatial.org (Click here to submit comments) Please refer to the following template for the contents of your message: Comments Template.

Subscribe: 

Charter requests are not currently able to be subscribed to.

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

 

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

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: 

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

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: 

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

 

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: 

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

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: 

Pages