ISO10303: IFC exchange format design and usage

IFC is one of the oldest standards for data exchange within the AEC industry. It became one of the most supported exchange formats available. Using a standard which was started about ten years ago, brings with it obsolete ways for defining objects and exchange files. Example to that is usage of EXPRESS language to define the schema and use of ASCII as the format of the file.

While it is great to have a format that is being adopted by a growing list of publishers, issues with the schema and its implementations makes it hard to adopt and rely on. Below are some of the issues that I guess are mostly visible, and a possible solution to consider!

Highly Typed: The IFC schema (ISO 10303-21) has an object definition for each type of object defined in the AEC industry. This results in a huge schema; instead of having one type of data object. The attributes of the objects are based on the object type, thus producing a complex exporter and reader of the file. As a developer, the highly specific format of the objects makes the specs your best friend while writing a parser, reader or an exporter to this format.

Mapping vs Correctness: This issue is mainly a problem with the usage of the format. The generosity of options in describing a single object or part of objects, is that a publisher usually chooses one path of representation which is usually the simplest to map too or the first option they see (since it’s a huge schema). This has the risk of losing data quality and/or having bad representation of the data. As an example, a circle can be defined in lots of ways: like IfcCircle, IfcArc between 0 degrees and 360 degrees, IfcTrimmedCurve of an IfcArc (between 360 and 0) trimmed at 0 and 360. The last one might seem odd, but I have seen it a lot. The three options give a correct result but it’s an over kill, and in my view wrong. Another example to fast routes taken is exporting all the geometry as triangle meshes losing all the quality…

Readability: There exists an XML version of the format, Part-28, but it’s not much used. ifc file (part 21) format is an ASCII file, where each object is a line by itself. Parent-Child relationship and associations are defined by #object_number that acts as a link between objects, which makes tracking an object in a text editor practically impossible.

Predefined Data fields: each object type found in the file has a predefined set of properties that should be available. The problem with this restriction is that when a publisher doesn’t have the required fields they include bogus data just to conform to the schema of the object, which sometimes makes the whole dataset bogus. This is also found in the required predefined hierarchy of the object definitions. Example: most design systems set the building name to be the filename or some string, when it’s not available!

A call for Conformance Level: Changing the schema is a very optimistic approach, since the time frame required for the industry to support it and implement it is long. What would be nice to have is a test suite where publishers are asks to run to check the quality of the data sent. Then publishers will consider updating their implementations to get a higher ranking on the conformance. In my view, with such test suites we will see less publishers producing files with geometric cache-triangulation (a very common observation) instead of the actual CAD data.

, , , , , ,

One Comment

  • a says:

    wonderful put up, very informative. I wonder why the opposite specialists of this sector do not realize this.
    You must continue your writing. I’m sure,
    you have a huge readers’ base already!

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>