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?
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
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.