We have started using IfcGroup for various Revit groupings, such as Area Schemes, Fabric Areas, and Rebar groups. What we haven't used it for is actual Revit groups. This seems like a good extension and we'll consider it for the near future.
Regards,
Angel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I hope you're well. I'm adding my thoughts on the equivalent to a Revit group in IFC if it helps.
I tend to think of a group in Revit as similar to an AutoCAD block (ie duplicated but transformed instances of equivalent geometry). In this aspect I think Ryan is correct, an IfcMappedItem (with a master IfcRepresentationMap) is an appropriate way of to take advantage of duplication.
If a "group" had an identifiable purpose (such as roof aggregation) it should really be identified as this product and decomposed. But Revit groups don't really support this at this point in time (to my knowledge).
I think the most appropriate equivalent in IFC is the IFCElementAssembly (should still be decomposed into sub elements including assemblies). But I'd still recommend taking advantage of the transformed geometry using the mapping if not typical extrusions etc.
Always interested in discussing these details. There are a few distinct differences between a Revit Group and an AutoCAD block. In particular, a group in Revit is a collection of elements - whose geometry is repeated, yes - but whose identity should not be lost. For example, if a group contained 4 walls and 4 doors, you would want, in my mind, an IfcGroup that contained 4 IfcWalls and 4 IfcDoors, not some sort of IfcBuildingElementProxy that contained an IfcMappedItem to the geometry of the walls and doors.
You could argue that you could have an IfcGroup that had an IfcMappedItem that mapped to the geometry of the walls and doors, and the IfcWalls and IfcDoors. However, then you'd have duplicated geometry - once in the group, and once in the walls and doors.
Now, what I could easily see happening in the example above is that the IfcWalls would contain IfcMappedItems instead of their normal geometry (at least for complex geometry). However, we would have to be careful about that, because items in groups are actually allowed to have different geometry from certain operations, such as wall joins to elements outside of the group. So, we'd have to make sure that for the "different" geometries, we didn't use the IfcMappedItem. Of course, figuring out what the "same" geometries were to figure out which ones are different isn't a trivial issue. In addition, many of the items that have complex geoemtry already use IfcMappedItem (there are some notable exceptions like spiral ramps; these aren't probably grouped much, though.)
As for the IfcGroup vs. IfcAssembly issue - we already have Assemblies as separate entities in Revit, which are exported as IfcAssembly. It may be confusing to have Groups and Assemblies export as assemblies.
What do you think?
Regards,
Angel
Regards,
Angel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This discussion reminded me that we already have code that attempts to export group geometries as mapped items! It is in the BodyExporter code, with a flag useGroupsIfPossible. This code is currently disabled; it is basically finished but hadn't been widely tested, and I was concerned that "switching it on" would create more issues than it fixed. I'll look to see what state it is in and consider "flipping the switch" - with some appropriate testing.
Thanks,
Angel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We have done part of this request for the v2.10/v3.2 release. In particular, Revit groups are now exported as IfcGroup. There is no attempt yet to revive the IfcMappedItem functionality, but that request has been recorded.
Thanks,
Angel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
HI Ryan, not much, but that's not the full answer. Revit groups don't have the ability to have shared parameters added to them, so you'd lose any metadata (including, e.g., the IFC GUID) associated with the IFC entity. This is a Revit, not IFC, limitation, so we'll need some core Revit work (unless you don't mind losing the information on the groups).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, at this point in our "FreeMVD workflow" I think it would be okay to lose most parameters. The key ones however are IFCSURFACESTYLE or the IFCMATERIAL property--in that, we're using the resultant Revit Material upon import, to use for automated tagging via Dynamo--as you can see in the sheets in this file
Retaining the GUID would be nice since we're looking to use it with merge control and conflict resolution of the various IFC files, but at this point haven't adopted or developed any solutions yet.
The only solution that i know exists out there is Constructivity's Merge Control, but to be honest, the UI is a little thick to get a handle of.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems from the following test files, that the IFC Exporter does not export out definitions for 'Revit's Groups'. Is that correct?
If so, any plans on supporting this in the near future?
From my understanding, would one use the following IFC entity to accomplish this?
IfcMappedItem -
http://www.buildingsmart-tech.org/ifc/IFC2x4/rc4/html/schema/ifcgeometryresource/lexical/ifcmappeditem.htm
Revit File: https://dl.dropbox.com/u/7117445/temp/IFC%20tests/Test%20for%20Groups.rvt
IFC file: https://dl.dropbox.com/u/7117445/temp/IFC%20tests/Test%20for%20Groups_Default%202x3.ifc
Cheers, Ryan
Hi Ryan,
Actually, I think the item would be IFCGroup: http://www.buildingsmart-tech.org/ifc/IFC2x4/rc4/html/schema/ifckernel/lexical/ifcgroup.htm
We have started using IfcGroup for various Revit groupings, such as Area Schemes, Fabric Areas, and Rebar groups. What we haven't used it for is actual Revit groups. This seems like a good extension and we'll consider it for the near future.
Regards,
Angel
Hi Angel,
I hope you're well. I'm adding my thoughts on the equivalent to a Revit group in IFC if it helps.
I tend to think of a group in Revit as similar to an AutoCAD block (ie duplicated but transformed instances of equivalent geometry). In this aspect I think Ryan is correct, an IfcMappedItem (with a master IfcRepresentationMap) is an appropriate way of to take advantage of duplication.
If a "group" had an identifiable purpose (such as roof aggregation) it should really be identified as this product and decomposed. But Revit groups don't really support this at this point in time (to my knowledge).
I think the most appropriate equivalent in IFC is the IFCElementAssembly (should still be decomposed into sub elements including assemblies). But I'd still recommend taking advantage of the transformed geometry using the mapping if not typical extrusions etc.
For reference, http://www.buildingsmart-tech.org/ifc/IFC2x4/rc4/html/schema/ifckernel/lexical/ifcgroup.htm
http://www.buildingsmart-tech.org/ifc/IFC2x4/rc4/html/schema/ifcproductextension/lexical/ifcelementassembly.htm
Happy to discuss further if you're interested.
Cheers,
Jon
Hi Jon,
Always interested in discussing these details. There are a few distinct differences between a Revit Group and an AutoCAD block. In particular, a group in Revit is a collection of elements - whose geometry is repeated, yes - but whose identity should not be lost. For example, if a group contained 4 walls and 4 doors, you would want, in my mind, an IfcGroup that contained 4 IfcWalls and 4 IfcDoors, not some sort of IfcBuildingElementProxy that contained an IfcMappedItem to the geometry of the walls and doors.
You could argue that you could have an IfcGroup that had an IfcMappedItem that mapped to the geometry of the walls and doors, and the IfcWalls and IfcDoors. However, then you'd have duplicated geometry - once in the group, and once in the walls and doors.
Now, what I could easily see happening in the example above is that the IfcWalls would contain IfcMappedItems instead of their normal geometry (at least for complex geometry). However, we would have to be careful about that, because items in groups are actually allowed to have different geometry from certain operations, such as wall joins to elements outside of the group. So, we'd have to make sure that for the "different" geometries, we didn't use the IfcMappedItem. Of course, figuring out what the "same" geometries were to figure out which ones are different isn't a trivial issue. In addition, many of the items that have complex geoemtry already use IfcMappedItem (there are some notable exceptions like spiral ramps; these aren't probably grouped much, though.)
As for the IfcGroup vs. IfcAssembly issue - we already have Assemblies as separate entities in Revit, which are exported as IfcAssembly. It may be confusing to have Groups and Assemblies export as assemblies.
What do you think?
Regards,
Angel
Regards,
Angel
Just to add a few cents to the discussion...
I have been using 'Groups' extensively in my recent project--a data center. Groups were ideal way to model this repetitive and modular building type.
Many of these Groups were nested many levels deep--including a multitude of system, and in-place families--including stairs/ramps, for example.
I wanted to use 'Assemblies' (being that you can schedule them in Revit) but as reflected in the following error, copying them neatly, is an issue.
"Edits caused an assembly to match an existing assembly type and inherit a new name."
With Revit 2014's ability to schedule Groups, Assemblies are becoming more redundant in my workflow.not correct, updated 8/20/2013From my perspective, it would seem to make sense to eventually subsume 'Assemblies' into 'Groups'.
Last edit: Ryan Schultz 2013-08-20
Hi Jon (and all),
This discussion reminded me that we already have code that attempts to export group geometries as mapped items! It is in the BodyExporter code, with a flag useGroupsIfPossible. This code is currently disabled; it is basically finished but hadn't been widely tested, and I was concerned that "switching it on" would create more issues than it fixed. I'll look to see what state it is in and consider "flipping the switch" - with some appropriate testing.
Thanks,
Angel
Sounds great, would be happy to test, let me know!
Best, Ryan
We have done part of this request for the v2.10/v3.2 release. In particular, Revit groups are now exported as IfcGroup. There is no attempt yet to revive the IfcMappedItem functionality, but that request has been recorded.
Thanks,
Angel
Hi Angel, would it be much work on the importer side to have these IfcGroups reconstitiutied as Revit Groups upon import?
HI Ryan, not much, but that's not the full answer. Revit groups don't have the ability to have shared parameters added to them, so you'd lose any metadata (including, e.g., the IFC GUID) associated with the IFC entity. This is a Revit, not IFC, limitation, so we'll need some core Revit work (unless you don't mind losing the information on the groups).
Thanks Angel,
Yes, at this point in our "FreeMVD workflow" I think it would be okay to lose most parameters. The key ones however are IFCSURFACESTYLE or the IFCMATERIAL property--in that, we're using the resultant Revit Material upon import, to use for automated tagging via Dynamo--as you can see in the sheets in this file
Retaining the GUID would be nice since we're looking to use it with merge control and conflict resolution of the various IFC files, but at this point haven't adopted or developed any solutions yet.
The only solution that i know exists out there is Constructivity's Merge Control, but to be honest, the UI is a little thick to get a handle of.
Other discussions that inform this one...