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: 

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

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

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

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

 

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 DGGS Standards Working Group seeks public comment on new tasks of work added to its charter

Status: 
Please note:  This Request is scheduled to close on 26 September 2019.
Open Date: 
Thu, 09/05/2019
Closing Date: 
Thu, 09/26/2019
Description: 

 

The Open Geospatial Consortium (OGC) seeks public comment on new work tasks added to the charter of the Discrete Global Grid Systems (DGGS) Standards Working Group (SWG).

The original goal of the DGGS SWG was to deliver an implementation standard. However, the fundamental and cross-cutting nature of DGGS resulted in the OGC DGGS being published as an OGC Abstract Specification that defines a conceptual model. In recognition of the nature of the relationship between DGGS and other OGC standards, much of the originally forecast effort to draft specific DGGS encoding standards can instead be accommodated by a mixture of extensions, changes, or best practice guides to/for existing OGC Standards. The DGGS SWG is therefore working with relevant OGC Working Groups as necessary to embed linkages between DGGS and other standards in the OGC Standards baseline. The new tasks proposed for the DGGS SWG address these linkages.

The goal of DGGS is to enable rapid assembly of spatial data without the difficulties of working with projected coordinate reference systems. DGGSs represent the Earth as hierarchical sequences of equal area tessellations, each with global coverage and with progressively finer spatial resolution. Individual observations can be assigned to a cell corresponding to both the position and size of the phenomenon being observed - meaning that the resolution and precision of the data capture is inherently part of the stored data, and not something that needs to be explained in metadata - and potentially overlooked.

Further, DGGS come with a standard set of functional algorithms that enable rapid data analysis of very large numbers of cells and, by their very nature, are well suited to parallel processing applications at multiple spatial resolutions - a boon for big data processing

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: 

OGC seeks public comment on draft charter for new Environmental Data Retrieval API Standards Working Group

Status: 
Please note:  This Request is scheduled to close on 19th September 2019.
Open Date: 
Thu, 08/29/2019
Closing Date: 
Thu, 09/19/2019
Description: 

 

The Open Geospatial Consortium (OGC) seeks public comment on the draft charter for the new Environmental Data Retrieval API Standards Working Group (SWG).

The Environmental Data Retrieval API SWG will standardize some APIs, defined with OpenAPI Version 3, to retrieve various common data patterns from a data store.

Much environmental data is truly 'Big Data', in that it cannot be readily copied and distributed in sensible timescales for many uses. By specifying precisely just the data required in a convenient pattern familiar to the user, a service provider can extract and serve the requested data, simplifying access for the user, and hiding the service implementation details, while being scalable both in terms of the underlying data volumes and the number of supported simultaneous users.

Using stable, standardized, service APIs based on simple data retrieval patterns will improve the access and use of data and information across different domains, including geospatial, facilitating more innovation and value.

A goal of the SWG is that these standardized APIs will be consistent with the strategic direction established by OGC members for OGC API standards, such as OGC API - Features and the future OGC API - Common.

The service APIs will support both traditional and cloud-based approaches to computing and also enable a mix of public and private business models on a 'level playing field'. For example, no one country is capable of supplying weather forecast data at the highest useful resolutions for the whole globe, so a distributed scalable approach is essential, enabling both advanced countries and the Least Developed Countries to contribute to global strategic initiatives of sustainability and development.

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: 

Pages