Buildings, dwellings, and other structures that provide us with indoor living, working, or storage space are the principal components of the built environment and also the top of the pyramid of infrastructure and services that make up that environment. Data about buildings has many uses, from mapping and property information to infrastructure protection and energy conservation. Many of these uses benefit from availability of standardized, comparable building data at national or even international scales. This report specifically details existing geospatial data standards and standardization efforts that pertain to the design of national building information layers in Canada. The report may also be relevant to building information standardization elsewhere in the world.

Existing representations of buildings and building structures cover a very wide range of level of detail and depth of information, from simple points and rectangles for mapping purposes, through specific ownership and addressing information for cadastral purposes, to detailed 2D and 3D design and model information, even dynamic "digital twins" that represent a building’s current status and operation.

The following terms and concepts are useful in describing these different degrees and types of representation.

There are a wide variety of possible use cases for building data that each benefit from particular building representations, attributes, level of detail, related entities, and data quality. Data standards are agreements on how at some level of specificity to model and encode data. The more broadly they can address requirements for data exchange and compatibility across a greater variety of use cases, the more utility such standards can have.

One categorization of some 284 use cases collected from various Canadian government agencies ( 2019/20 NBL Consultation Results) might include:

Use cases in these categories identify at least 174 building attributes of interest, but likely also involve differing building representations, levels of detail, and other design criteria for applicable building information elements. The applicability of data standards likely differs across these categories too, with more general standards having broader relevance, and more specific standards pertaining to smaller groups of use cases, but not necessarily bound to these particular categories.

Descriptions of standards in the rest of this report have been categorized according to their generality, what aspects of buildings they pertain to, and to some extent what form they take as data.

https://www.ogc.org/standards/sfs

This standard is the most direct implementation of the fundamental ISO TC211 standards for 2D geospatial feature data, incorporating feature identity, feature schemas, and locators such as (simple) coordinate geometries in 2D and 3D space. This is the basis for most database storage of geospatial data layers and is itself an ISO standard (ISO 191251-1 Common Architecture and 19125-2 SQL).

https://www.ogc.org/standards/gml

GML is an implementation in XML Schema of the same ISO conceptual feature model standards as SF-SQL, but covers much more ground and is also a separate ISO standard(s) (ISO 19118 Encoding Rules and ISO 19136 XML Schema). GML is essentially a toolbox or application schema language for creating specific feature data schemas or specialized profiles. An important characteristic of GML, elaborated in the General Feature Model, is that feature geometry is considered an attribute of a feature, not the definition of it. A given feature such as a building can have a single identity but be represented in data by multiple alternate geometries, allowing the choice of an appropriate geometry according to scale and application of the data.

These general standards specify the design and encoding of information about features and objects in the built environment such as buildings and infrastructure.

https://www.ogc.org/standards/citygml

CityGML through version 2 is an extensible GML application schema that models a great variety of elements of the built environment as children of CityObject. An important part of CityGML is the capability of defining extensions (Application Domain Extensions) that represent more specialized parts of the city infrastructure such as utility networks or more specialized attributes such as urban energy simulation data.

CityGML v.3 was approved by OGC in early 2021 and is based on its own conceptual model that contemplates implementations not solely based on GML (e.g., JSON). It introduces concepts and constructs such as Spaces in order to improve compatibility with other built-environment standards such as IFC and LandInfra, as well as dynamic elements that incorporate live sensed attributes into city objects.

https://www.ogc.org/standards/landinfra https://www.ogc.org/standards/infragml

LandInfra is a conceptual model implemented as a GML application schema (InfraGML) that focuses on land parcels, ownership details, surveys, and linear facility alignments such as railroad structures. It does also define facility entities that are not specific to buildings, but can be used to connect building structures with land units and ownership interests.

https://www.buildingsmart.org

Industry Foundation Classes are a suite of standard specifications developed by buildingSMART International for interchange of datasets that make up BIM (Building Information Model) instances. IFC is essentially a common subset of vendor-specific building models such as Autodesk’s Revit, Bentley’s Microstation DGN, Graphisoft’s Archicad, or Trimble’s Tekla. Some vendors such as Dassault are now, however, supporting IFC natively on their platforms. IFC and CityGML have considerable overlap in coverage, but typically divergent representations (e.g., unique geographic features in CityGML vs. parametrized assemblies in IFC). A joint committee (IDBE)between OGC and buildingSMART International has made progress to increase the overlap or correspondence between CityGML, LandInfra, and IFC, but direct round-trip data conversion between any two of the standards will likely remain limited for the foreseeable future.

A number of standards cover the types of data typically involved in sensing the characteristics of geographic features such as buildings.

https://www.ogc.org/standards/LAS

This standard, adopted by OGC as a Community Standard from ISPRS, is a compact format for the point cloud and signal data derived from LIDAR scan surveys. LIDAR is a common method for observing the 2.5D form of the Earth’s surface in very fine detail. LIDAR point clouds conflated with corresponding imagery can be used to visually and geometrically represent buildings directly. They are also commonly processed to extract building roofprints and even some roofing details such as gables and roof exposures.

https://www.ogc.org/standards/om

https://www.ogc.org/standards/swecommon

https://www.w3.org/TR/vocab-ssn/

The three standards above are core for the information needed to characterize the process of making sensor observations and applying the results as feature properties. The O&M conceptual model defines objects and relations pertaining to the observational process. SWE Common provides an encoding standard for observational data, while SOSA-SSN, a joint OGC-W3C product, is a modular OWL ontology built on and extending the O&M specification.

https://www.gs1.org/standards/id-keys/gln

Management and interchange of global feature identifiers is a significant challenge in any large-scale heterogenous domain, particularly in order to make sure that in each identification scheme, each feature is referenced by one unique identifier. the GS1 standards organization provides the GLN (Global Location Number) specification that can be used to manage the identities of locations and facilities / buildings at potentially a global scale by means of ID keys.

Structures standards specify minimal information about built structures of any type, primarily for the purpose of 2D mapping and as part of general spatial frameworks.

https://usgs-mrs.cr.usgs.gov/SPECX/treeview/index

This link provides access to ArcGIS-specific data dictionaries that define the TNM schemas "Struct_Point" and "Struct_Line". There are links in the Struct_Point schema (Foot_ID and Complex_ID) to feature classes Structure_Footprint and Structure_Complex encode more detailed building geometries but include no more involved building attributes than area and perimeter length. Building information in this model is spread among 4 different tables due to the ArcGIS limitation of one geometry type per table / feature collection.

Besides providing various structure geometries for rendering in USGS topographic maps and assorted metadata about data loading and access rights, the Struct_ schemas focus on a handful of structure properties that are characteristic of other TNM feature data as well.

https://www.usgs.gov/core-science-systems/ngp/tnm-corps/structure-definitions https://navigator.er.usgs.gov/help/WebHelp/structure_def_table.pdf

These tables provide detailed definitions of the various types of buildings or other structures defined by the Struct_ data dictionaries and denoted by FCodes, for example what is and is not considered a cemetery.

https://www.fgdc.gov/standards/projects/FGDC-standards-projects/RPADS/

This minimal data content standard is maintained by the General Services Administration, owner and operator of all U.S. Federal properties. It categorizes a real property asset as a building, land parcel, linear structure, or structure, provides a Federal identifier, name, and address, along with one or more simple geometries (point, line, polygon).

Spatial Data Standards for Facilities, Infrastructure, and Environment https://www.sdsfieonline.org (requires login account)

SDSFIE are a family of US Department of Defense data standards for definition and interchange of geospatial data specifically for installation, environment, and civil works missions. The SDSFIE-V| 4.0.2 standards for vector feature data as adapted for the U.S. Army include application schemas for these features:

LandParcel, Structure, and Building (along with Site) features actually share a number of "real property" attributes, especially a Real Property Site Unique Identifier (rpsuid) which is able to link these collocated features together in a database. In fact there are few differences between the definitions of Structure and Building, except that for some reason Building includes a "Proposed Demolition Date" property and Site does not.

The data standards in this category pertain specifically to buildings as distinct from non-building structures such as pipelines; they define generally 2D properties and geometries that are specific to buildings and building parts.

https://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_BU_v3.0rc3.pdf

The INSPIRE building data standard provides a conceptual model and various levels and/or types of detail through 4 profiles with implementations in CityGML, including BuildingsBase, BuildingsExtendedBase, Buildings2D, and Buildings3D. The profiles are defined by means of an inheritance hierarchy of structure types. Figure 13 shows features and building specific properties in the BuildingsBase schema. An AbstractBuilding inherits attributes from an AbstractConstruction class and adds building-specific attributes such as "BuildingNatureValue" and "currentUse". It is then realized in both Building and BuildingPart classes.

The base profile is extended with either 2-2.5D geometries or 3D geometries, as well as additional attributes to fill out the 4 profiles shown in Figure 14.

The BuildingsExtendedBase adds feature types for "OtherConstructions" for structures not considered buildings, "Installations" for small building additions, and "BuildingUnits" for independently accessible building parts. Mainly, though, it adds additional building attributes, as shown in Figure 15. Some of these relate to utility network hookups but only as boolean (yes/no) attributes.

There is no explicit reference to cadaster or the parcels on which buildings might sit, but there is acknowledgement of the connection in the guidance that the externalReference property can be used to reference "the cadastral register where information about owner, tenant, criteria of valuation (heating, toilet, …​) may be found." This is illustrated in Figure 16.

https://nsgreg.nga.mil/nas/

Although the U.S. National Geospatial-intelligence Agency is technically part of the defense establishment, it has developed its own extensive standard feature application schemas for worldwide mapping and reconnaissance operations (NSG Application Schemas), including for a number of structure feature types such as buildings and ruins. The extensive lists of attributes for NSG Buildings include general ones such as "Floor_Count" and ones highly specific to intended uses such as "Helipad_Present".

https://irma.nps.gov/Datastore/Reference/Profile/2252776

NPS has published its own data standard for data it needs to manage or at least keep track of describing buildings on NP properties. Building attributes in this standard include their own building type codes, drawn from a large list maintained by the Department of the Interior. Notable also are the distinctions between the building owner, maintainer, and occupant. The data standard also includes many attributes which are links to data about the building in a variety of other special-purpose databases, such as the National Fire Database for Buildings. The data standard clearly recognizes that information about a given building structure is maintained in many different locations and defines foreign key fields to relate them together.

https://www.ogc.org/standards/landinfra https://www.ogc.org/standards/infragml

As noted under its Base Standards description, the LandInfra does include a Facility entity connected to other LandInfra concepts such as LandDivision, Survey, Alignment, Road, Railway, etc. From this perspective, the LandInfra Facility is useful for representing different facilities involved in infrastructure and earthworks projects. The LandInfra Facility schema is shown in Figure 17.

The LandInfra Facility model is similar to the INSPIRE (and IFC) model in supporting both Facility and FacilityPart. Specific support for building data, however, is only by way of a FacilityPartType codelist. The GML encoding of LandInfra (InfraGML) is fairly agnostic to the type of geometry used to represent LandInfra entities, but in practice is usually limited to 2D or 2.5D geometry types.

Standards in this category apply specifically to digital model data intended to represent the 3D shape, elements, configurations, systems, etc. of a real building. They can be characterized broadly as building model application schemas drawn from more general built environment modeling standards such as CityGML and IFC.

The INSPIRE building standard introduced in the previous section is also an example of a building model standard, leveraging CityGML to represent buildings in 3D with potentially high levels of detail.

Organization and digitization of information about buildings and civil engineering works, including building information modeling (BIM)

This ISO subcommittee is associated with 14 published standards and 8 more in development, all pertaining to building data and specifically to building information models. The standards that this group develops are generally concerned with business processes and practices around BIM, though, and so far have not developed specification that would be directly applicable to development of a national building layer schema. ISO 19650-1:2018 does describe, however, concepts and principles around the use of BIM to organize building information.

Reference https://www.nationalbimstandard.org/nbims-us

A US national BIM standard has been developed by the National Institute of Building Sciences. This standard focuses on defining many building types according to either their physical form, such as "Low-Rise Free-Standing Slab Building" or their functional usage such as "Agricultural Research and Development Facility".

https://standards.buildingsmart.org/IFC/RELEASE/IFC4_1/FINAL/HTML/schema/ifcproductextension/lexical/ifcbuilding.htm

The IFC specifications also include a class of IfcBuilding that defines a number of attributes relevant to the positioning, design, and construction of buildings. The principal function of IfcBuilding, however, is to serve together with IfcSite, IfcStorey, and IfcSpace as the hierarchical spatial framework for IFC elements that comprise the building structure. This is illustrated in Figure 18 from the IfcBuilding specification.

The attributes for IfcBuilding are shown in Annex A of this report. They are drawn from the rather deep inheritance tree for IfcBuilding shown in Figure 19. For example, the attribute "ContainsElements" is defined in IfcSpatialElement but "FireProtectionClass" or "OccupancyType" are only defined for IfcBuilding itself. Some attributes may be directly applicable to energy analysis, such as "BuildingThermalExposure".

While IfcBuilding would be complex to use as a standalone data model, several capabilities of both the class and of IFC itself could be useful. For example, IFC Property Sets have been specialized for buildings to generate a substantial list of extended building and building part attributes such as in Pset_BuildingCommon.

This illustrates a design pattern of extensions that consist of linked property sets as an alternative to additional / specialized full model entities.

Focusing on the issue of building attributes / properties, the standards in this category define and organize concepts for specific building aspects such as energy efficiency. Both of the standards in this category are organized as OWL ontologies. This means they leverage RDF triples to represent relationships between concepts and and may include OWL axioms that determine conformance of the ontology to specific description logics, e.g., potential use in machine reasoning and validity of open-world assumptions. Ontologies rely even more strongly than other models on globally unique systems of identifiers for both concepts and individual instances of them, usually in the form of IRI’s. As collections of terms, they can be fairly easy to use, but ontologies as sets of consistent logical statements are only defined in OWL within the scope of documents. This makes it tricky to determine the logical scope of models that pick and choose concepts from existing ontologies. In many cases, it is more robust if inefficient to follow the patterns laid out by existing ontologies rather than including them directly in a new model.

https://brickschema.org/ontology/1.1

Brick is described as a uniform metadata for buildings or an extensible dictionary of terms and concepts around the physical, logical, and virtual assets in buildings and their relationships. Although the descriptions avoid the word, Brick is in fact defined as an OWL ontology and asserts some compatibility with the BOT ontology described below. Brick’s focus is to define functional relationships between building elements that in a sense build on the structural relationships that IFC defines or spatial relationships represented in CityGML.

Root classes in brick include Equipment, Location, Point, Tag, and Measurable. Relationships include specific functional ones such as "regulates" but also quite general ones that overlap with many other standards such as "hasPoint". Brick:Building is defined as a specialized subclass of brick:Location as shown below

This class serves mainly to define relationships with materials from which the building has been constructed and devices by which it "operates." Useful model design patterns in Brick include Tags and a rich set of relationships (predicates) between concepts. Individual Brick instances (models) may leverage the rich predicate axioms available through OWL but few of these are defined in the Brick ontology itself.

https://w3c-lbd-cg.github.io/bot/

This W3C community group effort is also organized as an OWL ontology that in this case describes "core topological concepts of a building." BOT focuses on the spatial (e.g., enclosedBy), topological (e.g., linkedTo), and mereological (e.g., partOf) relationships, rather than the geometries, functional relationships, or extended attributes that characterize some of the other standards described in this report. It is also clearly intended to integrate or mediate between other building model schemas and includes a set of alignment modules for this purpose.

BOT is clearly a developing specification and intended to be a core vocabulary with which to build more complete models. It’s usefulness will depend a great deal on the viability of a semantic approach to building models, which does not yet seem to have been demonstrated at any scale.

https://bedes.lbl.gov/bedes-online/category/premises?page=1

BEDES is the one standard covered in this report that focuses on building energy related characteristics and energy usage data exchange. While developed by Lawrence Berkeley Labs, its primary sponsor has been the U.S. Department of Energy. Its primary manifestation is a dictionary of terms and definitions, available as a searchable dataset, or as a list in generic XML / CSV form. It’s applicability to building data schemas is only made apparent in a set of mapping spreadsheets that indicate some of the building attributes the dictionary terms should be applied to. Mapped entities include "premises", "envelope","HVAC", and "Generation and Storage Equipment".

These entities and attributes probably belong in a core building data package. Three other entities besides "Building" help to represent different perspectives as well as cardinality:

This can also be considered the core of a more widely linked system of building data.

This extension would provide a simplified 3D extrusion +/- roof detail of a building’s outer skin to support various parameters of designed and measured environmental interaction

This extension would add a more or less detailed 3D building model encoded in CityGML and/or IFC, with SiteFacility elements drawn from LandInfra. This would provide the entities and attributes to support the dynamic elements of building operations.

This extension would build on the 3D model extension to add dynamic evolution of utility commodities and environmental interactions.

This extension would focus on those BuildingPart attributes relevant to building energy analysis and modeling

This extension would most likely include details concerning the ownership and operation history of a building and/or site. This becomes relevant to a national building layer when looking at patterns of environmental contamination, construction code issues, or evolution of building conditions.

Building data standards do seem to fall into a few specific categories, depending on their target use cases. Mapping use cases minimize the represented information. Cadastral use cases focus on value and regulatory conformance. Economic development and operations use cases look at how sites and building fulfill their intended functions. Analytical use cases look to incorporate critical process elements and modeled or measured performance attributes to look at. Most of these use cases do not necessarily need to be implemented at a national scale, so a module / linked approach has value in right-sizing the data collection and management effort at the scale that is needed.

This report reviewed standards and specifications for digital building data applicable to development of a national-scale building data layer. Standards were considered in several categories:

Many commonality are to be found in the attributes used by these standards to represent building data. There are fewer connections between the perspectives represented by these standards categories, i.e., cadastral parcels standards rarely address building structures per se and buildings standards rarely address the sites on which buildings are located.

An informal synthesis of the presented models does point at a relatively small group of core attributes for buildings and other key entities. Extensions to such a core can be efficiently utilized in order to add or link from more detailed data required for specific advanced but timely additional use cases.

As discussed above, the coverage of needed building information by any single reviewed standard is relatively poor, as they have generally been developed for specific usage scenarios. The standards directed at national scale building stock coverage have generally focused on putting buildings on a map, not putting models or policies in place.

There is also a gap between standard all-in-one data schemas that have few and brittle links with other collections of building-related data and the ontologies that are being developed to represent building structures and systems but still are pitched to a relatively high conceptual level. This gap could be filled with specific linked data approaches to solve decentralization challenges with comprehensive but patchy building data that are useful immediately but able to evolve into more complete semantic web systems.

It is clear from this work that many data standards apply to this challenge of a national building data layer but none completely encompass it. This is certainly an opportunity to continue harmonization and modeling work, followed by prototyping activity to develop an appropriate standard for building data. Such a standard could facilitate interchange and integration of building data at a national level as well as comparability of building stock data at regional levels.