TessellateElements patch was failing because it was relying on optionality of `edges` argument. Though argument itself is currently useless and not used in the code.
It wasn't considering that IfcTaskTimeRecurring might be just created and IfcTaskTimeRecurring.Recurrence is None resulting in error below
File "\api\sequence\assign_recurrence_pattern.py", line 120, in assign_recurrence_pattern
if len(file.get_inverse(settings["parent"].Recurrence)) == 1:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "\file.py", line 524, in get_inverse
inverses = [entity_instance(e, self) for e in self.wrapped_data.get_inverse(inst.wrapped_data)]
AttributeError: 'NoneType' object has no attribute 'wrapped_data'
1) It wasn't removing ownerhistory in the case if task was RelatingObject in IfcRelNests
2) Replaced handling of IfcRelNests as an inverse with direct api calls.
3) Added some basic tests.
It's py.types requirement, similar to 6e2edbf
Example issue without __all__:
import ifcopenshell
import ifcopenshell.api.project
# "create_file" is not exported from module "ifcopenshell.api.project"
ifcopenshell.api.project.create_file()
In IFC4X3 IfcQuantityCount is now more strict and requires only interger values.
Error for a reference:
TypeError: attribute 'CountValue' for entity 'IFC4X3.IfcQuantityCount' is expecting value of type 'INT', got 'float'.
Before - https://i.imgur.com/CYwSGxY.png
After - https://i.imgur.com/Wbe6Ij6.png
I'll attach example .csv and .ifc in #4704
What changed:
1) If query was provided but it didn't found any elements, then it will still autoassign quantity = 0 instead of cost item end up without quantities at all (which has a different meaning in ifc). Works both with Property provided and without it.
2) If provided quantity = 0, it will now load as quantity = 0 instead of not creating any quantities at all.
3) You can provide both Query and Quantity and they all will be added to the cost item. E.g. if Quantity = 15, Query = "IfcWall", Property="Prop" and there are 3 walls in the model each having Prop = 25 then final quantity will be 15+25*3=90. Previously Quantity would take the priority and the result would be just = 15.
Though this is still doesn't work with counting quantities due behaviour in cost.assign_cost_item_quantity.
E.g. if Quantity = 7, Query = "IfcWall", Property="" (to make sure it will just count them) and there are 3 walls in the model then final quantity will be not 7+3=10 but just = 3, as query will take the priority here.
order of objects in .RelatedObjects is important (e.g. for cost items, it's the order of their appearance), so we should maintain it and cannot use sets for .RelatedObjects
Kurt Battisti
