All posts in IFC

Developing GDL – the big picture

While still in the process of actually buying Archicad, I’ve managed to get hold of a demo version, to try it out for myself. My first accomplishment was a neat little house with doors, windows, a stairway and even a toilet, firmly guided by a tutorial.

My first Archicad drawing

After this first and somewhat successful encounter, I started exploring the GDL scripting language, its capabilities and editing environment. I had my hopes up for a somewhat BASIC scripting language, but still powerful and efficient for its purpose. This seems to be true so far.

What I didn’t expect was this incredibly lousy editor. Unfortunately it’s as simple as that. Archicad ships with a built-in GDL editor that, to my great frustration and sorrow, is the worst piece of inconvenient half-done crap, I as a programmer could imagine. I’d rather edit my GDL in M$ notepad, and that should say something about the quality of the editor!

My first GDL object

I’ve been browsing for other editors, and since I had a hard time actually believing what I saw, maybe for some answers to the quality of the built-in editor. I came across the ArchiCAD-Talk forum, where Archicad users where discussing newly proposed GDL coding guidelines from Graphisoft, that among others, suggests that commands are written lower case (commands has, like in BASIC been written upper-case so far):

Case, indents and comments are the only tools we have to make scripts readable. I see no reason to promote a standard which abandons one of these features.

… and the talk goes on with wishes for line numbers, syntax highlighting and auto indentation.
The discussion is from 2004, but nothing really seems to have changed since then.

I have been programming C, Java and C# for a couple of years, and for my part, the tools I use are of the essence. I’ve been used not only to syntax highlighting and auto-indentation, but to auto-completion, tool-tip help and code snippets that help me code the trivial tasks faster and more efficient. This GDL-editor is like returning to DOS, writing .bat scripts with edit – *sigh*.

My hunt for other (and better) editors has resulted in the following:

One editor being used is the 3nf GDL scripter. It has syntax highlighting and line numbers, but the website has not been updated since 2004. I’ve tried it on my XP SP2, and it keeps crashing. Further, if I open an object in ArchiCad made with GDL scripter, I’m issued a warning, that this object is made by an external editor and yada yada yada – certainly not a message I want my customers to be met with.

Then there’s a GDLedit highlighting plugin for a number of editors, including vim and emacs. This could be used for editing the GDL scripts in an external editor, and copy-paste it to Archicads built-in editor.

That’s it. No more editors as far as I can see (let me know if you know any!) – This leaves me somewhat depressed.

Now, why would Graphisoft, a company that has invested so much effort in parametric objects and BIM, abandon the project like this?

Daddy is not angry, daddy is disappointed.

I’ve heard so much about the wonderful GDL-society and the good-spirited, open-minded and ambitious people populating it. But all I find is dead links and closed websites, old tools and people complaining about the stand-still in the developing of new ones.

I hope I’m wrong, that there’s some great, wonderful tool out there being developed or just overlooked, that someone will post the missing link sometime soon. Until then, I’ll be checking out what Autodesks Revit, Bentleys Microstation or maybe IFC can do for me.

My GDL link collection
My IFC link collection

The ins and outs of IFC

One important aspect of doing a startup based on building information modelling and supporting the building industry with parametric 3d-objects, is to understand the IFC format right. There’s a bunch of information out there, that’ll explain all about IFC, like why, when, by whom and how the IFC was invented, developed in an incompatible way, ditched and reinvented. This post will focus on presenting a human readable version of the technical setting, in which IFC has its place.

Terms of the IFC-world

First off, I’d like to clarify a bit about the terms of the IFC world, as I myself was rather confused with terms like “STEP” and “EXPRESS” when I first encountered them.
IFC is modelled by IAI with the language EXPRESS (ISO 10303-11) based on STEP (ISO 10303). Now, remember that ISO stands for “International Organization for Standardization”, which should give a clue about what to expect from any ISO standard, when even the acronym of the name is ill ordered. What seems to be more obvious, however, is that STEP is the biggest standard within ISO. EXPRESS is one of the first parts of the STEP standard, and it sets a standard for how to model data in STEP. IFC is a product description like STEP, only it is focused on a data model for the building industry, where STEP has a much wider audience. IFC has recently been adopted by ISO, and can now be called ISO/PAS 16739 (which is good, because ISO/PAS 16739 is much easier to remember than IFC). As if this was not enough, actual IFC data is mostly stored in a file, a so-called STEP part 21 file. STEP part 21 is a part of the STEP standard, just like EXPRESS, and describes a standard way of storing object data in a file. Sometimes this standard is referred to as STEP21 or STEP-File, don’t be confused. Thanks to wikipedia for helping me clarify this.

That didn’t clarify anything! What is IFC?

The ifcwiki has this to say about IFC:

The IFC data model is an object-oriented data model based on class definitions representing the things (elements, processes, shapes, etc.) that are used by software applications during a construction or facility management project.

So – we are dealing with an “object-oriented data model”. Nice, this sounds like fun!

As stated above, the IFC format is modelled (described) with EXPRESS and stored in STEP-Files. Let’s have a closer look, shall we?
Browsing the latest IFC documentation or reading the Model Implementation Guide, reveals that in IFC, everything is an object. Even relations are represented as objects. Here’s an example:

[code lang=”diff”]
ENTITY IfcRelationship
IfcRelAssigns, IfcRelDecomposes,
IfcRelAssociates, IfcRelDefines, IfcRelConnects

Oh yes, there’s the EXPRESS modelling language for you, beautiful, isn’t it!? As the code above proposes, the IfcRelationship is an abstract class, it is the parent to IfcRelAssigns, IfcRelDecomposes, IfcRelAssociates, IfcRelDefines and IfcRelConnects and it inherits from the IfcRoot class, lets take a quick look at IfcRoot:

[code lang=”diff”]
IfcRelationship, IfcObjectDefinition
GlobalId : IfcGloballyUniqueId;
OwnerHistory : IfcOwnerHistory;
Name : OPTIONAL IfcLabel;
Description : OPTIONAL IfcText;
UR1 : GlobalId;

This is exciting! The IfcRoot object is an abstract object as well, it has a set of properties or parameters, and some kind of unique identifier, globally unique, that is. I won’t go into any more detail, as all the details is better explained in the IFC documentation. The interesting thing here, is the notion that every object that inherits from IfcRoot, has a GUID (Globally Unique IDentifier), and that is almost every object (exceptions are simple data types and object that represents them, like IfcLabel and IfcInteger).
A simple IfcWindowI’ll come back to some of the EXPRESS definitions of IFC in one of my next posts, but for now, I’m going to be a bit pragmatic and show you some real IFC STEP21 code.
I’ve cut out what assembles a simple window frame, as outlined in the picture, and put it in this file, NOTE: it will not show correctly in an IFC viewer. You can check for yourself, all the references are included, and there’s nothing left, that isn’t needed by the window. Hopefully this gives a reasonable introduction to IFC and its setting. Sometime soon, I’ll be digging a little more into the data model and examine the possibilities of storing it in a DBMS.