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.
The other problem is the fact that IFC will only be one of many formats.
On large projects, the CDE will be a common 'server' with folders full of dgns, dwgs, xsd, rvt, 3dm, jt etc. Everyone will be using their own apps and their apps will be saving in the own formats. The problem comes when one user needs to reference another user's file which is generated in another format.
With Bentley, you are spoilt for choice, you can ref Rhino 3dm's, dwg's, ifc's directly. No need to wait for the weekly or monthly share or conversion to i-dgns. But what if you are a subbie using a dwg-based app? You may get some partial joy with Xref-ing dgn's... but more than likely will need similar translation/transformation automation tools.
ACAD as of 2016 will be able to Xref Navisworks nws files, its version of i-models. Some folks will be using i.dgns or i-models as their lightweight model format to get the all important context into their models, but there will be others that will need nws or jt.
There needs to a means of 'replicating' the different formats so that the whole issue of having different files goes away / becomes 'transparent' when each user looks at his folder... he sees all the project's files in his app's format.
What about change control? Oooh...you shouldn't be able to access those foreign files if they haven't been shared..etc Sure sure, the admins should have the option to restrict this. Admins who have seen what happens in the trenches know that the users rely on being able to 'preview' those unshared files to make their deadlines. The old wait till you do clash detection malarky as a viable means of developing a design is a joke... told by BIM snake-oil salemens.
Having replication will be increasingly useful as we go forward. No app can cater to all requirements. Most large offices these days are multi platform. I know or lots of teams which use Rhino in conjunction with Mstn. It would be good to replicate dgn's as 3dm's automatically so that the Rhino users have real time situational awareness. I know of other offices that use Mstn for the early stages and Revit for construction documentation.These guys sit next to each other and don't work blind between weekly shares. Replication can only boost productivity by removing the fee-robbing drudgery of translating/transforming stuff repeatedly.