What is gbXML

Overview

The core idea behind gbXML, is it provides the ability to describe multiple buildings that are somehow related (campus, property set) and located in the same climate region. Each building in the set can further be represented in a more detailed way (its geometry, zoning, airside systems, and waterside systems) along with other criteria that influence the overall energy consumption of the building (schedules of use, thermostat temperature setpoints, internal loads, materials and constructions).

Like any XML file, gbXML is nested. It is quite nested relative to some more simple XML formats. The format is governed by gbXML.org, which maintains an XML Schema Definition (XSD) that describes all of the current structure, naming convention, and requirements of a valid gbXML file. The current version of the XSD is 5.11. If you would like to see changes to XML, please email me at [email protected] and if approved by the board, the changes will be added to the XSD and released to the public after approval.

If you would like to learn more about gbXML and its work in making data analysis easier for energy modeling, visit here.

Concepts of gbXML Tree Structure

If you were to open a sample gbXML file today and read the file with your eyes, the basic gbXML structure is a series of containers:

• gbxml
  • Campus
    • Building(s)
      • Space(s)
        • with deeper nests...
    • Surface(s)
      • Opening(s)
    • Construction(s)
    • Layer(s)
    • Material(s)
    • Meter(s)
    • Zone(s)
    • Schedule(s)
    • Result(s)
    • DocumentHistory

Each of these levels in the tree are different descriptions of a composition of buildings. You may have some familiarity with these sorts of items to describe a building or set of buildings.

This tree structure is not intended to be a definitive list of all the elements in a gbXML document, just to give you a sense of the level of nesting and the flavor of information. We only note the deeper nests inside spaces and surfaces just to give you an overview of the nature and intensity of nesting. All of these elements in the document are in reality further nested, the space and surface elements are the most nested of all elements. Also, how it is composed and organized. Where we put (s) at the end of the category, this implies that an array of these elements can exists.

Take note of the fact that surfaces, constructions, schedules, etc are not declared inside the building description. They are standalone. This basic structure of gbXML can confuse people, because many items that may conceptually belong inside an individual building exist at the very end of the document. These items can exist standalone in the document, connected to the building description by a shared identification attribute. This way, it is possible to re-use elements like this over and over again on different projects, or to reuse the same elements in different buildings. It is one way that gbXML tries to stay flexible for the people who use it the most and can appreciate that convenience. But it does seem counter-intuitive from a first glance at the document structure.