Bonsai's Pset/Qto editor could display a property or quantity's own Unit
override, but had no UI to author one -- only the project-level Project
Units panel existed, which sets defaults, not per-instance overrides.
Builds on the edit_pset/edit_qto Unit-wrapping support and the
get_unit_scale/get_candidate_units helpers added in the previous commit.
- bim/prop.py: Attribute gains unit_id (the STEP id of the property's own
override, 0 = project default) and unit_id_enum (the dropdown-driving
dynamic enum, "Default (<symbol>)" plus every candidate unit for the
attribute's measure type). update_attribute_unit_id converts the stored
value live when a different unit is picked, so the physical quantity is
preserved rather than the number being silently relabeled.
- tool/pset.py: is_measurable_special_type/get_candidate_units_for_special_type/
resolve_effective_unit/convert_attribute_unit support the picker and the
live conversion. get_special_type_for_prop classifies a property by its
value's own declared measure type, falling back to an explicitly-attached
Unit for generic numeric types (e.g. IfcReal) whose spec carries no unit
semantics of its own but which may still legitimately carry one. Seeding
in import_pset_from_existing ignores a stray Unit attached to a property
whose value has no numeric/measure semantics at all (e.g. text), which
used to crash trying to select an identifier the picker's enum items
never include.
- bim/module/pset/ui.py: the picker widget itself, next to the value field
in edit mode, gated on the attribute being measurable.
- bim/module/pset/operator.py: EditPset wraps measurable values with their
chosen Unit on save, for both properties and quantities. The qto
rounding-loop fix reaches into the wrapped dict instead of assuming a
bare float/int, which would otherwise zero out every unit-overridden
quantity.
Adds regression tests across all of the above, including conversion
correctness, explicit-clear/default round-trips, an unrelated sibling
property's override surviving untouched, and the stray-Unit crash guard.
edit_pset()'s unpack_unit_value() couldn't distinguish "no Unit dict was
passed" from "{"Unit": None, ...} passed to explicitly clear an existing
override" -- both collapsed to a bare None, and every consuming call site
checked truthiness, so there was no way to actually clear a previously-set
property Unit override once one existed. Fixed with a private _NO_UNIT
sentinel; bare (unwrapped) values still leave Unit untouched exactly as
before.
edit_qto() had no Unit-handling capability at all: neither
update_existing_property() nor add_new_properties() ever read or wrote a
quantity's Unit attribute. Added the same {"Unit": ..., "NominalValue": ...}
wrapped-dict convention edit_pset() already supports, disambiguated from
the pre-existing IfcPhysicalComplexQuantity dict convention
({"Discrimination": ..., "HasQuantities": ...}) by checking for a "Unit"
key -- a complex-quantity spec never contains one.
ifcopenshell.util.unit gains two small helpers:
- get_unit_scale(unit): dispatches to get_derived_unit_scale/
get_named_unit_scale depending on unit type, also used to de-duplicate
calculate_unit_scale()'s own inline dispatch of the same logic.
- get_candidate_units(ifc_file, unit_type): all units in a file matching a
given unit type, unlike get_project_unit()'s single-default lookup.
Adds regression tests for all of the above, including explicit-clear,
bare-value-preserves-override, and complex-quantity-routing-unaffected
cases.
Previously, unit symbols only appeared while a Pset/Qto was in edit mode
(pencil icon) -- the read-only summary view read raw {name: value} dicts
straight from ifcopenshell.util.element.get_psets(), a completely separate
path from the Attribute/unit_symbol machinery, so it never showed a label
even after the earlier fixes. This matters for the "someone in the field
just looking at values" use case, not just editing.
- bim/module/pset/data.py: switch to get_psets(verbose=True) to get each
property's own entity id, then resolve its unit symbol the same
override-aware way the edit-mode path does (tool.Pset.get_unit_symbol_for_prop).
Falls back gracefully (empty symbol) for IfcPreDefinedPropertySet
attributes, which aren't IfcProperty entities and can't carry a Unit
override.
- bim/module/pset/ui.py: read-only value button now shows "250 mm" instead
of just "250".
Also adds the regression tests planned but not yet committed:
- test/tool/test_pset.py: edit a property with its own Unit override and
write it back, confirming no rescale and the override survives.
- test/bim/test_prop.py (new): get_display_name() falls back to the plain
name (no crash) when no unit is resolvable or the project has no units
assigned at all.
NominalValue is optional -- IfcPropertySingleValue permits a null value --
but get_property_unit() unconditionally accessed prop.NominalValue.is_a(),
crashing on any single-value property that's legitimately blank.
Also adds a regression test confirming IfcContextDependentUnit symbols
("each", "boxes", etc.) aren't shadowed by the IfcDerivedUnit branch added
in the previous commit.
IfcSIUnit.Dimensions is a schema-derived attribute that isn't computed for
Bonsai's SQLite-linked "large model" file representation, returning None
there instead of an IfcDimensionalExponents entity. #9278 added an
unconditional unit.Dimensions.LengthExponent access to every IfcSIUnit
processed by calculate_unit_scale(), so it crashed project loading for
any linked file, even ones with no unit prefixes at all -- not just the
prefixed-area/volume case the fix targeted.
Fixed by reading dimensions from the existing si_dimensions table (keyed
by the unit's stored Name, not the unresolvable derived attribute) instead
of unit.Dimensions.
See the PR discussion for a standalone reproduction script.
Led to error during OpenCOLLADA build:
```
2026-08-28 13:33:34,391 make[2]: *** No rule to make target `/Users/runner/work/IfcOpenShell/IfcOpenShell/build/Darwin/arm64/10.15/install/pcre-shared-8.41/lib/libpcre.so', needed by `lib/libOpenCOLLADABaseUtils.dylib'. Stop.
2026-08-28 13:33:34,391 make[2]: *** Waiting for unfinished jobs....
```
Just to use consistent patches between the builds. It was previously guarded by `WASM`, but it was a dead code - `OpenCOLLADA` is skipped on wasm, so it was never exercised.
Regarding the "specializing std::hash outside of the std:: namespace" issue on gcc - it was caused by patch missing fixes for `COLLADABU_HASH_NAMESPACE_OPEN` and `COLLADABU_HASH_NAMESPACE_CLOSE`. So in theory it should have also result in an error in clang or in an invalid code/ub. Either way, now it's fixed.
See logs below for example issue I've met locally when I had just `RocksDBTargets-relwithdebinfo.cmake`.
Providing a list of configs makes it try to use matching config first and only then try `Release` as a fallback, otherwise it was now requiring `Release` builds.
```
CMake Error in CMakeLists.txt:
IMPORTED_LOCATION not set for imported target "RocksDB::rocksdb"
configuration "RelWithDebInfo".
```
* Modifications to build C++ with Visual Studio 2026 and the v145 toolset.
* Fixes linker settings for rocksdb for Debug and Release builds
* module is a C++ 20 keyword. Explicitly stating namespace allows cpp20 projects to build against the library
* Fixes crash when initializing an object with the initialize function when some of the attributes are empty, {}, or omitted, std::nullopt
* cleanup for vs2026 v145 toolset per @aothms review
* Fixes bug, IfcCurveSegment.setStartLength was setSegmentLength in alignment_helper.cpp
* Bumps boost to 1.92
Noticed after 5b00c8b45 - build started to break. `--py313` is not needed here, since wasm build doesn't really depend on the provided Python versions and just builds the version it picks up from `pyodide`.
Richard Brice