- The patch was failed when executed from Bonsai since self.src wasn't provided, fixed now.
- Added a temporary hack to diplsay file selector for this patch.
- small refactor.
* fix: Rename the "MergeProject" recipe to "MergeProjects"
This rename, alongside renaming "filepath" to "filepaths" and adjusting the docstring has been done to clarify, that this patch can be used to merge multiple IFC files into one (and not just two)
* fix: Fix `test_Merge_Project.py`, which was broken due to renaming the patch recipe
It was leaving an orphaned pset if 'products' was a list of all elements pset is assigned to. Then it would create a new pset for each element leaving original pset orphaned.
In IFC it's possible for a property set to be assigned to multiple elements and which may lead to confusing behaviour when you edit a pset on one element and other element seems to get edited too.
Which makes it worse is that that it is possible that some software is might be doing this unintentionally when exporting IFC (as some sort of optimization as storing 1 is more optimal than n copies of it).
So now there are some tools in Bonsai and in IfcOpenShell to handle the shared psest:
1) Indication that property is shared - https://imgur.com/a/9dd3jST (similar to how Blender indicates ID data-block users). You can click on it to "unshare" the pset - a new copy for the pset will be created and it's going to be linked only to the active object.
2) api pset.unshare_pset method that does the same. And util.element.get_elements_using_pset method that encapsulates schema differences and different approaches for occurrences/types.
3) ifcpatch recipe 'UnsharePsets' that's making all property sets in the IFC file to have just 1 element that's using them. You can limit the affected elements by providing query.
ifcpatch recipe is also available in Bonsai - https://i.imgur.com/aOCx7HI.png
Instead of specifying parameters `a`, `b`, `c` and `d`, more meaningful parameters have been introduced (`threshold`, `automatic_offset_point`, `x`, `y` and `z`), which allow to do the same operations in a more understandable way.
This change affects the following recipes: `OffsetObjectPlacements`, `OffsetStoreyElevations`, `SetFalseOrigin`, `SetRefElevation` and `SetWorldCoordinateSystem`
Since there is a limited number of choices, a string property wouldn't be very helpful. Use a dynamic enum property (which is adjusted according to which types of SQL are available) instead.
Andrej730
