Why are IFC details exposed end users?
I've been looking at demos of infrastructure products that support IFC exchanges for bridges. Without pointing fingers at specific vendors, many seem to require end users to know a lot of detail about the IFC specification. The products seem to require the end user to assign IFC classes and attributes to bridge elements. For example, in one product after an extruded shape of a precast concrete I-Beam was created the user had to tell the software the object was a precast concrete I-Beam and assign the IfcBeam class and set the type enum.
This seems error prone and unnecessary. Through the UI, the user could have assigned any class and type resulting in a very poor model.
Why are these IFC details exposed to end users? It seems to me that the fine grain details of IFC should be left to software developers and hidden from the end user. Importing and exporting models that conforms to an MVD should be seamless.
Comments
Generic 3d modellers softwares can't assume object's type and nature from design. More information is required.
So basically either the soft does provide a "concrete beam" entity and then is able to export properly or use a multi purpose generic beam entity and it is up to the user to actually tell the nature of the object from icf point of view.
Not only the nature and shape of objects define an ifc class, but also the role in the building, like the exact same beam may use 2 different classes, depending on the axis (vertical / horizontal) and contribution in structure.
Agreed - for a generic modeler, the user needs to choose what the object type is. For a dedicated modeling tool (e.g. the "bridge tool") these should occur out of the box as much as possible. However, many traditional BIM tools which translate to OpenBIM don't have a 1:1 mapping, so exposing the guts of IFC through awkward interfaces is often common.
Unfortunately, the concept of a MVD is good in theory, but fails in practice. MVDs are generally poorly implemented / validated / certified, leading to all sorts of translation problems going in and out of software. Even when working in Native IFC, MVDs introduce unnecessary translation issues (e.g. dumbing down objects from Design Transfer to Reference View MVDs).
Poor translation and problematic MVDs is the root cause of these problems in my opinion.