Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Part composition follow ups #182

Open
piotr-smolira opened this issue May 1, 2024 · 2 comments
Open

Part composition follow ups #182

piotr-smolira opened this issue May 1, 2024 · 2 comments

Comments

@piotr-smolira
Copy link

          >  An alternative implementation might be to have sites in their own hierarchy and have elements referenced to the site.

At least in the alignment that would already be possible, because it is kind of lifted out of the spatial hierarchy and directly aggregated into the project. So it's indeed a relevant question what that implies for road.

Should a site be able to compose a facility?

Even in the case of buildings this has been brought up. You could have a construction site on the 3rd storey of an existing building, why not?

But this really relates to the ambiguity around Site and Project. Are these geospatial reference points, the terrain, the plot, the construction area. This has never been really established and the various attributes, properties and usages all relate to various facets.

In the end I'm all for predictable and consistent exchanges though. I'm wondering if a sensible compromise would be something like the following, where lines indicate aggregation, containment, or references.

afbeelding

Originally posted by @aothms in #176 (comment)

@piotr-smolira
Copy link
Author

Relating to the Project and Site issue.

I got file in IFC4x3_ADD3.
What I noticed is that both IfcBridge and IfcRoad are contained in IfcSite on the same level.
Like in the figure below:
Fig1

By the definition of IfcBridge it enables crossing above obstacle or ground.
It mostly facilitates a transport network, but does not organize the transport network itself. Here comes IfcRoad with IfcRoadPartType and its enumeration.

To determine how Road and Bridge are related to one another only on semantic level (without looking at location side), there needs to be a rule to check if there's an IfcBridge, then there should be an IfcRoad (it applies to IfcRailway) related to the IfcBridge one way or another.

We could deconstruct passages with IfcRoad, IfcRailway. Then, both of them are allocated on a piece of land (IfcGeographicElement, described as Type Terrain), under a piece of land (tunnel, i.e. IfcTunnel), or over a piece of land (bridge, i.e. IfcBridge). My opinion is that there should be relationship between {IfcRoad, IfcRailway} and {IfcBridge, IfcTunnel, IfcGeographicElement (or other entity)}.

Please share your thoughts, @aothms and others.

@aothms
Copy link
Collaborator

aothms commented May 1, 2024

I think (but I'm not so familiar with the infra use cases) that in theory these are not relationships on the facility, because this relationship is not necessarily uniform for the complete facility. Consider e.g cases below:

afbeelding

I think the idea for this was to use https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcRelInterferesElements.htm with Spatial elements marking the respective regions of the areas passing under/over respectively. I don't really know how that would connect to the facility (and/or part) level.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants