-
Notifications
You must be signed in to change notification settings - Fork 55
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
Connection to materials (and profiles?) #198
Comments
In our implementation in ifcopenshell we already do. I think it was also more or less the aim of working on a higher level of abstraction in IDS, so that these kind of idiosyncrasies and inconsistencies in the schemas can be uniformly addressed in IDS. It is a very much a bit messy though, because for example quantities cannot be associated to materials and profiles. Maybe also a moment to bring up the IfcPredefinedPropertySets https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcPreDefinedPropertySet.htm again, now mostly deprecated since IFC4X3_ADD2, except for 1 because it is too complex to represent in a conventional pset :( I think neither of these have to be a priority though. If speccing this all out gets too messy I think we can safely say we defer it to e.g 1.1 because I'm pretty sure it can be added in a backwards compatible manner. |
Psets can also be assigned to tasks, resources, material layers / material profiles, or material layer sets / profile sets ... etc. We currently support all of these. I see no reason why it shouldn't be supported? For example properties on profiles / materials are critical for structural analysis. |
I agree, there are many use cases based on checking properties assigned to materials, tasks, etc. The whole field of BIM-based life-cycle assessment (LCA) relies on properties assigned to materials (ISO22057 is dedicated to EPD in BIM). I spoke yesterday with a general contractor who needs to review and accept material declarations, a process currently based on PDFs. He asked if he could receive and check all of that automatically with IDS. Here is a sample IDS validating property of IfcMaterial, and I think it should be a valid IDS:
|
We need to be explicit about all the relations that allow the assignment of properties. There are some implications on the auditing tool as well. Right now the auditing expects properties to be compatible with a limited set of entities (based on
We can extend it with the following:
What other relations should be included? |
Can you be more specific about the agreements for checking material and profile properties? I am specifically concerned about applicability settings. The example from @atomczak defines IfcMaterial in the applicability. Is it also allowed to use building elements like IfcWall (IfcWall -> IfcMaterial -> Material Property)? |
I'm wondering about the reporting of failure for such example. |
@MatthiasWeise a property facet only checks properties of that the element (i.e. itself, or inherited by its type if it has one). It does not check properties of the materials of the element. @pjanck BCF does not require a GlobalID so this is not a problem. You can apply an IDS requirement to any non-rooted class. BCF is also not the only report format. |
with
vs.
seems contradictory. I think I am missing something here. @Moult Which facet can be used to check material properties, if not the one presented in the example of @atomczak ? |
@pjanck no contradiction, just perhaps a misreading. @MatthiasWeise asked this:
And so I answered that no, a property facet will not traverse an assigned material to check properties of that material. |
@Moult Thanks for clarification! I was asking because IDS is meant to have a higher level of abstraction as pointed out by @aothms. Therefore, I was wondering if such traverse interpretation would be useful in some cases, e.g. asking for Pset_MaterialMechanical properties for load bearing elements only. |
There is also the connection to IfcMaterialUsageDefinition via the IfcMaterialSelect class hierarchy. In our tests with the material facet we discovered that some prominent software vendors prefer the material export using these entities. It may be good to simply list the options the material face is conceived for and how the material associations should be interpreted in general. |
@atomczak Great overview, it very nicely shows all the options for defining material! |
Just FYI, I think the test cases cover pretty much all those scenarios pretty well (although maybe not exhaustively across all permumtations). So 👍 to those who created them. The one exception is the Question: Presumably that traversal of |
I don't think we should go as far. I would propose to exclude evaluation of IfcRelAggregates relatedobjects in any facet:
|
Yes, that makes sense for me. Agree on all the points. Putting this into a real world example, IfcStairs and StairFlights are probably a common scenario we can use to test the hypothesis. |
Colleagues,
I am playing catch-up but can I ask some naïve questions?
1. What (where?) are the implementers agreements and why are they not included in the XSD, at least as annotations?
Error 301: Invalid configuration for IDS implementation agreements
1. Why are new properties rejected ? Surely IDS isn’t only for official properties?
Error 103: Invalid property name `DateOfConstruction`
1. Why are valid property-set names being rejected?
Error 401: Reserved prefix 'Pset_' for property set name (Pset_ManufacturerTypeInformation)
On the positive side, we are close to having Sustainability IDS definitions for any Facility, for any Product, and later in the year for any EPD (Environmental Product Declarations).
Regards,
Nick.
|
Hi @NickNisbet, The road to making the initial draft into an operational format has taken quite a lot of detours. I'll be presenting an updated document this Friday in the call (I'll send out the invite today). May I ask you to rewrite the questions in independent issues and add ids snippets to help understand your questions better? |
What (where?) are the implementers agreements and why are they not included in the XSD, at least as annotations?
Error 301: Invalid configuration for IDS implementation agreements
Invalid cardinality on 'property' element at line 182, position 10.
<ids:property datatype="IFCLABEL" minOccurs="1" maxOccurs="1">
<ids:propertySet>
<ids:simpleValue>Pset_BuildingCommon</ids:simpleValue>
</ids:propertySet>
<ids:name>
<ids:simpleValue>YearOfConstruction</ids:simpleValue>
</ids:name>
</ids:property>
I’ve added these but the XSD does not make them mandatory. In fact it disallows them.
Regards,
Nick.
|
As mentioned, the documentation is improving and gonna be presented this Friday. In the new schema Please note that the new schema (0.9.7), which is available as PR at #240 Or in the original repository at: https://github.com/CBenghi/IDS/blob/facetsReview/Development/ids.xsd |
@NickNisbet this issue is about materials. Property questions should be in a new issue
[EDIT] Moved to : #241
|
@NickNisbet this issue is about materials, you should create new issues for unrelated matters. I've moved your content to: #241 |
It has come to my attention that Properties can be associated to objects other than
IFCOBJECT
orIFCOBJECTDEFINITION
via instances of classes such asIfcMaterialProperties
(see https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcMaterialProperties.htm)Should we consider those paths valid for 1.0?
@atomczak, would you care to contribute to this discussion? You might have a number of use cases to support them in the verification of models, the counter-argument being implementation ease, of course.
Thanks,
Claudio
The text was updated successfully, but these errors were encountered: