-
Notifications
You must be signed in to change notification settings - Fork 18
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
IVS-80/GRD000 - Grid Information #257
base: development
Are you sure you want to change the base?
Conversation
@version1 | ||
@E00020 | ||
|
||
Feature: GRD000 - Grid Information |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feature: GRD000 - Grid Information | |
Feature: GRD000 - Grid Placement |
@evandroAlfieri Why did we pick "Information" instead of "Placement"? Grid Information to me hints at information on grids in the model, not other elements placed according to grid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I thought moving the pr back to draft was enough to save you from reviewing it. It's about this rule that we (Geert and I) wanted to talk with you on Monday
Given its attribute PlacesObject | ||
Given its entity type is 'IfcProduct' including subtypes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is governed by the schema.
PlacesObject: SET [0:?] OF IfcProduct FOR ObjectPlacement
But what is not governed is that there is at least one Product being placed by the Placement, which I think is a good requirement to add here as an activation criterion.
Given its attribute PlacementRelTo | ||
Given its attribute PlacesObject | ||
Given its entity type is 'IfcGrid' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These three lines should actually not be a given statement, but a then statement.
Given an IfcGridPlacement Then PlacementRelTo/PlacesObject **must be** IfcGrid
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes it a normative rule, and not a rule to check for activation.
Which is part of the reason why this PR is de-activated. It would probably be better to create two new normative rules and then skip the 000-rule. Based on this issue
Given its attribute PlacesObject | ||
Given its entity type is 'IfcProduct' including subtypes | ||
Given return to IfcGridPlacement | ||
Given its attribute PlacementRelTo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PlacementRelTo does not exist on schemas pre IFC4.3. I think this must be reflected in the scenario.
Given its attribute PlacementLocation | ||
Given IntersectingAxes = not empty |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is given by the schema:
IntersectingAxes: LIST [2:2] OF UNIQUE IfcGridAxis
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I was wondering how close we should stay to the relating concept template.
Given its attribute PlacementLocation | ||
Given IntersectingAxes = not empty | ||
|
||
Then The IFC model contains information on quantities of elements |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copy pasta
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Speaking of which, maybe this is too error prone and we can rather easily replace this with:
Then The IFC model contains information on quantities of elements | |
Then The IFC model contains information on the selected functional part |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Undercooked pasta, in this case ..
It's indeed very easy to miss, and maybe not such an important part. We have the description in the feature file to provide context after all.
Given IntersectingAxes = not empty | ||
|
||
Then The IFC model contains information on quantities of elements | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So all in all, you could consider rewriting this scenario as:
Given an IfcProduct
And its attribute ObjectPlacement
And its entity type is IfcGridPlacement
Then The IFC model contains information on ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But would this be close enough to the relating concept template?
Would it be nice if we could state that some software supports a functional part based on these templates?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, it goes back to the age old question that we have to second guess the intention behind the template, and this case I'd say it's twofold:
- [GRD000] Describe grid placement functionality:
IfcProduct ----ObjectPlacement---> GridPlacement
- [GRD001-a] Constrain placement of grid "a grid placement should be defined relatively to a grid":
GridPlacement ----PlacementRelTo----> IfcObjectPlacement ---PlacesObject---> IfcGrid
And then a third component that is important, but is not in the template:
- [GRD001-b] "The grid to which the placement is relative should contain the axes that are used for the intersection"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's phrase it differently, as soon as the model contains:
IfcProduct ----ObjectPlacement---> GridPlacement
The file contains a "grid placement" according to the functional part.
But if it's not according to the 2 further specifications I just highlighted, it's not that the model doesn't contain it, it's that the usage is invalid. So yes, these are additional normative parts and we need to create this separation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@evandroAlfieri @Ghesselink Annother rule for the backlog is this informal proposition from the docs:
IntersectingAxes[1] and IntersectingAxes[2] shall not be part of the same row of grid axes, i.e. both shall not be within the same set of IfcGrid.UAxes or IfcGrid.VAxes of the corresponding IfcGrid.
return layer if context.include_layer else None | ||
|
||
#ensure the stack does not get pupulated when nothing was yielded in the last step | ||
if (lambda f: f(f))(lambda f: lambda data: bool(data) and (not isinstance(data, (list, tuple)) or any(f(f)(item) for item in data)))(context.instances): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again this is rocket science to me. Can we clear this up first in the other PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's bring the rocket science back to building information science then 🚀
See #258 (comment)
In short, it ensures that context.instances is meaningful. In this case, when the result of the last Given statement is an empty set of instances, we don't want to go back. For instance;
| Step -> context.instances after step |
Given An IfcEntity -> [Entity, Entity, Entity]
Given its attribute A -> [SomeAttr, SomeAttr, SomeOtherAttr]
Given its attribute is SomeAttr -> [SomeAttr, SomeAttr, ()]
Given its attribute B -> [(), (), False]
Given its attribute IfcEntity -> What do we return here?
In case we don't check whether context.instances is meaningful, we'd return the context.instances as was the case after the initial Given step. This is not the preferred behavior, since the preoccuring Given statements determined that the rule would not be applicable.
The handle_given
section in the decorator would probably be a better location for this logic.
@@ -203,6 +200,7 @@ def should_apply(items, depth): | |||
|
|||
# evokes behave error | |||
generate_error_message(context, [gherkin_outcome for gherkin_outcome in context.gherkin_outcomes if gherkin_outcome.severity in [OutcomeSeverity.WARNING, OutcomeSeverity.ERROR]]) | |||
pass |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A debug statement I forgot to remove, sorry
4e3ce44
grid_placement.PlacementLocation = f.createIfcVirtualGridIntersection( | ||
[grid_axis_1, grid_axis_2], | ||
(0.0, 0.0, 0.0) | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This violates the informal propositions here: https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcVirtualGridIntersection.htm
It's also a really creative grid.
I would define:
U axes:
(0, 0) -> (0, 2)
(1, 0) -> (1, 2)
(2, 0) -> (2, 2)
V axes:
(0, 0) -> (2, 0)
(0, 1) -> (2, 1)
(0, 2) -> (2, 2)
W:
<empty>
And then you intersect e.g UAxes[1] with VAxes[1], but they need to be instances from the grid itself.
Also you don't actually reference this variable, but redefined sth on L 777
Also the polyline grid axes are best 2d instead of 3d.
This one is a bit more elaboration and includes changes in the python implementation
General/improvements not limited to the current rule:
GRD000 specific: