BBIM - Ifc 4x3 class and predefined type | quick guide for beginners

I meant to prepare something similar to a quick guide to list the use of Ifc class and predefined type of building elements in a model.

Thanks to @antbozz I was able to prepare something for those, like myself, who are struggling with building elements that are not easy to find in the bSDD or similar.

The proposed coding system (columns 'Type' & 'Subtype') is not the main point of the attached table since it depends on the company's standard, it is rather the content of 'Class4x3' and 'Predefined' that in my opinion could be helpful to beginners.

Any feedback will be greatly appreciated
Happy modeling !

KoAraMassimoemiliotassoCadGiruantbozzsemhustejDayalan

Comments

  • It is hard to see what entities belong to Domain in the Ifc Document. I thought that combining Entity inheritance and Domain would be easier to organize, but do those of you familiar with IFC have a better way to categorize them?
    Is it IFC's development policy not to include Domain in Entity inheritance?

    IfcDistributionElement

    • IfcDistributionControlElement

      • IfcBuildingControlsDomain
        • IfcSensor
    • IfcDistributionFlowElement

      • IfcFlowSegment
        • IfcHvacDomain
          • IfcPipeSegment
          • IfcDuctSegment
        • IfcElectricalDomain
          • IfcCableCarrierSegment
        • IfcPortsAndWaterwaysDomain
          • IfcConveyorSegment
      • IfcFlowStorageDevice
        • IfcHvacDomain
          • IIfcTank
        • IfcElectricalDomain
          • IIfcElectricFlowStorageDevice
  • edited July 2024

    bridge classification

    I tried to classify (4x3) elements in a bridge, if anybody with knowledge in infrastructure IFC could check if it is somehow correct or needs to be edited, pretty please?

    thanks

    KoAraRoelMassimoppaawweeuuAceDimitriscarlopav
  • @steverugi
    The proposed classification of bridge elements from the BIM for Bridges and Structures TPF study is in this document.
    https://github.com/jwouellette/TPF-5_372-Unit_Test_Suite/blob/main/Bridge IFC Hierarchy Proposal.pdf

    KoArasteverugijwouellette
  • Hi @Rick_Brice

    The proposed classification of bridge elements from the BIM for Bridges and Structures TPF study is in this document.
    https://github.com/jwouellette/TPF-5_372-Unit_Test_Suite/blob/main/Bridge IFC Hierarchy Proposal.pdf

    thank you for the link, extremely interesting, much appreciated

  • Hi @Rick_Brice

    The proposed classification of bridge elements from the BIM for Bridges and Structures TPF study is in this document.
    https://github.com/jwouellette/TPF-5_372-Unit_Test_Suite/blob/main/Bridge IFC Hierarchy Proposal.pdf

    I was trying to implement the classification as per your proposal

    currently (2411011) it's not possible to create an IfcBridgePart inside another IfcBridgePart, only IfcSpace

    or should I do it in a different way?
    thanks for your help

    KoAra
  • Not sure what you mean by not being able to create an IfcBridgePart inside another IfcBridgePart, only IfcSpace (mostly because I'm still a newbie to IFC). I think I've been able to do it per https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/concepts/Object_Composition/Aggregation/Spatial_Composition/content.html
    Here is a breakdown for the attached model (screenshot from KITModelViewer)

    KoArajwouellettesteverugi
  • edited November 2024

    @Rick_Brice

    Not sure what you mean by not being able to create an IfcBridgePart inside another IfcBridgePart, only IfcSpace (mostly because I'm still a newbie to IFC).
    Here is a breakdown for the attached model (screenshot from KITModelViewer)

    thanks for the quick reply
    I meant using Bonsai
    when I create an IfcBridgePart and need to create a sub IfcBridgePart in it the same from the dropdown is not available, only IfcSpace

  • That's interesting - I never noticed that before. I'm generating the IFC from my bridge design software and then importing it into Bonsai.
    Here is what the spatial decomposition looks like

    Everything below "Unnamed Bridge" shows as IfcSpace.
    Over in the Scene Collection, they are IfcBridgePart

    I think the first step is to figure out if there is something fundamentally wrong with the IFC itself (as in, I'm code it incorrectly). If it's ok, then looking to the Bonsai UI for short comings is the next step. The Bonsai UI is still heavily skewed towards vertical construction. There is going to be some growing pains for horizontal construction

  • @Rick_Brice

    That's interesting - I never noticed that before. I'm generating the IFC from my bridge design software and then importing it into Bonsai.
    Here is what the spatial decomposition looks like

    looks good to me here :)

    Everything below "Unnamed Bridge" shows as IfcSpace.
    Over in the Scene Collection, they are IfcBridgePart

    As far as I understand the Outliner is no longer used, the Spatial Decomposition should be rather the way to go

    I think the first step is to figure out if there is something fundamentally wrong with the IFC itself (as in, I'm code it incorrectly). If it's ok, then looking to the Bonsai UI for short comings is the next step. The Bonsai UI is still heavily skewed towards vertical construction. There is going to be some growing pains for horizontal construction

    will post an Issue then, many thanks
    cheers

  • Everything below "Unnamed Bridge" shows as IfcSpace.

    I think that is the default, not the actual IfcBrigePart, I usually select it by clicking on the square in the above menu

    and check it in Object Information > Metadata

  • Sounds like Bonsai has some work to do. Technically, we've had our bridge proposal vetted by the bSI Technical Team and they've agreed it is reasonable. For IFC4.3, spatial containment will need to be flexible for infrastructure, as many owners in the domain will have slightly different requirements about that hierarchical/logical structure and relationships. For bridges, tunnels, roads, waterways, rail, etc. it will NOT be as straightforward as buildings.

    steverugiKoArasemhustej
  • Hi @steverugi ,

    I am attaching a few documents in case they can help you, one of them shows how I organise the models of each elementary work (tunnel, bridge, road,...), and then I organise as I want each ifc of these elementary works (I tried to translate it). I don't want them to give me an IFC exported directly from the software, as each software gives you a different scheme, I usually ask them to reorganise it. The document is not finished, I am completing it.
    The other document is an Excel where you can find all the elements that you can find in a railway work (it is in Spanish, sorry). The document is quite interesting, I've only left a few tabs, if you want it complete I'll give it to you.

    steverugi
  • Hi @BimETS

    I am attaching a few documents in case they can help you, one of them shows how I organise the models of each elementary work (tunnel, bridge, road,...), and then I organise as I want each ifc of these elementary works (I tried to translate it). I don't want them to give me an IFC exported directly from the software, as each software gives you a different scheme, I usually ask them to reorganise it. The document is not finished, I am completing it.
    The other document is an Excel where you can find all the elements that you can find in a railway work (it is in Spanish, sorry). The document is quite interesting, I've only left a few tabs, if you want it complete I'll give it to you.

    thanks a lot for your help, very much appreciated!

    BimETS
  • edited January 4

    Update

    I tried to use ifcopenshell directly to create an IFC4X3_ADD2 file that would allow nesting IfcBridgePart using this code example and here it is:

    #import libraries
    import ifcopenshell.api.root
    import ifcopenshell.api.unit
    import ifcopenshell.api.context
    import ifcopenshell.api.project
    import ifcopenshell.api.spatial
    import ifcopenshell.api.geometry
    import ifcopenshell.api.aggregate
    # Create a blank model
    model = ifcopenshell.api.project.create_file("IFC4X3_ADD2")
    
    # All projects must have one IFC Project element
    project = ifcopenshell.api.root.create_entity(model, ifc_class="IfcProject", name="My4x3Project")
    
    # Set units to meter square meter and cubic meter
    length = ifcopenshell.api.unit.add_si_unit(model, unit_type="LENGTHUNIT") 
    area = ifcopenshell.api.unit.add_si_unit(model, unit_type="AREAUNIT")
    volume = ifcopenshell.api.unit.add_si_unit(model, unit_type="VOLUMEUNIT")
    
    # Assigning with arguments to metric units
    ifcopenshell.api.unit.assign_unit(model, units=[length, area,volume])
    
    # Create a modeling geometry context, to store 3D geometry 
    context = ifcopenshell.api.context.add_context(model, context_type="Model")
    
    # Store the 3D "body" geometry of objects, i.e. the body shape
    body = ifcopenshell.api.context.add_context(model, context_type="Model",
        context_identifier="Body", target_view="MODEL_VIEW", parent=context)
    
    # Create a bridge, bridge parts and sub parts.
    site = ifcopenshell.api.root.create_entity(model, ifc_class="IfcSite", name="My Site")
    bridge = ifcopenshell.api.root.create_entity(model, ifc_class="IfcBridge", name="BridgeA")
    bridgepartSUB = ifcopenshell.api.root.create_entity(model, ifc_class="IfcBridgePart", name="Substructure")
    bridgepartSUP = ifcopenshell.api.root.create_entity(model, ifc_class="IfcBridgePart", name="Superstructure")
    bridgepartDECK = ifcopenshell.api.root.create_entity(model, ifc_class="IfcBridgePart", name="Deck")
    bridgepartPIER = ifcopenshell.api.root.create_entity(model, ifc_class="IfcBridgePart", name="Pier")
    bridgepartABUTMENT = ifcopenshell.api.root.create_entity(model, ifc_class="IfcBridgePart", name="Abutment")
    
    # Since the site is our top level location, assign it to the project
    # Then place our bridge on the site, and our parts in the bridge and so on
    ifcopenshell.api.aggregate.assign_object(model, relating_object=project, products=[site])
    ifcopenshell.api.aggregate.assign_object(model, relating_object=site, products=[bridge])
    ifcopenshell.api.aggregate.assign_object(model, relating_object=bridge, products=[bridgepartSUB])
    ifcopenshell.api.aggregate.assign_object(model, relating_object=bridge, products=[bridgepartSUP])
    ifcopenshell.api.aggregate.assign_object(model, relating_object=bridgepartSUP, products=[bridgepartDECK])
    ifcopenshell.api.aggregate.assign_object(model, relating_object=bridgepartSUB, products=[bridgepartPIER])
    ifcopenshell.api.aggregate.assign_object(model, relating_object=bridgepartSUB, products=[bridgepartABUTMENT])
    
    # Write out to a file
    model.write("/content/drive/MyDrive/Colab Notebooks/IFC/4x3model.ifc")
    
    

    when I open the IFC in Bonsai..

    my nested IfcBridgePart are there! nice!

    well, I haven't fully tested it but seems to be working just fine, .ifc file attached. If stable I can use this to prepare a template with the needed Spatial Decomposition since it's pretty similar for the bridges I have to model.
    Any advice would be very appreciated
    cheers

    @Rick_Brice @BimETS @jwouellette

    Massimobrunopostletheoryshawjwouellettesemhustejdang
  • edited January 4

    SVG file with hierarchy

    I attach an .svg file with relevant hierarchical bridge IFC structure as suggested by @Rick_Brice , if you open it in (for instance) InkScape you see all elements grouped accordingly, the same is shown in the .png and the image below.

    The intention is to provide beginners with some quick info to start using 4x3add2 schema in BIM infrastructure works

    It would be very helpful if it were to be 'vetted' so that I can use it in our Wiki-OSArch and with my junior colleagues at work, thanks

    Massimojwouellettesemhustejcarlopav
  • Hi @steverugi ,
    The work you are doing seems very good to me, congratulations!!!
    I have downloaded the ifc and checked it with an ifc viewer and it works correctly.
    The structure you suggest seems to me to be quite correct. One of the things I like is that you don't nest an ifcbridgepart with another ifcbrigdepart. If I can help you with anything, let me know... I'm very good at testing ifc ;).
    Could you explain to me how you generate the ifc from the generated ifcopenshell code?

    steverugi
  • @BimETS said:
    Hi @steverugi ,
    The work you are doing seems very good to me, congratulations!!!

    Thanks

    Could you explain to me how you generate the ifc from the generated ifcopenshell code?

    I used Google colab the last line of the code saves the ifc to the desired path

    BimETS
  • Nice work @steverugi. Your example script will be a big help for bridge engineers.

    I can use this to prepare a template

    If you are looking to create a template file to use as Bonsai template and put it in, bonsai/bim/data/templates/projects, so the template shows up in the UI, there is a bit of an issue. The spatial breakdown for a building is hard coded into Bonsai. I tried to create a bridge model template for Bonsai a few months back but set it aside because I didn’t understand the internals enough to get around the hard-coded building information.

    jwouellettesteverugi
  • @Rick_Brice said:
    Nice work @steverugi. Your example script will be a big help for bridge engineers.

    Happy to help

    If you are looking to create a template file to use as Bonsai template and put it in..

    Not really, just trying to workaround the current limitations in Bonsai, which I seem to have sorted out somehow with the script
    The idea of a template though is a good one I think
    Cheers

    jwouellette
  • I think it would be really useful if Bonsai could have a more general New Project from Template system so domain experts could contribute template files for new road, bridge, rail, tunnel, etc. projects. The new project UI has a long history of buildings and doesn’t seem to have the flexibility to support anything else.

    Do you have aspirations of updating Bonsai for bridges? I would like to build in some basic bridge modeling features. As a first step I’m trying to create a UI and backend IfcOpenShell API to create a simple alignment. Unfortunately the work is not going well due to lack of blender and bonsai programming knowledge.

    jwouellettesteverugiBimETS
  • edited January 4

    Yes, definitely
    Let's find the way to collaborate, very exciting task
    My colleague Jonathan has good programming skills, I think you know him already
    Looking forward to

  • @BimETS said:
    The structure you suggest seems to me to be quite correct. One of the things I like is that you don't nest an ifcbridgepart with another ifcbrigdepart. If I can help you with anything, let me know... I'm very good at testing ifc ;).

    So according to our spatial hierarchy proposal for US Bridge using IFC4.3.2.0, using IfcBridgePart for multiple level of nesting “SUPERSTRUCTURE>PIER or ABUTMENT>FOUNDATION” is allowed and is our proposed “best practice” and AASHTO standard.
    Why? Well, within the limitations and sloppiness of the final spec (my opinion), the IfcBridgePart acts as both a spatial “level” and a “semantic container” instead of explicitly segregating the two into different IFC concepts (which ones? good question needing further discussion for best consensus-based answers). The spec itself does NOT limit the use of nesting, similar to IfcGroup or IfcElementAssembly, but provides an opportunity to give better semantic context to the groupings, their sub-components, and their relationships to each other, as well as the overall bridge structure. The feedback from the US state DOT owners/stakeholders is that this conceptual organization is the most desired when looking at a bridge and its components for the purposes of tracking construction progress and payment, as well as asset management (e.g., inspection, maintenance, inventory, etc.). Again, this is ONE POV, which is why the IFC4.3.2.0 flexibility is useful and important, but also a potential double-edged sword for software on both the data creation and ingestion/use, by further complicating software UI/UX for the variety of end users.

    Any other ideas are open for consideration and discussion.

    steverugiBimETS
  • @KoAra said:
    It is hard to see what entities belong to Domain in the Ifc Document. I thought that combining Entity inheritance and Domain would be easier to organize, but do those of you familiar with IFC have a better way to categorize them?
    Is it IFC's development policy not to include Domain in Entity inheritance?

    IfcDistributionElement

    • IfcDistributionControlElement

      • IfcBuildingControlsDomain
        • IfcSensor
    • IfcDistributionFlowElement

      • IfcFlowSegment
        • IfcHvacDomain
          • IfcPipeSegment
          • IfcDuctSegment
        • IfcElectricalDomain
          • IfcCableCarrierSegment
        • IfcPortsAndWaterwaysDomain
          • IfcConveyorSegment
      • IfcFlowStorageDevice
        • IfcHvacDomain
          • IIfcTank
        • IfcElectricalDomain
          • IIfcElectricFlowStorageDevice

    Look at Chapters 6 & 7 for the specification for such listing. There are still some legacy “hangovers” (IFC2x and on) but obviously it is not to everyone’s liking. But that’s consensus-based standards for you… trying to find the “best common denominator” with people willing to do the work and be part of the conversation.

    steverugiKoAra
  • I agree that a consensus on the ifc 4x3 structure would be optimal as it would facilitate our work. In building it is clear that the organisation of the ifc, IfcBuilding/IfcBuildingStorey, and the different models of different disciplines (architecture, mep, structures) will follow the same schemes.

    About the ifc 4x3 scheme there is not much information, and sometimes it seems to me that we depend on how the different softwares export these ifc, and we have to believe that what is exported is good.
    In my case, as a property I ask them to give me the models of the different disciplines in ifc, and I insist that I don't care about the software generated. What is the problem, that each software exports with a different scheme, because of this lack of consensus. And for me that is a problem.

    One of the main problems with these exports is that the IfcRailwaypart entity is used, from my point of view, in an exaggerated way. They really seem to be the equivalent of windows folders. This is why I don't like the nesting of the IfcXxxPart entities.
    But of course I will be the first to use the template agreed by a majority, because I firmly believe that this is the only way to make ifc prevail. And of course learning a lot from these discussions.

    steverugiKoAraviktor
Sign In or Register to comment.