-
Notifications
You must be signed in to change notification settings - Fork 83
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
Properties and quantities not differentiated #868
Comments
In IFC 4.3 the properties are normalized. |
We are not talking about the same thing. In quantity sets, there are: In property sets: These are two different types that do are not part of the same inheritance branch. I suggest re-opening the issue. |
Ah; I see your point now. |
This is a valid point for discussion, but I think the conclusion is premature:
In my view the distinction between properties and quantities does not need to be maintained in newer versions of the spec. We already don't handle them differently in newer bsi specs such as bsdd or ids. In current releases there is no clear rationale on whether something constitutes a property or quantity. It seems to be either legacy or personal opinion. The concept of what constitutes e.g length to me does not change whether it's part of a quantity set or property set. But specific measuring instructions can be added as part of the "usage" of a property as part of the quantity or property set. These three points considered I would opt to keep the unified definitions the same across props and quants. |
These two definitions are treated completely differently in software. Where props can be manually edited, quants cannot and are automatically generated. I think this kind of a distinction (at this point in time) is good to have but this is another discussion. IMHO (for the future), quants should be removed from the schema and replaced by geometry validation. This would be more future proof.
Just yes. This way (and geometry validation) there should be no distinction. A bit problematic for things such as windows, but we are talking about standardising, so I see a good base for an international approach related to software implementations. Makes it much easier and still leaves room for local implementations because the international validation would supply a common geometry interpretation. |
Just a reminder that quantities currently have special status in the costing, scheduling, and resource management aspects of IFC. E.g. this parametric cost item relationship: https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcCostItem.htm#Figure-6.5.3.2.A-Cost-assignment |
Right, two discussion, what currently is, what should be. |
These are different definitions / entities and cannot be referenced in both an IfcPropertySet and IfcElementQuantity. The spec should take that into account:
The text was updated successfully, but these errors were encountered: