-
Notifications
You must be signed in to change notification settings - Fork 32
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
Bever Control Sprint 3.exc #179
Conversation
@ivaroppen Please sync from main, there is a change necessary to activate the checker. If you require assistance, please shoot me an email. |
Sorry, I need some help with this 2 issues: Check 'Underground excavation in Sprint 3.exc' with uuid=3e71c130-014e-4a7d-c0de-1fc10ce1deb1 The following instances are failing: #352, with GlobalId '3rVsqBF4j7UvaqqoBZaBIg' Could you please point me in the direction of what I am doing wrong? The other one I need help with: Check 'Element's representation in Sprint 2.3' with uuid=23b70110-014e-4a7d-c0de-1fc10ce1deb1 2.3.2.ii) Correct Representation for Element: correct surfaic or volumentric type used. Following may be used: Body tesselation, Body Brep, Body Swept Solid, Surface Model, Voxel, Surface Tesselation The following instances are failing: #352, with GlobalId '3rVsqBF4j7UvaqqoBZaBIg' In sprint 2.3 the allowed geometries does not allow Body Sectioned SolidHorizontal. The current checker is complaining when I use Body Sectioned SolidHorizontal in Sprint 3.exc (RepresentationType = AdvancedSweptSolid). |
Your interpretation is correct. We will update the checker - I'll open an issue for this. |
It was the checker as well. I'll update it together with #185 fixes. |
I've managed to update the checker - thank you for pointing out the errors in its implementation! |
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.
Great job with an interesting model! We could merge this with a few comments:
- IfcTunnelTypicalSection should be contained and not aggregated (maybe fix this?)
- It seems as if there are two IfcGeoScienceModel (one, PHYSICALDISTRIBUTIONMODEL, aggregating the other, NOTDEFINED) - Intentional?
- The geometric representation in this case could be made more efficient since all profiles has an equal number of vertices. One IfcSectionedSolidHorizontal with four profiles would do. However, the current representation works. It would be interesting with the widened part having a different number of vertices in the profile. In that case, e.g. an IfcFacetedBrep would be needed in the widening part. It would be interesting though to add guiding curves to the excavation body representation :-)
- IfcElementAssembly missing PredefinedType=.ARCH.
- IfcArchElement has PredefinedType USERDEFINED (maybe a software library issue?)
- IfcArchElement=>Material missing PSet_MaterialConcrete
- In the IfcBuiltSystem/TUNNEL_SUPPORT, both the IfcElementAssembly and the IfcArchElement (which is decomposing the IfcBuiltsystem) is included
- The IfcArchElementType and IfcArchElement are not associated. Maybe that's the intention?
Yes, I think it’s a library issue.
Agree, however, I did not fix it this time.
Sorry, did not fix in this time. The remaining points in the review should be fixed in this version… |
The workaround is quite nice though. I can offer a re-serialization with IFC Reactor to make it better but it would modify your header FILE_NAME content to a different processor. Let me know whether you would like me to do that. It is turning out to be quite the "beacon file". |
Predefined type for IfcArchElement
Please see #167 for an explanation on the guidelines. |
@SergejMuhic : I think that the guided curve implementation needs to be discussed/resolved. The way I understood it, we discussed having one element (e.g. IfcUndergroundExcavation) having two geometric representations (e.g. IfcSectionedSolidHorizontal + IfcGeometricCurveSet for the guide curves). In the provided dataset, the sectioned solid belongs to the excavation elemennt and the curve set to a separate spatial zone. Furthermore, i wonder what the below means practically in the IFC file with regards to e.g. contexts: |
We should create a usage for it. We have the resolution documented in issues bSI-InfraRoom/IFC-Specification#118 and bSI-InfraRoom/IFC-Specification#648. I have created an issue to resolve the applicable entities: |
File
A draft for Sprint 3.exc
Covered Concept Templates - Usages Included
The defined consept templates and usages should be included in this draft.
Miscellaneous