Standardisation and minimum interoperability

  • Share on Pinterest

Standardisation and minimum interoperability

  • OASC objectives include a definition of the MIM from different perspectives as the best balance between general-purpose interoperability and municipalities’ needs.
  • minimum implementations can mean different things, but the model shall be simple while not general-purpose kv database, inclusive, and open for specializations and extensions both in domain-specific, technical, and social dimensions.
  • OGC suite of standards is the materialisation of the world-class models covering geolocated data collection, exploration, and discovery that are aligned with other models and open for extensions.

Smart City ICT enabler

The idea of Smart Cities pops up in more and more visions that link various applications to make urban life and business more effective and enjoyable. Most of these are based on digitisation and the growing number of municipal and private data streams. Quickly, however, the heterogeneity of the data brings complications and challenges during its integration. Creating data interoperability can be addressed at various levels, including normalisation of structure or metadata, architectural layering and translators, and standardisation. The choice is a matter of sustainability, openness, and available resources. By nature, OGC standards, being global and cross-domain, are generalistic and inclusive. Stakeholders can not only influence and observe the workspaces but also combine, extend, and profile standards. Tailoring allows them to address their specific use-case while preserving support on the basic level between tools and systems. This can be a costly effort, however, requiring specialised knowledge and available capacity. Further, it may also be redundant work in common across multiple cities.

The Minimum Interoperable Mechanisms (MIM) promoted within the Open and Agile Smart Cities (OASC) aims to address interoperability at the technical and semantic levels. The idea is to identify the most effective minimalistic model as a cornerstone of information exchange within a municipality and between cities. Because the problem goes deeper than the open data concept, it is only partly covered by the guidelines and directives like INSPIRE. Still, it should be a matter of choosing the suitable suite of standards and the links between them. However, this is often easier said than done, especially as the problem has several dimensions.

Notably, most urban data is geolocalized, so it is reasonable to use its geographical context in time to unlock otherwise hidden relationships between data. It is the enabler of the Twin Cities concept, where a dense urban environment digital representation is meaningless without precision location. Naturally, not all the needs require the same models, for example counting attendees of an event vs simulating a virus’ spread at that event. Nevertheless, it is linked and has a minimum common part that can be extended. That is also the area of OASC MIM thread (MIM7-Places), which tries to find a balance between completeness and efficiency of the geospatial sharing policies.

While the right choice between standardized approaches is a challenge in itself, it is also worth knowing how the standards work together. Happily, shared best practices pave the way for multiple standards, and convergence can be observed from that perspective.A good example is a feature defined in the W3C/OGC Spatial Data on the Web Best Practice document, GML, GEOJson, etc. appears in various standards and recommendations.The same data can be viewed from different perspectives. Here, the example can be an Earth Observation, which focuses on specific types of fat data processing. But satellite sensors are just like any other IoT, it is helpful to have the profile of the ISO/OGC Observation and Measurement. The ISO/OGC standard compliance ensures the common critical information to augment with Sensor Things API, SNN, and SOSA data is provided.

Various dimensions

The Data Consumer perspective

Naturally, the starting point should be defining the purpose of the data sharing policy as well as its target audience. The perspective varies a lot from case to case. The architect should be aware if the user specializes in detailed GIS data (and which), or is a developer of consumer-facing applications, or even both.

The incredible adoption of geo-portal technology was enabled both by embracing the concept of open data and the standardised, simple-to-use implementation on the map engines. It proved that most end-user app developers do not need to know cartography and legal constraints to build navigation apps – that is, if there are commonly available competing tools with standardised stack and specialistic models embedded.

Direct use of the specialised standards can be, on the other hand, required for the Digital Twins core design and implementation. Modeling city facilities on the natural terrain and combining it with the observations and physical models is far more complicated than GEOJson can represent. It is also worth remembering that the quality of the source data will only be as good as the general model or the check-in processes enforces and allows. However, a balance also needs to be struck so that it doesn’t become so complicated that it unintentionally limits unforeseen but valuable datasets in the future.

Resolution (from imagery to statistics)

The variety of data also introduces challenges related to data resolution. For example, field operations of the SCIRA project need more accurate, online data, including video transmissions. At the same time, centralised data hubs require interconnectivity between data streams to ensure coordination of the services and data exploration and aggregation. For such a case, a solution designer should consider the implementations that support federation, customisable data transfers between hubs, and on-the-fly transformations.

Protocols and encodings

On the technical side, we shall not forget that standards that work well for high-end devices can be inadequate for the lightweight sensors and the system itself. The transfer bandwidth, latency, and accessibility (well known in the telecommunication as QoS elements) heavily influence transport considerations and the logical models. For desktops and mobiles, one can use general-purpose HTTP. At the same time, both light sensors and high bandwidth transmissions work better with queue-based or stream protocols like MQTT or RTSP. The optimal solution abstracts the logical models and supports the transport protocols and encodings that best fit.

Figure 1. The ability to integrate various data types and sources is enabled by common and comprehensive geospatial models

Model augment ability

Finally, any selected techniques need to be easily integrated with existing legacy (and future) systems. The geolocation model should be adequate and extensible. The lightweight core model should be informative but also easy to understand and manage. In addition, it should be open for free extensions to integrations with other domain standards. An example of the successful integration of OGC standards and IFC for Building Information Models (BIM) can be found in the Future City Pilot Phase 1 public report. It contains lessons learned from the practical implementation experiment and recommendations for improvements.

Additionally, indoor mapping can leverage relative location models where door number is more important than the geographic location. Followers of the idea shall consider how the emergency indoor symbology NAPSG data can augment OGC CityGML. Such an Application Domain Extension was tested in the OGC Indoor Mapping and Navigation Pilot: Public Safety Features CityGML ADE.

Cross standards platforms

Several examples of end-to-end integration models prove that open ecosystems, while valuable, are not simple. Multiple producers and consumers connect at numerous places in various ways for multiple purposes. In the future, complexity will likely increase with advanced use-cases and new technologies entering the market. Opening the platform increases the usefulness of the system, leveraging the potential. At the same time, it also lowers the barrier to entry and minimises the risk of vendor lock-in for both sides of the integration. The model architecture proposed in the OGC 3D IoT Platform for Smart Cities Pilot shows the way it can be done. Its fit-for-purpose integrated environment provides a cross-silo, open ecosystem simply by implementing the OGC SensorThings API, CityGML, WPS, WFS, and 3D Tiles (OGC 3D Portrayal Service) Standards.

Figure x. 3D IOT Platform for Smart Cities Pilot CityThings concept
The OGC® Sensor Web Enablement (SWE) and OGC® SensorThings API (Application Programming Interface) standards were used in the SCIRA Pilot to support the central sensor data hub. These standards provide an interoperable approach in support of virtually any sensor system. In essence, the suite of OGC SWE and OGC SensorThings API (STA) standards provides standardised means for discovering sensors, tasking sensors & actuators, requesting robust descriptions of sensors & sensor observations, and for accessing real-time or archived comments and messages. Those standards can support sensor systems in a Cloud environment, within a field hub, or as part of the sensor itself or on the sensor platform (“on-the-edge”). See [1] for details.

The challenge is to further evolve the standards based on the lessons learned and efficiently tailor the suite of standards’ profiles and extensions. The sweet spot between generalistic models and highly specialized ones can lie in the minimum cornerstone. That would allow for smooth integrations and exploitation on any sound touchpoint and provide required validations. Most probably, it is beyond the general-purpose key-value database and ensures common basics of understanding. On the other hand, it is easily connectable to other models and not too complicated on a typical level. It can be detailed to the highest reasonable level for narrow specialists.

About OGC

The Open Geospatial Consortium (OGC) is an international consortium of more than 530 businesses, government agencies, research organizations, and universities driven to make geospatial (location) information and services FAIR – Findable, Accessible, Interoperable, and Reusable. OGC members form a global forum of experts and communities that use location to connect people with technology and improve decision-making at all levels. OGC’s member-driven consensus process creates royalty-free, publicly available geospatial standards. Working at the cutting edge, OGC actively analyzes and anticipates emerging tech trends. It runs an agile, collaborative Research and Development (R&D) lab that builds and tests innovative prototype solutions to members’ use cases. OGC is committed to creating a sustainable future for us, our children, and future generations.


[1] OGC SCIRA Pilot Engineering Report

[2] OGC 3D-IoT Platform for Smart Cities Engineering Report

[3] Future City Pilot Phase 1

[4] OGC® Sensor Web Enablement: Overview And High Level Architecture

[5] OGC SensorThings API

[6] CityGML