OGC Requests

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

The main purpose of this SWG will be to develop and propose a standard for geographically-anchored poses (geopose) with 6 degrees of freedom referenced to one or more standardized Coordinate Reference Systems.

The combination of position (up/down [z], left/right [x] and forward/backward [y]) and orientation (pitch, roll, and yaw) with 6 degrees of freedom for objects in computer graphics and robotics is usually referred to as the object’s “pose.” Pose can be expressed as being in relation to other objects and/or to the user. When a pose is defined relative to a geographical frame of reference or coordinate system, it will be called a geographically anchored pose, or ‘geopose’ for short.

An object with a geopose may be any real physical object. This includes objects such as AR display devices (proxy for a user’s eyes), vehicles, robots, or even a park bench. It may also be a digital object like a BIM model, a computer game asset, the origin and orientation of the local coordinate system of an AR device, or a point-cloud dataset.

All physical world objects inherently have a geographically-anchored pose. Unfortunately, there is not a standard for universally expressing the pose in a manner that can be interpreted and used across the range of modern computing platforms.

The ability to specify the geopose of any object will aid in interoperability between real world 3D spatial computing systems, such as those under development for autonomous vehicles, augmented reality (AR), 3D map visualization, or any digital representation of the physical world or part therein (digital twins).

Members of the Geopose SWG will work towards defining an interoperable way to express, record, transform, and share the geopose of objects in a consistent manner across different applications, users, devices, services, and platforms.

One example of the benefit of standardized geoposes concerns traffic awareness and management: describing the pose of moving cars and people in a universally consistent manner could lower the incidence of accidents and road deaths. The same real-time geopose of a vehicle or pedestrian could be shared and displayed in different systems including:

• a traffic visualization on a screen in another car,
• shown directly at its physical location in the AR glasses of a pedestrian that is around the corner for the car, or
• in the real-time world model used by an autonomous vehicle or delivery robot to help it navigate the world and avoid other vehicles or pedestrians.

​​​​​​

The Symbology Conceptual Core Model (SymCore) is the basis for defining symbology rules for the portrayal of geographic data. The model is modular and extensible (one core model, many extensions), and also encoding agnostic (one symbology model, many encodings).

The work by the SymCore Standards Working Group that led to this proposal was done as a continuation of the OGC Symbology Encoding standard (SE 1.1), only with a focus on modularity and extensibility.

SymCore provides a consistent approach that:

• Provides the flexibility required to achieve adequate symbology rules for a variety of information communities, e.g. aviation symbols, weather symbols, thematic maps, etc, and;
• Achieves high-level styling interoperability without encoding dependencies.

As such, Symcore defines a more general and portable symbology model for use across the broad OGC standards baseline that can be applied to geospatial datasets as well as online geospatial data and mapping services.

Potential implementations of SymCore are expected to enhance OGC standards such as the Web Map Service, Web Feature Service, GeoPackage, and others. By sharing a common core, and using the extension mechanism, integration of these standards for the purposes of cartographic representation could be greatly simplified.

Last year, authors of the SCCM standard requested early public feedback in advance of finalizing the candidate standard to ensure that the work was reflecting the community’s needs. This announcement marks the start of the formal public comment period as the standard moves towards adoption.

SensorML is a machine-readable language for describing sensors, actuators, and processes surrounding measurement. SensorML is a key component of OGC’s Sensor Web Enablement (SWE) suite of standards. SWE is concerned with establishing interfaces and encodings that enable a “Sensor Web” through which applications and services are able to access sensors of all types - from the commonplace sensors associated with mobile phones to high-precision remote sensing platforms such as satellites - as well as the observations generated by them, over the Web.

The primary focus of the Sensor Model Language (SensorML) is to provide a robust and semantically-tied means of defining processes and processing components associated with the measurement and post-measurement transformation of observations. This includes sensors and actuators as well as computational processes applied pre- and post-measurement.

The main objective is to enable interoperability so that sensors and processes can be better understood by machines, utilized automatically in complex workflows, and easily shared between intelligent sensor web nodes.

The recently published version 2.1 of the GMLJP2 imagery standard additionally supports SensorML descriptions, thereby giving GMLJP2 the ability to support “raw” sensor model imagery. Sensor model images are useful because they contain geospatial information that is lost upon processing into rectified ‘map’ images. Besides being processed into map images, sensor model images may be used, for example, for precision mensuration or to construct 3D models of ground structures. Such physical and replacement sensor model descriptions are being compiled into a sensor model repository by the OGC Naming Authority.

The SensorML v2.1 Standard specifies a means to create a general mathematically-based model for transforming an initial state (for example, the location and orientation of a camera) to a final state (the ground point of origin of the light entering the camera) via a serial processing chain. The standard also provides an associated XML implementation. The main change of SensorML 2.1 from SensorML 2.0 is the addition of setEncodedValues in both the standard and in the XML implementation to provide a method to more concisely encode arrays, as compared to setArrayValues.

The Open Geospatial Consortium (OGC) seeks public comment on the draft Charter for a proposed Blockchain and Distributed Ledger Technologies (BDLT) Domain Working Group (DWG).

Distributed Ledgers are collections of replicated, shared, and synchronized digital records that are stored across multiple sites. The technologies used to implement such ledgers (Distributed Ledger Technologies aka DLT) include the Blockchain, which is a digital ledger of records arranged into linked and cryptologically-validated chunks of data called blocks. By far the most widely cited application of Blockchain technology is in the finance sector where it can be used as a cryptocurrency, the two most notable examples being Bitcoin and Ethereum.

However, other applications for DLT and Blockchain are now gaining popularity. There is potential use of DLT in, for example, land registration, city services, space, pan-government registries, and justice. Location can play a key role in many of these application areas. For example: the location of financial transactions can determine what taxes apply; the location of the boundary of a property forms the basis of its registration; and the location where evidence is discovered in a crime scene can have an impact on judicial proceedings.

At present, there are numerous DLT services and networks available. There is however no standard for how those DLT should encode geospatial information such as locations, coordinates, and coordinate reference systems. The various DLT have therefore implemented ad hoc geo-encoding approaches. This situation is likely to lead to a problem of limited interoperability between information held in different DLT networks.

Given the immutable nature of Blockchain and DLT, the need for standardization of the information encoded within them is time-critical: any poorly encoded geographic information will remain inherent to a given ledger for as long as it is in use.

The purpose of the BDLT DWG is to build understanding of Blockchain and Distributed Ledger Technologies, as well as the potential requirements for geospatial standardization within those technologies. Further, the BDLT DWG will identify gaps and issues that should be addressed to improve geospatial standardization in Blockchain and DLT.

In October 2018, OGC published the Discussion Paper Geospatial Standardization of Distributed Ledger Technologies with the purpose of improving the understanding of Blockchain and distributed ledger technologies. One recommendation of the Discussion Paper was to form the OGC BDLT DWG.