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.