-
Notifications
You must be signed in to change notification settings - Fork 61
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
PartOf recursive #164
Comments
I guess it could also be valuable to allow recursiveness to be set on the PartOf facet itself in IDS |
Actually it gets a little more complicated, consider the following situation: IfcDoor -> IfcRelAggregates -> IfcCurtainWall -> IfcRelContainedInSpatialStructure -> IfcBuildingStorey If you were to build an IDS to check whether the IfcDoor are all part of an IfcBuildingStorey, how would you do that? My initial thought would be to always (for all 4 types of aggregations defined in IDS) incorporate traversal via IfcRelAggregates, and then from any object encountered do the actual PartOf check. This would also be valuable for example for systems. But it kind of depends a bit on the typical use cases... |
Interesting case... Maybe just walk DOWN the spatial tree until the first match of the specified relationship? When checking IfcDoor for Relation IfcRelContainedInSpatialStructure, just ignore all relationships inbetween and stop at IfcBuildingStorey. |
Thanks for chiming in Jan. I don't really understand what you mean with walking down the tree though, I think in all cases we are interested in walking up. The problem is that there is no Thinking about it, in a lot of use cases, I would say the additional "relation" field in IDS makes things a lot more complicated. Why would we not just always check all 4 routes, but maybe I am thinking too simplisticly. |
Does this mean, that a prohibited Example: prohibited Example:
There aren't only 4
This proposes to only apply "recursion" with My opinion: I would not support recursion of any sorts. Out of the two options above, I could live with the latter. Also, in this case, I would greet such addition:
|
In itself that's not an argument against enabling recursion.
I think they are just the four type of relationships that came up during the use case analysis as relationships that are meaningful to enforce/specify for end-users. If I would picture me as an end user I think I would like partOf to be transitive. If A is contained in B, B is contained in C. Then yes, A is contained in C. I find the combination of the various relationships indeed very challenging. A <- Aggregates -> B <- Contains -> C, is really hard to distinguish from A <- Contains -> B <- Aggregates -> C or from just A <- Contains -> C. From that point of view I'm quite sympathetic to @rubendel's argument to just arbitrary and recursively keep traversing these 4 relationships until you arrive at the specified entity. It supports the lowest handing fruit kind of use cases I imagined for this feature.
But indeed not use cases related to directly being contained in something. So instead of saying:
you have to say
Given how project specific IDS's are I don't think that'd pose an immediate problem given the other kinds of facilities in IFC, but it is a limitation. |
Proposal: arbitrary and recursively keep traversing these 4 relationships until you arrive at the specified entity. This means we need to remove the enumeration of ifcrelaggregates, ifcrelassignstogroup, ifcrelcontainedinspatialstructure and ifcrelnests. |
After thinking about it a bit longer, Proposal 2: turn 'relation' attribute into optional. When 'partof' is used it can be any recursive path of any relationship to the entity; when explicitly defined it should be a direct relation (or recursive but only with that same relationtype). |
The documentation currently does not mention whether PartOf should be checked recursively. I think it should, but would be good to discuss and then document.
Example: Checking whether objects are part of a building storey, naively only checking the direct parent through the IfcRelContainedInSpatialStructure will work in a lot of cases, but not when objects are part of an assembly or other grouping objects.
https://github.com/buildingSMART/IDS/blob/master/Documentation/partof-facet.md
The text was updated successfully, but these errors were encountered: