OGC Requests

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.

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.

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.

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.