Mapping IFC and AECOsim Fields

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

Parents
  • 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:

    Name

    Material

    Volume

    Surface Area

    Top of slab

    etc...

    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?

  • Sorry, but I don't agree here.

    The problem with "burnt in" values is, that we can't trust them. If the geometry is calculated from the ifc model by the viewer, than it is possible to check it. Different ifc viewers might get different results.

    A geometry value that is hard coded is something I never would use.

  • FWIW, we're also looking into fixing the Net values in the Base Quantities tab.  

    In regards to the mechanism used to generate those values in IFC format...   I'm afraid I'm not qualified to enter that discussion.  



  • Andreas,

    I'm not suggesting getting rid of the IFC viewer's ability to calculate its own quantites, such as the "Quantities" tab in Solibri. I just want AECOsim to burn its information to the tab "Base Quantities" tab. That way we have the best of both worlds - a calulated value in the viewer and a burnt value matching AECOsim's data.

    My reasoning is that we invest most of our time and effort in AECOsim and we trust its native calculations. When we export to IFC we are sending the model to numerous parties, all of which may use different IFC viewer software. We need to know that they will see the same data as we do in AECOsim. Bentely have no control over how the IFC viewers calculate quanities, and there's plenty of scope for errors with complex objects. The "Base Quantities" tab would therefore provide a consitent link between the authoring software and its end use.

  • And which data would you want to see?

    Take e.g. a slab with some cuts into it. Bentley has 2 different values for the volume, for example. The volume without features subtracted, the volume with features subtracted. And if you move on to surface area, there is also the possibility to just subtract feature areas above a certain threshold.

  • I take the point... Generally though I'd say "Net (modelled)" values would be most useful in most cases - if there's a feature modelled I probably want it to be accounted for in any quantitifaction. For me that's the "purest" information.

    If I wanted to exclude certain penetrations I'd just remove them in AECOsim before running the export, safe in the knowledge the IFC would report whatever is modelled.

Reply Children
No Data