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
Parts: Wrong location for parts #86
Comments
@WawanSolihin @dvrvb Do you have any idea whats wrong here, or if it's already fixed in a more recent commit? |
Hi eibre, Nope, it's not yet fixed. Regards, |
In this case, what is your expectation on the exported IFC? Is the beam supposed to be created as a Beam with aggregation of the parts? or it is OK with a Beam with multiple geometries? |
Yes.
I don't think it is OK, but this is the current workaround I use because the other method fails. |
Maybe I was not very clear. I tested the file with the latest ifcexporter and I do not get a IfcBeam with an aggregate of 5 IfcBuildingElementParts, but I get an IfcBeam that has 5 geometry items instead. The location seems to be correct (see attached). I don't think this change in the behaviour is on purpose, but it is a side effect of supporting the creation of the Type object (e.g. IfcBeamType in this case) that will have a shared geometry (using MappedItem), which is shared by multiple instances of the same type. In the past the type was not supported, or not real (i.e. one type for each instance). So my question here is which is the desired behavior that is preferred? An IfcBeam with aggregate of 5 IfcBuildingElementPart, or an IfcBeam with a reference to IfcBeamType that has 5 geometry items (linked to the instance by MappedItem)? |
The attachment: |
with the DEV-solution until 21th january (not your latest commit of 25 jan) I got this result, with the aggregation: see sample |
Yup I got that at first until I updated to the latest codes. I do not think there was any particular change directly related to it between 21 Jan to now. |
I'm building now the latest solution. I thought it was only related to some German translations, but I will notice it in a few moments. |
Aha, if I choose the default export option IFC4 Reference View, I also got the same result as you. |
Hmm true enough, that is the case. There is a setting there that makes the import parts somewhere. I will take a look. |
Yes @dvrvb is right. Parts are not exported unless |
|
@WawanSolihin I installed the last beta5 and exported with the settings shown in the image below. |
Hi Eibre, I don't want to interfere in your question at Wawan. If I export it now (IFC2x3CV2.0 and IFC4RV1.2), with a current build solution, it still stays in place. |
@dvrvb Thank you for your interest in this issue! I tested your file and the parts stay in place, the same result as you got. How ever when I added a true north rotation to project base point they are off again: |
Hi @eibre, Regards, |
@WawanSolihin I can't share my model to the public, but have sendt it to Angel since I couldn't find your e-mail address. |
…rrect projection direction for IFC4RV requirements. IFC4RV Beam (Arch) is now without error in the automated test 1st fix for issue related to runaway parts in "export only elements visible in view" (there are still situations that may cause a wrong rotation, but the test case reported in issue #86 so far looks good) Minor typo changes
…rrect projection direction for IFC4RV requirements. IFC4RV Beam (Arch) is now without error in the automated test 1st fix for issue related to runaway parts in "export only elements visible in view" (there are still situations that may cause a wrong rotation, but the test case reported in issue #86 so far looks good) Minor typo changes
Version: IFC4RV Beta Release v0.6 .2
Steps to reproduce:
I have a simple I-beam where fire insultion is added.
Create parts of the beam
Export ifc in a view where parts are visible.
Problem:
The position of the parts are offseted.
If "export parts as building elements" is checked, the position seems to be correct.
Sample Revit and two ifc files created with different settings are attached:
sample_files.zip
Maybe this is related to #20
The text was updated successfully, but these errors were encountered: