I'm trying to get robust IFC exports set up. When I look at the IFC EXport > Mapping Options > Map > Property Mapping, I see the attached table. I can't seem to add or change any settings (other than clearing existing entries). Is this just our setup or is this how its supposed to look?
I thought that standard properties had been defined in the IFC format - i.e. for a Column: Name, Length, Net Volume, Surface Area, etc...
I therefore expected to find all, or at least some, of these AECOsim fileds would be mapped to relevent IFC fields? It appears none of this work has been completed - this may explain why my data seems to be such a mess in the exported IFC files (apart from the two fields listed, which are very relaible!)
Am I missing something obvious? How do the properties get mapped, why are standard properties not already mapped to IFC fields?
Has anyone ever created an IFC which they are satisfied with? If so I'd be most interested to see the DGN, IFC and any settings used. So far I can't say I've seen an IFC export with a data structure that satisfactorily replicates the AECOsim schema. It looks to me like its just a question of correctly mapping the information, but perhaps I've missed something!
Mark
ABD SS4 v08.11.09.622
ANZ Dataset
Mark, make sure the \DatasetExtensions\IFC2x3_psets\ folders are available to your dataset. The Pset files are what display in those mapping pull-down menus.
Thanks Steve,
We found that the "as delivered" ANZ dataset incorrectly installed the additional IFC data to the following path:
\DatasetExtensions\DatasetExtensions\IFC2x3_psets\
So we've corrected this to match the path configuration variable:
\DatasetExtensions\IFC2x3_psets\
This now allows me to select properties from a pull down lists in IFC EXport > Mapping Options > Map > Property Mapping.
BUT... the lists are extremely limited - there's nothing to map most to the fields to and I can't understand why the standard fields wouldn't already be mapped.
I must be missing something in my understanding, but here's how I expected IFC exports to work:
IFC has a series of Pset files covering common building elements and including the typical fields which might be relevant to the specific element, for example:
Column Pset might include:
Name
Material
Height
Volume
Surface area
Cross section area
etc...
whereas Slab Pset might include:
Surface Area
Top of slab
I was under the impression these Psets contained industry standard fields, defined by established IFC protocols (?). Bentley, Autodesk, or others would then simply map the information their package used to these preset Pset fields. Thus for a standard item, such as a column, the "Height" would report in a standard IFC field, no matter whether it was drawn in AECOsim or Revit (and irrespective of what the authoring package called that property - "Length" in AECOsim for example). As a user I would only need to worry about "special" items or fields I'd introduced.
This doesn't seem to be the case though.... As far as I can see, almost no fields are directly mapped - the AECOsim IFC export is therefore a splurge of data with little structure or consistency. IFC Name for example seems to come from either "ID|Number", or "Identity|Description" depending on what's filled in - I'd much rather it always, and only, came from one field.
Can you explain where I've misunderstood the process, or explain how else we can achieve the desired consistency of output?
Hi Mark,
I actually believe this is correct, but I'll discuss with folks here to be sure.
The Property Mapping Utility is only used to map duplicate properties in the current project schema.
When the IFC2x3 dataset extension, possibly including FM Handover, is part of the project’s workspace, some properties in the IFC2x3 property sets duplicate ABD properties, e.g. the IFC property Pset_ColumnCommon/FireRating duplicates the ABD property ObjectFireResistance/Rating.
Without property mapping, both properties would be displayed in the UI, e.g. ‘FireRating’ and ‘Rating’; hence users would not know which property to enter the value to or whether to enter values to both. Also, both property values would be exported to IFC to their respective properties.
Mapping duplicate properties avoids this confusion, because a mapped duplicate IFC property (e.g. ‘FireRating’) is greyed out in the UI with a note which ABD property (e.g. Rating) the value should be entered into. On IFC export the values entered for the ABD property will be exported to the mapped IFC property set and property, e.g. Pset_ColumnCommon/FireRating.
Datasets are delivered with the necessary mappings; hence users typically don’t have to use the Property Mapping Utility unless to map user-defined properties that are duplicated by IFC properties. Note that only properties in property sets starting with Pset_ or COBie_ are available for mapping in the right-hand column of the utility and that mapped properties are no longer available for mapping in the drop-down list, because an IFC property can only be mapped once.
The mappings are stored in IFC_PropertyMapping.set located in the setting folder, e.g. the entry for the above FireRating/Rating examples is:
Concrete Column * Pset_ColumnCommon FireRating IfcLabel ObjectFireResistance/@Rating
This means
(a) that for all catalog items of ‘Concrete Column’ the ABD property ‘Rating’ in property set ‘ObjectFireResistance’ is mapped to the IFC property ‘FireRating’ in property set ‘Pset_ColumnCommon’;
(b) that all ‘Rating’ values will be exported to the IFC property ‘FireRating’ in property set ‘Pset_ColumnCommon’.
However, if the formats of the ABD and duplicate IFC property differ, e.g. the IFC property Pset_ColumnColumn/@LoadBearing is a ‘Boolean’, while the duplicate ABD property "ObjectStructuralUsage/@StructuralFunction is a ‘string’, then the Property Mapping Utility cannot and is not being used at present. Such property mappings are made by entries in IFC_PropertyMapping.set, e.g. for the above example:
Concrete Column * Pset_ColumnCommon LoadBearing IfcBoolean EVALUATE DG("ObjectStructuralUsage/@StructuralFunction") EQ "Load-bearing"; StructuralFunction ('Load-bearing'=True)
(a) that for all catalog items of ‘Concrete Column’ the ABD property ‘StructuralFunction’ in property set ‘ObjectStructuralUsage’ is mapped to the IFC property ‘LoadBearing’ in property ‘Pset_ColumnCommon’;
(b) that if the value in the ABD property ‘StructuralFunction’ is equal to the string “Load-bearing”, then it will be exported to the IFC property ‘LoadBearing’ as ‘True’, if the string is anything else, then it will be exported as ‘False’.
The fly-over hint of the mapped IFC properties in the placement tools will indicate this information.
I hope this clarifies the property mapping issue and answers your question.
Regards,
Volker
Volker,
Thank you for the detailed response.
If I've understood correctly, you're saying that the translation is done "behind the scenes" in most instances and Property Mapping Utility only comes into play where the AECOsim schema has data fields duplicating standard IFC ones.
This makes some sense but seems illogical to me. In the case of Fire Rating I don't understand why we would wish to keep duplicate fields. Surely a much more logical approach would be to have one "correct" field that translates directly to IFC. What benefit is there in leaving a redundant field greyed out?
That aside, I also am not seeing the information I would expect translated to the IFC files. For example, I understood standard geometric information for a concrete column would appear in a standard IFC Pset. It's height, its cross-section area, its volume, etc... Yet this information does not seem to be reliably translating from AECOsim to IFC...
We do see "Structural Quanities" information, but this is very irratic, with errors in magnitudes of units and often complete failure to export values. This "Structural Quantities" field is not a Pset so I cannot imagine it is the intended IFC protocol. All the evidence appears to suggest that there is no "IFC pset process" set up in AECOsim to deliver geometric data fields... Am I mistaken?
We're finding the IFC export to be extremely confusing and frustrating and would therefore appreciate further explantion and advice.
Perhaps the easiest way to describe the probelm is by explaining what I want to see...
I draw a column in AECOsim and export to IFC.
I then open the IFC file in a viewer (Solibri and/or Navisworks).
I want to click on the column and see the identity tag I've added to a data field in AECOsim.
I want to click on the column and see its fire rating and any other data fields I've added in AECOsim.
If I've not added any data I want these fields to display in the same format but with a blank entry or a dash.
I want to click on that column in an IFC viewer and see a data field for its length, its cross section area, its volume and and its surface area.
I want these values to have the correct units.
I do not want these geometric values to be calculated by the IFC viewer (although it may do that as well), I want them written to the object by AECOsim so they match the values I see in Dataset Explorer.
I want the values to appear in the same format and syntax, each and every time I run the export.
Currently this is not the experience we are having with AECOsim IFC export though.
Looks like you found a bug in the ifc export.
Left side of screenshot shows Solibri Viewer, right side Aecosim. Same column.
Another one!
I get the same result - 0's throughout the Strucutral Quantities tab. Previously I was getting values but they were 10^9 times too big for volume (I assumed this to be a mm to m error deep in the exporter). I don't know why, but I can't seem to replicate this any more though.
I also don't understand why there are two Strucutrual Quantities tabs - one is always filled with 0's. The Quantities and Base Quanities tabs are generated by Solibri measuring the geometry and tend to be inaccurate for curved elements (presumably becasuse of the way the facets are calculated).
Net result is that quantities information is not available. This is a problem Bentley must solve urgently!
Our Cost Consultants need to be able to access information in a neutral platform. Since we installed SS4 I-models do not carry any data in complex models, so they are useless. IFC is the preference and needs to become a reliable standard - I don't understand why it is proving so difficult to get it right.
Andreas,
What is under Solibri Tab to right of one you have open?
it appears to have same name like it is duplicated.
Tom