In the US, we’ve proposed the following update to hierarchical structure for bridges:
I am trying to confirm that this is permissible under the schema and the AbV. The question is whether this is an acceptable use of IfcFacilityPartCommon, being there is no IfcFacilty>IfcFaciltyPart as an umbrella to them, but being directly “bound” to the IfcSite.
Now, I’m not hindered by any knowledge on bridges, but I think in which you phrase the question there is indeed some tension:
Well, I’m dealing with a US context specifically. From the input/feedback we’ve gotten from the state DOTs (AASHTO members) is:
Yes, this is my big question… do I need to declare an IfcFacility before I can use IfcFacilityPartCommon? Assuming that I can have multiple facilities (bridge, road, railway, building, port/waterway) on the same site, within the same project, how best to use FacilityPartCommon which is meant to span/cross Facilities? Is it required to belong to one or the other, or is it meant to be a “free-agent”, or Limbo, for constructions that work.
From the online documentation of IfcFacilityPartCommon:
5.4.3.27.1 Semantic definition
A part that is not clearly part of one domain but is a hybrid and has shared responsibilities in multiple domains.
For example ‘Level crossing’, ‘junctions’, etc. See the enums for more examples.
So, I’m assuming I can use IfcFacilityPartCommon, without an IfcFacility as proposed above.
Approaches, Retaining Structures, and Slope Protection are NOT considered integral to the bridge, but are important complementary structures. How they get designed and built often varies by jurisdiction, but they are structures that do need to be part of the overall project documentation.
Culverts are a bit trickier and we are continuing to sort this out. Our tendency is to treat them like the others.
Thus, while these structures are not explicitly “bridge parts”, they will be part of the larger road infrastructure network. Thus, the desire to put them in the same project, on the same site, but NOT within the spatial container of the bridge.
Can we get official feedback from @berlotti and/or @Evandro on the use of IfcFacilityPartCommon? I’ve asked this on the OSArch Forum and there doesn’t seem to be clear consensus, though only a couple opinions, on this anywhere. It is important for the US Bridge work to move forward.
Quickly looking at the documentation it seems clear: IfcFacilityPartCommon can not be used like this. https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/concepts/Object_Composition/Aggregation/Spatial_Decomposition/content.html
Why not make your ‘Retaining structure’, ‘slope protection’, etc. an IfcFacility? With the CompositionType you can be pretty flexible.
The large amount of USERDEFINED is also discouraged of course.
Thanks. We’ll consider it. As explained before, these “parts” are not really considered “facilities” on their own, but always part of either the bridge, road, or the site… all depending on jurisdictional preferences and requirements. Yes, looks like some compromises on the client side will need to be made.
The documentation and schema diagrams are a bit confusing (even with the Concept Templates), as some classes are interpreted as being on the same “level” as others… thus a bit of confusion as to what is “contained” and what is a parallel container.
As for USERDEFINED… it might be discouraged, but USERDEFINED has always been useful when trying to capture semantics that the standard schema doesn’t address well. This is going to happen for a lot of the bridge work we are doing now for the US. And yes, we are well aware of the bSDD and how it works, but US infrastructure doesn’t yet utilize a standardized classification system like Uniclass or Uniformat or the like and this makes specifics more challenging… we’re doing our best, but this is going to be a long journey with evolving revisions to workflows and data requirements… and there are a growing number of things (enumerations and maybe some Built Element classes) considered “missing” in the current schema (from the US client perspective) that would help their cause.
Looks like we’re leaning into these two options:
OR
@berlotti Since IfcFacility is a supertype and has no PredefinedType(s) specified for itself, do we just have an IfcFacility for said group of “generic” or undefined facilities (defined by IfcFacilityPartCommon) and just supply a Name (e.g., “Road-Bridge Common Structures” in IfcRoot.Name?
One more clarification needed…
Is it permissible or NOT to have an IfcBridgePart embedded in another IfcBridgePart? See the examples above where we declare a “Foundation” within a “Pier” and “Abutment”. The idea was to encapsulate the foundation elements within each major bridge structure and make it easier to sort and find related elements.
