Hi,
I’ve been trying to load Ifc4 files with IfcOpenShell. I only looked at a few IfcRepresentationItems but, from what I can gather, there is no implementation of Ifc4 in IfcGeom. Is this correct?
For example, in IfcExtrudedAreaSolid the position parameter is optional in Ifc4. Currently the IfcGeom code assumes it isn’t optional and doesn’t test hasPosition() before trying to access the position.
If so, are there any plans to implement it? How do you plan to do it?
Thanks,
Ian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regarding your specific example, actually I wasn't aware of this change. This is related to something that has to change in IfcOpenShell. Accessors of optional attributes should not have the same return type as non-optional attrs. If that were the case, the code would not compile when linked to the IFC4 schema.
For now something has to be implemented with an ifdef USE_IFC4 and hasPosition(). If I get a chance later this week I will fix it, if somebody doesn't beat me to it with a pull request.
Kind regards,
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm sorry I came across as pessimistic, it was not my intention; I clearly didn’t look deeper enough.
The new attribute access system in the c_sharp branch is definably a good way to make the code in IfcGeom a lot more format independent. Is there anything, besides time, stopping us from applying it to the main branch?
For now, I’m looking into the implementation of the temporary solution with USE_IFC4.
Kind regards,
Ian
Last edit: Ian Clévy 2015-11-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No worries, didn't mean to sound offended or anything. Nothing stopping us in particular, except for backwards compatibility. There is a lot of changes coming to the way the schema is being converted as part of the 0.6.0 release [1]. Probably this change will find its way there as well.
Ultimately, maybe it would be best if the schema can be defined by various preprocessor directives that specify how various things are mapped.
Hi,
I’ve been trying to load Ifc4 files with IfcOpenShell. I only looked at a few IfcRepresentationItems but, from what I can gather, there is no implementation of Ifc4 in IfcGeom. Is this correct?
For example, in IfcExtrudedAreaSolid the position parameter is optional in Ifc4. Currently the IfcGeom code assumes it isn’t optional and doesn’t test hasPosition() before trying to access the position.
If so, are there any plans to implement it? How do you plan to do it?
Thanks,
Ian
Hi Ian,
You're a bit too pessimistic, there have been some IFC4 items implemented in IfcOpenShell, e.g:
https://github.com/IfcOpenShell/IfcOpenShell/blob/master/src/ifcgeom/IfcGeomShapes.cpp#L814
They are enabled when you compile with USE_IFC4.
Regarding your specific example, actually I wasn't aware of this change. This is related to something that has to change in IfcOpenShell. Accessors of optional attributes should not have the same return type as non-optional attrs. If that were the case, the code would not compile when linked to the IFC4 schema.
This change to attribute accessors is actually already implemented in this branch:
https://github.com/IfcOpenShell/IfcOpenShell/commit/214c22896244525267936242895e1ee7c58fe3e0
For now something has to be implemented with an ifdef USE_IFC4 and hasPosition(). If I get a chance later this week I will fix it, if somebody doesn't beat me to it with a pull request.
Kind regards,
Thomas
Hi Thomas,
I'm sorry I came across as pessimistic, it was not my intention; I clearly didn’t look deeper enough.
The new attribute access system in the c_sharp branch is definably a good way to make the code in IfcGeom a lot more format independent. Is there anything, besides time, stopping us from applying it to the main branch?
For now, I’m looking into the implementation of the temporary solution with USE_IFC4.
Kind regards,
Ian
Last edit: Ian Clévy 2015-11-04
Hi,
No worries, didn't mean to sound offended or anything. Nothing stopping us in particular, except for backwards compatibility. There is a lot of changes coming to the way the schema is being converted as part of the 0.6.0 release [1]. Probably this change will find its way there as well.
Ultimately, maybe it would be best if the schema can be defined by various preprocessor directives that specify how various things are mapped.
[1] https://sourceforge.net/p/ifcopenshell/discussion/1782718/thread/b5e3ee85/
Kind regards,
Thomas