I. Executive summary
I.A. Testbed background
Within the context of annual global energy consumption, buildings are one of the most significant consumers. Regionally focused, building related analyses are important in arriving at data driven climate change policy that reduces the overall energy consumption of buildings and provides other benefits to society. Policymakers need simple tools that enable them to conduct rapid visualization-driven assessments of how new or existing building related climate change policies will impact the energy and emissions profiles of the building stock within specific geographic regions (i.e. a city, or a province). The component geospatial and building energy datasets needed to build these tools are available globally from many sources, but the datasets exist in different political, data, and expertise domains. The lack of dataset interoperability and lack of communication between each dataset’s stakeholders results in duplication of effort, lost potential for energy savings, and lost opportunities for effective policy tools. Standards that enable interoperability of building energy and geospatial datasets would therefore address key barriers to integrated planning activities and tools for policymakers.
As the transformation to spatial computing continues, a key potential use case for data interoperability is the Canadian Geospatial Data Infrastructure (CGDI). The CGDI is an infrastructure for geospatial information. The CGDI concept is similar to the traditional physical infrastructure that helps Canadians with their everyday lives (e.g., roads, utilities, and telecommunications). The development of RESTful Web APIs, enhancements in the representation of 3D building data, and the growing availability of modeled energy data have allowed the rudimentary extension of some CGDI capabilities to be used within the domain of buildings and energy. Providing a fully functioning standards based energy and utilities component of the CGDI, enabled by interoperability and organizational communication, would go a long way to enabling municipal and utility entities to implement better energy and emissions policy and programs and work towards implementing Urban Digital Twins.
I.B. Testbed goals
The goal of the OGC Testbed-18: Building Energy Data Interoperability task was to address interoperability between geospatial and building energy datasets using existing OGC standards and where appropriate, fostering the development of new OGC standards. The task participants showed examples of the types of visualization tools that can benefit stakeholders and are enabled by Web API services that conform to OGC standards.
To accomplish those aims, the participants prototyped the components of an Energy Spatial Data Infrastructure (ESDI) that could become part of the CGDI and support the execution of building energy experiments and analysis – ideally using existing OGC Web API standards. Testbed-18 workflows attempted to use those components that implemented OGC Web APIs to build and access interoperable generalized data models containing geospatial and building energy data. The Testbed-18 Building Energy workflows focused on enabling the following stakeholder use cases.
Housing Retrofit Program Planning
Provide the geospatial tools governments and other entities need to be able to quickly look at the existing building stock within their jurisdictions and assess a variety of different building retrofit scenarios that support climate change related retrofit policy and program development.
Electric Utility Hosting Capacity Analysis
Enable utilities to perform hosting capacity analysis, which is an analytical approach that can help utilities and the jurisdictions they serve understand how the electric grid is geospatially-impacted by the connection of new or modification of existing energy sources and sinks.
I.C. Testbed tasks description
Testbed-18 tasked participants with exploring existing datasets available from the building and energy domains in Canada. The participants developed mapping and integration approaches that aimed to combine the provided and available data sets into a single data model. The intent of the single model was to enable the use of services and/or interfaces (components) compliant with the model data for the direct and simple analysis, simulation, and visualization of building energy and greenhouse gas emissions metrics without further integration and mapping efforts. The data were served and accessed via standard-based Web services that aimed to be compliant with the latest OGC Web API standards.
I.D. Testbed locations
The locations chosen by the Testbed-18 participants and Natural Resources Canada (NRCan), the Testbed-18 sponsor, were the City of Montreal, Quebec, Canada, and the Nuns’ Island neighborhood within it. These locations were chosen because of their publicly available geospatial buildings datasets.
I.E. Testbed data sources
The Testbed-18 participants had access to the following geospatial and building (energy) datasets relevant to the chosen locations:
Montreal agglomeration property assessment roll data (City of Montreal);
City of Montreal 3D buildings 2016 LoD 2 model with textures (City of Montreal);
geoindex shared platform (Province of Quebec);
City of Montreal digital terrain model (City of Montreal);
automatically Extracted Buildings (NRCan);
building, alteration and demolition permits (City of Montreal);
EnerGuide Rating System (ERS) database entries (NRCan);
Housing Technology Assessment Platform (HTAP) archetype files for HOT2000 software (NRCan CanmetENERGY); and
reduced HOT2000 File Representation (NRCan CanmetENERGY).
It is important to note here that although these datasets were provided, they were not all used within the Testbed activities.
I.F. Testbed activities
During Testbed-18 all data models and OGC standards compliant API implementations were demonstrated as prototypes that included several services and clients – the participant roles. Short descriptions of these participant roles and the Testbed-18 participants assigned to them follow in the table below.
|Building Energy Data Service (D122 and D123)||The Building Energy Data Service was a Web API instance that served building energy data according to the data models investigated in this ER.|
|External Geospatial Data Service (D127 and D128)||The External Geospatial Data Service was a Web API instance that provided access to geospatial data that was required for the applications offered by the Building Energy Processing Service (D126).|
|Building Energy Processing Service (D126)||The Building Energy Processing Service was a Web API instance providing access to applications that make use of the components D122, D123, D127, and D128.|
|Building Energy Client (D124 and D125)||The Building Energy Client applications accessed the other Testbed-18 web services and used them to provide stakeholder access to building characteristics and energy data through web and augmented reality interfaces.|
Different cases involving the prototype services and clients were explored in Testbed-18 though tracks of experimentation. These tracks both allowed parallelization of the tasks within Testbed-18 and the case-by-case analysis of different interactions between the services and clients. A summary of the participants, participant roles, and activities performed within each track follows in the table below.
|Track||Participants (Participant Role)||Description|
|Initial Processing Track||The initial processing track primarily focused on the development and implementation of different OGC compliant Web API services that attributed energy consumption to buildings given the provided source geospatial building characteristics data. As part of the track, a minimal viable product for building energy simulation using a given geospatial dataset as input was implemented for Nuns’ Island in Montreal, Canada. Energy simulation results were attributed to buildings in the Nuns’ Island dataset and offered to clients as a data model through Web API implementations.|
|Extended Processing Track||The extended processing track focused on a more generalized geospatial processing workflow using data from Montreal, Canada. While track one aimed to stand up services using only the available datasets (without dataset conflation), track two aimed to generalize that workflow to the entire Montreal geographic area. The conflation of the provided geospatial building and building characteristics datasets into a common data model and its provision to clients using Web API implementations was a key activity within this track. The track also provided building archetypes for the Province of Quebec through a standards compliant Web API implementation. Unlike the initial processing track, the extended processing track did not attribute energy consumption to buildings in Montreal.|
|Data Visualization Track|
(all Building Energy Client D124 and D125)
|The data visualization track documented the workflows towards consuming the outputs of the initial and extended processing tracks and displaying them through novel and innovative visualization tools. These visualization tools were a demonstration of how the utility and municipal planning use cases could be achieved when supported by underlying Web APIs.|
Expanding upon the above tracks of the experimentation summary table, the details of the activities performed by each participant within each track of experimentation are shown in the figures and tables below. The figures show the dataset (and processing) workflows performed within each track. The tables summarize, for each of the Testbed-18 participant activities (and their roles), the data used, the services provided (or used), and a general description of the activities performed within each track, as appropriate.
I.G. Initial Processing Track Summary
The initial processing track primarily focused on the development and implementation of different geospatial and building energy web services given the available data for Nuns’ Island, Montreal, Canada as show in the following figure and table describing the activities.
Figure 1 — The data conflation and example processing workflows for the Initial Processing Track.
|Participants (Participant Role)||Data and Services||Description|
|Steinbeis Consortium (Building Energy Processing Service — D126)|
|The Nuns’ Island CityGML LoD 2 dataset from the City of Montreal was cleaned and enriched with additional building characteristic information from the Montreal agglomeration property assessment roll dataset (building function, year of construction, building category, neighborhood name). A Simstadt energy simulation engine API implementing the OGC API — Processes interface was developed and deployed to attribute energy usage to buildings.|
|interactive instruments (Building Energy Data Service — D122 and D123)|
|An OGC API — Features compliant API implementation instance was deployed that further enriched the Nuns’ Island CityGML LoD 2 dataset with the building energy simulation results from the Building Energy Processing Service for Nuns’ Island. The applicability of CityGML Energy ADE and other data formats such as Mapbox Vector Tiles, FlatGeobuf, and glTF for the storing of the produced energy attributes was explored.|
|Ecere (External Geospatial Data Service — D127 and D128)|
|3D geometry for Nuns’ Island was made available through an implementation instance of the draft OGC API — GeoVolumes specification. The geometry was served as a 3D Tiles bounding volume hierarchy and implicit tiles. The attributes from the CityGML dataset were populated into a GNOSIS data store and made available through an implementation instance of the OGC API — Features specification. Collections were created using an implementation instance of the draft OGC API — Processes — Part 3: Workflows & Chaining specification and an adapter process to connect to an energy processing service that implements only the OGC API — Processes — Part 1: Core Standard.|
I.H. Extended Processing Track Summary
The extended processing track focused on a more general geospatial dataset processing workflow using data from Montreal, Canada. The following figure and table describe the activities.
Figure 2 — Data conflation workflow for Extended Processing Track.
|Participants (Participant Role)||Data and Services||Description|
|Steinbeis Consortium (Building Energy Processing Service -D126)|
|The activity built upon the Steinbeis Consortium’s work on the Nuns’ Island dataset during the Initial Processing Track but expanded it to cover the entire City of Montreal. Inputs from the City of Montreal CityGML LoD 2 (6 boroughs), Montreal agglomeration property assessment roll, Automatically Extracted Buildings from NRCan, and LiDAR data (Montreal DTM) data were conflated to synthesize a hybrid CityGML LoD 1 & 2 dataset for the entirety of Montreal.|
|interactive instruments (Building Energy Data Service — D122 and D123)|
|The activity provided an OGC compliant Web API to access the City of Montreal hybrid CityGML LoD 1 & 2 dataset. An API implementation was provided for accessing City of Montreal building data as 3D Tiles, Vector Tiles, and Features with multiple data encodings. An OGC API — Features compliant Web API implementation also provided access to NRCan housing archetypes taken from the HTAP Archetype Database for the Province of Quebec and offered in Reduced HOT2000 File Representation data format.|
I.I. Data Visualization Track Summary
The data visualization track documented the workflows that consumed the outputs of initial and extended processing tracks, displaying them through novel and innovative visualization tools.
|Participants (Participant Role)||Description|
|interactive instruments (Building Energy Client D124 and D125)|
The buildings in the Nuns’ Island dataset were joined with the results of the energy simulation provided by the Building Energy Processing Service (yearly and monthly heating demand as well as the specific space heat demand). The information was visually presented as styled buildings rendered in Cesium JS and MapLibre GL JS. Cesium JS was used to render the feature data provided as 3D Tiles 1.1 and glTF 2.0; MapLibre GL JS was used to render feature data provided as Mapbox Vector Tiles or GeoJSON using the MapLibre Style Specification.