IFCNameAttributeMapping .. should be IFCTypeAttributeMapping

[owen]

http://www.archicadwiki.com/TechTips/IFCNameAttributeMapping#IFC_Name_Attribute_Mapping

It is always good to see improvements to the user-customizability of IFC configuration such as the above new feature (in a Hotfix no less!). However I do wonder how widely customers were consulted about this as IMO this mapping feature has been applied to the wrong IFC attribute - user-customizable mapping should work for IfcType not the Ifc Name attribute. Best would be enabling a similar mapping system for both, but I think the latter is more important.

The ArchiCAD ID attribute is commonly used for both 'type'/'mark' identification (e.g steel member sizes) and unique instance identification (e.g Doors) within ArchiCAD. ArchiCAD ID is mapped to the IFC Name attribute.

The IFC Type attribute is - according to the Graphisoft Help Center:

An IFC Type Product is an IFC Entity that defines a particular style/type of other entities by relating to them with common IFC Attributes and Properties. For example, IfcWindowStyle is an IFC Type Product, to which many windows (IfcWindow) refer

It it under the IFC Type attribute where you should refer to find information regarding the product type such as Model Name, Sizes, etc .. not under IFC Name which is usually used for instance identification.

If i take the Window (ID 'WD-001') example from the link at the top of this post, the way AC currently works will result in the following attributes:

(Italicized text in examples below is customisable via the mapping XML)

IFC Name = WD-001 Window 17 0.9x1.5 Window*
IFC Type = Window 17

whereas what I believe you would want in an IFC is:

IFC Name = WD-001 <i.e the window identifier only
IFC Type = Window 17 0.9x1.5 etc <i.e the windows type details

as it stands I think the fixed way in which AC creates Type from various element attributes - see here - is inflexible and in many cases this means the whole 'Type' property becomes broken for IFC use, particularly in relation to objects where their parametric nature means they can contain many 'IFC Types' and so simply using the library part name for all instances of potentially different objects is not good.

The addition of XML mapping for IFC Type name would be most useful and correct what i think is an oversight with this new 'IFC Name Mapping' option. Ideally library parts should also be able to read/write information to IFC properties so for example the object can modify the Type property depending on what variation it is .. I hope GDL will become 'IFC Aware' in AC18 😉

[EDIT] Just realised I posted this to the wish forum not discussion but that probably makes sense anyway. So the 'Wish' is i guess 'to provide an IFCTypeAttributeMapping function in addition to the new IFCNameAttributeMapping function'