In the introduction to GAEB, you learned about the Who and the Why of the format. If you want to dig deeper into the technical details, you'll learn here the differences between the GAEB versions.
Tip: Do you want to work with GAEB? Then take a look at the GAEB & AVA .Net Library to get an easy interface to work with all GAEB types.
Three Different Formats
The GAEB format has existed for multiple decades now. It has been continually improved to adapt to growing customer demands, offer more functionalities and leverage modern IT technologies. Currently, there are three distinct formats in use.
The sample files you are about to see match the following service description:
True to its name, GAEB 90 received its last major overhaul in June 1990. Similar to other data formats of its time, like ISYBAU, the file structure is based on the punch card format (from 1974) - it consists of lines that are all exactly 80 characters long.
The structure is hard to understand if you do not know it's exact specification. The first two letters in each line indicate the line type, the last six digits stand for the line number and everything in between has a specified meaning. For example, line type 25 - Short Text marks all letters on position 3 through 72 as text content.
There are two main advantages to using GAEB 90: The format is compact and storage efficient, and virtually any software with a GAEB interface does support GAEB 90. However, there are many, strict limitations in the format when it comes to conveying bills of quantities. Still, it is by far the most used format of all GAEB versions.
Here's the example project in GAEB 90:
Following the naming tradition, GAEB 2000 was specified in the early 2000s. It's design aims included to create an easier to parse structure while also lifting a lot of the restrictions present in GAEB 90.
That time saw the XML format becoming more and more popular, and so a similar-looking yet different structure was chosen. In GAEB 2000, elements are wrapped in #begin[Text] and #end[Text] tags while the actual content lies in between. This allowed for some self-describing capabilities in the format, making it easier to understand the file content without having to know the exact specification. The feature set was massively expanded, now even containing definitions for project schedules and commerce contracts. While the data size increased in relation to its predecessor, this did not have a huge impact thanks to growing capacities in computers and especially storage.
Nonetheless, GAEB 2000 could never really reach widespread adoption. The main reason probably was that GAEB 90 was simply enough and there was little pressure to upgrade. Now, with the advent of BIM and accompanying growth in customer expectations, there is already it's successor, GAEB XML. The small adoption of GAEB 2000 might also have been due to some technical barriers, as for example the used Rich Text Format (RTF), which allows formatted texts, is a proprietary solution that never had huge support by software tools and was way outclassed by HTML.
The following depicts the example project in GAEB 2000. Please click the arrows at the bottom to fully expand it or view it directly.
The latest iteration is called GAEB XML. Actually there's not just a single GAEB XML standard but multiple versions. While the initial one, GAEB XML 2.0, was basically just GAEB 2000 mapped to XML, it was soon followed by the first, radically new version 3.0 in 2004, then 3.1 and finally, since 2013, 3.2.
Among it's many new features were the change in the data structure to English names, which made it easier to be used outside of German speaking regions. Additionally, elements within a GAEB file can now finally be uniquely identified, which is especially important in BIM and its connection of data from various sources.
From a software developers standpoint, working with GAEB XML is much easier than with the other formats. The definition files are made available in consistently high-quality schema definition files that are maintained by the standardization organization.
The following file depicts the example project in GAEB XML format. Please click the arrows at the bottom to fully expand it or view it directly.
Challenges when Working with GAEB
GAEB offers many benefits for the end user, that's why modern work flows are unthinkable without it. From a software developers point of view, however, things are not as easy. Due to the long history of the format and it's many different versions and features, it's quite a challenge to fully support it. Another burden is the many different implementations of GAEB exporters in use today, where some of them do not adhere to every bit of the standard. Experience shows that there are a lot of incompatibilities, schema violations and deviations in "files in the wild".
Do you plan on working with GAEB, without having to invest months of up front development time for the creation of a stable module? Then take a look at the GAEB & AVA .Net Library. The code is available in C# and is offering an easy interface to work with any GAEB files. Thanks to .NET Standard, it's available on all platforms - no matter if on the desktop on Windows, Linux, Mac, in the cloud or on mobile devices. Take a look at the example code!
Do you have more questions regarding GAEB? Do you want to support GAEB in your own application? Do you want to use GAEB in modern BIM tools oder simply analyze your data? Don't hesitate to contact us!