Creating Itemsets from objects in IFC files

Im getting IFC files from different disciplines and I then want to create itemsets based on the properties of the objects in the IFC files.

I have tested this with only dgn-files and using the Dataset_GB.

But when a wall or other objects have been exported to IFC there is only a few properties available to choose from in the Item Set Search dialog.

When I look in the Items dialog I can see that the properties exist on the IFCWallStandardCase.

See screen shots below. Im using AECOsim SS6 and Navigator SS6

Do someone know how to solve this?

Parents
  • Hi Johan,
    Are you opening or importing the IFC file? When directly opening I do see the same limited number of properties available in the Search dialog, which is almost the same list for all component types. On the other hand, IFC Import generates a Wall component vs. IfcWallStandardCase, and seems to provide all of the properties available in the original DGN file. Is this an option for you?



  • Hi

    I have a Composition model to which I attach the different models I get from various disciplines (IFC, DWG and DGN). I then publish to i-model to be reviewed with Navigator. Non of the IFC-models i made in a Bentley Software.

    I tried the import option and it seems that properties are available but the Graphics did not look the same. It was very slow and created a new dgn file to be managed. So I do not think thats it is a good option. If you import the IFC there can be a risk of human error and objects can accidently be moved.

    Is there any other workflow for this kind of work?
Reply
  • Hi

    I have a Composition model to which I attach the different models I get from various disciplines (IFC, DWG and DGN). I then publish to i-model to be reviewed with Navigator. Non of the IFC-models i made in a Bentley Software.

    I tried the import option and it seems that properties are available but the Graphics did not look the same. It was very slow and created a new dgn file to be managed. So I do not think thats it is a good option. If you import the IFC there can be a risk of human error and objects can accidently be moved.

    Is there any other workflow for this kind of work?
Children
  • OK, thanks. Referencing IFC files does use the same functionality as opening, and is based on core MicroStation. Importing is specific to ABD and maps the IFC properties to the DataGroup System and Family + Part system. Can you elaborate on the graphical difference you see between the two?

    I'd have to check with our MicroStation team for more details on how the IFC Open/Reference ability accesses properties, and what should be brought across.



  • This is how the model looks when imported:

    And this is how it looks when its attached as a reference:

    The model also becomes very slow to navigate when imported compared to attached as a reference

  • But this import issue is not really interesting for now. Because I dont believe this is a good way to handle this. I think import is only if you intend to continue to work with the imported objects.

    I work on a big project where there will be a lot of IFC files and my job as a coordinator can not be to import all the models I receive in to dgn-files.

    There must be people out there that coordinate and reviewing projects that contains models from other sources than dgn-files?
    Or when they do are they not using the information within in the files and just looking at the graphical contents?

    The i-model plugin for revit is one solution but Bentley do not have plugins for every software on the market...
    It would be nice if they did, but I think it would be easier for bentley to get the IFC to work (if it is so that it does not work properly) than to create plugins for every software..

    There is a service ticket on this issue from last year. It also handles the issue with the characters åäö that also causes problems when attaching an IFC-file. But that issue is easier to walk around.
  • All good questions!

    I am curious to hear how others are approaching this.



  • Unknown said:
    to get the IFC to work (if it is so that it does not work properly) than to create plugins for every software..

    Johan,

    This is a big question and opportunity for Bentley. IFC is supposed to be the 'lingua franca' that everyone should be using. Mstn has had IFC referencing functionality for a while now.

    I think that being generated by other apps, the compataibility of the IFC will always be a problem. So much needs to be translated and mapped. I think that there are three stages:

    1. Settings and mapping table in the exporting app. If a plugin like the Revit i-model exporter is not available, then there will need to be a lot of experimenting. I think things will get better as more and more apps get the latest IFC / MVD certification. Bentley and users like yourself could help by publishing settings that work best and highlighting problems, so that the devs can fix them.

    2. The IFC generated is usually opened up in IFC editors like Solibri, SimpleBIM etc, and 'cleaned'. I think that there will be a lot of re-mapping and coding to correct errors involved here. Most users will have a viewer app at least to check which app has 'failed'.

    3. Settings and mapping tables in the importing app. I think that there are two options here. You could use the IFC mapping tools provided by verticals like ABD or you could convert to i-models and use the i-model transformer tool, which can be automated using ProjectWise's Automation tools. Something you will probably want to look at if you are working big jobs that will have thousands of files that need repeated translation, checking, re-mapping, optimisation and merging.

    In the UK, there is a concept called the Common Data Environment (CDE) is a core component of achieving the government's goal of Level 2 BIM for publicly funded projects. I always thought that it is really a blurry vision that has been rehearsed years ago by Intergraph's 3d Interop and Bentley's i-models.... using IFC as the exchange format. The need for a CDE means that the focus has shifted from the import/export tools included with each authoring app to the 'middleware' that glues everything together and tracks changes etc etc.

    This translation and hosting function needs to be as seemless as possible. I find that the biggest problem even in BIM environments is still getting the information to the collaborators. The amount and scale of the files means that there is a huge lag and cost associated with translations. I know of one project where translations need to be instructed i.e. paid for beforehand !!. Talking about BIM is a waste of time if it ignores the basic lack of basic IT automation tools required to enable those high-faluting dreams. PW has all the basics for sharing models etc but should be ready out of-the-box to be able to incorporate and automate the translation/transforming etc en bloc tools, like Intergraph's 3d Interop Publisher.

    Bentley has a big advantage here due to its history with big projects and the petro-chem world where this kind of thing is old hat. The need for IFC will be most pronounced during the construction stage where all those subcontractor-supplied IFC models generated by dwg/tekla-based apps is huge problem for the main contractors... hey small Revit footprint, guys.. hint hint. And the CAD geometric data is only one portion of a much larger whole. See the German MEFISTO project, which is more contrractor-centric compared to the anglosaxon debate which is much more FM, designer-focused.