When a iModel is published from Revit isn't it supposed to contain intelligence? For example, a door knows it's a door, stairs know they're stairs, etc. The reason I am asking is that I was wondering if drawing rules could be applied to them?
John K.
They retain their Revit intelligence as business data (or embedded data), they don't retain their parametrics in i-model.
It could possibly be done, but the challenge would be you'd have to create Criteria Sets, ECQueries, or something other than Family/Part to group the items together, and then you may not be able to label the components as the rules are looking for data that may not live in the same structure or location. For example, a Steel Beam that comes over may have an property called "Shape", but is that the same "Shape" that a Structural Rule is looking for in the same storage location on the element.
Thanks,
Shawn
------------
Thanks for the input Shawn. Maybe it would be better if we used IFC models from Revit? Has anyone had any experience with Revit IFC files?
John
IFC would include BIM data so perhaps that is a better option for you. As far as Revit IFC fidelity... I'll leave that to others to answer.
Not sure if this workflow is suited to your needs. But I'll throw it out here.
When publshing imodels from Revit you get whatever is in the view at the time of publishing.
You get the 3D model from the default 3D view. You get the floor plans from the floor plan views. etc.
The 3D imodel can be used for 3D coordination, clash detection, rendering, etc.
Each plan, elevation, etc. can be generated as imodel drawings to reference to drawings for sheet creation.
and that's a possibility, Paul...but I think he's trying to bring data into their standard way of doing business, so he wants to apply his logic and rules.
the Revit i-Model process uses IFC data, so you'd get the same data regardless...I think you'd get better graphic and object fidelity (and smaller size) via i-Model.
If you could merge your i-model into a .DGN, then you could apply part/family...OR if you could apply Part/Family to an object via the Overlay file...but it wouldn't necessarily be ON the object...it's worth a shot.
One example that has come up between an IFC model and an iModel that I have noticed. I cut a section of a wall that is supposed to be CMU, for instance. If that wall is in an iModel then I just get the outline of the wall cut but if that wall is in an IFC model I get the CMU hatch pattern of the wall. Now mind you that the IFC file was generated from ABD and the iModel was from Revit. I'm waiting for a client to send me an IFC from Revit to see if there is a difference. I'm also going to create an iModel from ABD and try both.
I-models do include business data via EC schema properties, but that data is to support all disciplines - it was never intended to carry BIM intellgence such as Family & Part. That's whay Shawn was outlining a few potential scenarios to get that data added (to what is a read-only model).
IFC, on the other hand, was designed as a building-specific format and therefore offers things that an i-model cannot. From a Structural perspective there's also the ISM plugin, but that won't help for Architectural components such as doors, windows, etc.
Hmmm...
i-models seem like the vanilla schema. IFC is more the building-specific schema and recognises F+P. ISM is the structural-specific schema... and therefore should also recognise F+P?
Bentley now has quite a few translation tools:
Platform: i-model transformer, i-model Composer, DataManager, i-model drivers for Excel, Access etc
Building: IFC transformer, ISM Revit Link, RFA Interpreter (coming soon)
In a BIM environment, a lot of the Ref attachments would likely to be i.dgn's or dgn's that would need to be:
1. Cobbled together from different sources: ISM to get best fidelity for structural elements coming from Revit, IFC from another BIM app or to get the architectural stuff, i-models from other Bentley verticals etc
2. i-model transformer has a graph-based scripting interface which will be useful to handle the inevitable customisation that will be needed to prep the info before the user can Ref the i-model (or work on the dgn).
Should the IFC model be split into several floors, each with a nested i.dgn so that would mesh with the existing ABD model? Or split by phasing?
I-model transformer seems to also support the use of a 'Relating Schema' to merge/associate data from an Excel table for example to the graphic/attribute elements in the i-model.
Purpose specific filters to reduce the stuff for the task at hand...
3. I-model transformer also seems to be able to re-map values based on scripted user requirements. It would be good to have this functionality part of the upcoming RFA Interpreter and IFC Transformation tool.
It would be good to be able to combine the tools into one UI and 'choke point'. Interoperating with Revit would mean getting an IFC that would need to map and replace 'dumb' IFC geometry with tagged attributes with interpreted RFA's, and other DGS elements like paz, bxc, DG annotation cells etc to minimise the amount of 'zombies' we will need to deal with.... using i-model transformers rule sets and graph-based UI...?
It should be possible to include Item Set Criteria Sets, ECQueries etc
4. What about transaction management? Will Design History be able to version the changes to the non-graphic attributes? Sqlite? IFC GUID change tracking? ISM?
5. What about links to GC and the upcoming Parametric Content Modeler? The RFA Interpreters seems to only work for elements that have 'counterparts' in BA that work similarly. What if you don't have one? I think you would have be able to build one using GC or PCM...
Revit may not have an open format, but it has an API that allows the user to generate Revit elements within Revit. So, an IFC with the appropriate tags attached to the relevant elements could be converted into the native Revit element with the help of the Revit ISM plugin?
Looks like Nigel has an idea: www.eatyourcad.com/article.php