# Why are IfcBridge and IfcRailway defined in differnet layers? **URL:** \ **Category:** Uncategorized\ **Created:** [August 2, 2023, 3:15am UTC](https://forums.buildingsmart.org/t/why-are-ifcbridge-and-ifcrailway-defined-in-differnet-layers/4888 "2023-08-02T03:15:44Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Feifei](https://avatars.discourse-cdn.com/v4/letter/f/d07c76/32.png) [@Feifei](https://forums.buildingsmart.org/u/Feifei)\ **Post date:** [August 2, 2023, 3:15am UTC](https://forums.buildingsmart.org/t/why-are-ifcbridge-and-ifcrailway-defined-in-differnet-layers/4888/1 "2023-08-02T03:15:44Z")
In IFC 4.3.1, both IfcBridge and IfcRailway are derived from IfcFacility, but IfcBridge (and IfcBuilding) is defined in the Core Layer 5.4.3.7, and IfcRailway (and IfcRoad, IfcMaringFacility) is defined in the Domain Layer 7.8.3.3. It’s confusing. Maybe there are some historical reasons. In my opinion, all subtypes of IfcFacility should be defined in the same Layer. I do not know if my understanding is correct. ---
**Author:** ![aothms](https://avatars.discourse-cdn.com/v4/letter/a/c67d28/32.png) [@aothms](https://forums.buildingsmart.org/u/aothms)\ **Post date:** [August 22, 2023, 10:41am UTC](https://forums.buildingsmart.org/t/why-are-ifcbridge-and-ifcrailway-defined-in-differnet-layers/4888/2 "2023-08-22T10:41:06Z")
It is confusing and inconsistent, but I do think the current situation is our best attempt at providing modules that are as self-contained and specific as possible. In the old days of IFC4 we didn’t have infra domains. IfcBuilding was a core concept because it addressed (nearly) all disciplines in scope of IFC. Now it can indeed be considered domains specific, but at that time it wasn’t. Then, infrastructure domains where added any maybe there wasn’t a further explicit subdivision as we have for buildings. So the respective top level facility elements were inserted right into the specific domains. And then there isn’t an IfcBridge domain schema, so was added to core. In IFC5 there will be opportunity again to properly realign the various traits and various domains. But for now I think this is the best we can do. What specifically would you propose otherwise and, maybe another question, how important do you find the assignment to subschemas, because in the end they cannot be used modularly and frankly if you’ll take a good look you’ll find more inconsistencies, because it doesn’t affect day to day use of the standard. ---
**Author:** ![Feifei](https://avatars.discourse-cdn.com/v4/letter/f/d07c76/32.png) [@Feifei](https://forums.buildingsmart.org/u/Feifei)\ **Post date:** [November 14, 2025, 3:48am UTC](https://forums.buildingsmart.org/t/why-are-ifcbridge-and-ifcrailway-defined-in-differnet-layers/4888/3 "2025-11-14T03:48:54Z")
Thank you for your detailed explanation. ---
**Author:** ![jwouellette](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/jwouellette/32/2140_2.png) [@jwouellette](https://forums.buildingsmart.org/u/jwouellette)\ **Post date:** [November 17, 2025, 6:38pm UTC](https://forums.buildingsmart.org/t/why-are-ifcbridge-and-ifcrailway-defined-in-differnet-layers/4888/4 "2025-11-17T18:38:14Z")
Another way to look at it: A Bridge can be part of a Rail OR Road network, just like a Beam(Girder) can be part of a Building or a Bridge. Tunnel might be a similar case. As @aothms stated, when the schema was just about buildings, the larger context/domain was singular and the [subdomains](https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/HTML/link/chapter-7.htm) were architectural, structural, building controls, electrical, hvac, etc., along with “[shared element domains](https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/HTML/)”. With the context being the entire built environment, there are now more and different subsets as things like electrical, structural and others can be applied to different domain contexts.