See #6835. Qto_OpeningElementBaseQuantities came out axis-scrambled for
openings authored in a Z-up local frame (X along the voided wall, Y
through it, Z vertical), which is how Bonsai authors every wall opening:
- The IfcOpenShell engine mapped Height to the local Y extent and Depth
to the local Z extent, so a 0.9 x 2.0 door opening with Bonsai's
default 1.2m void depth reported Height 1.2 and Depth 2.0, and Area
(max side area) picked the through-wall side, 2.4 instead of 1.8.
This matches the wrong Height=1.2/Area=1.2 screenshots reported for a
1x1 window opening in #6835.
- The Blender engine mapped opening Width to get_length, which returns
the longest bounding box edge, i.e. the opening height for typical
door openings (the same defect 4adaf0d fixed for IfcDoor Width), and
get_opening_depth used min(x, y), which returns the opening width
whenever the width is smaller than the void depth.
The IfcOpenShell engine now has opening-aware internal calculators
(get_opening_width/height/depth/area) that detect horizontal (slab
style) openings with the same heuristic as the Blender calculator, so
slab opening depths keep reporting the slab thickness. The Blender
ruleset uses get_x for opening Width, and get_opening_depth measures the
through-element Y extent for vertical openings.
Door and window quantities themselves are addressed separately: the
Blender engine door Width was fixed in 4adaf0d, and the remaining
door/window defects (door not quantified on the IfcOpenShell engine,
inflated areas) are fixed by the attribute-based calculators in #8389.
Generated with the assistance of an AI coding tool.
(cherry picked from commit efac8a0ec0)
ItemIsASum and Quantities are exporter columns that were missing from
MAIN_CSV_HEADER_COLUMNS, causing them to be misidentified as numeric cost
value categories on re-import. Also initialise rate_cost_schedule to None
before the search loop to avoid UnboundLocalError when no match is found.
Generated with the assistance of an AI coding tool.
IfcQuantity* carries an optional Formula (IfcLabel) documenting how a
quantity was derived. Export it alongside each quantity so it survives
in the Quantities column.
The per-quantity entry shape grows from [name, value] to
[name, value, formula], which stays backward compatible for positional
consumers reading index 0/1. Formula is read with a schema-safe getattr
(it does not exist on IfcPhysicalComplexQuantity, nor in IFC2X3) and is
coalesced to "" when absent.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
serialise_cost_quantities built the "Quantities" JSON string by manual
concatenation, inserting quantity.Name and the related element's Name
without any escaping. A name containing a double quote, backslash or
newline produced invalid JSON, breaking any downstream parser (e.g. a
Typst json.decode consumer reporting "failed to parse JSON"). It also
crashed with a TypeError when a name was None (str += None).
Build a Python list and serialise it with json.dumps instead, keeping
the exact same [[name, value], ...] output shape, the element-name
prefix and the unsupported-type behaviour. None names are coalesced to
"" and quantity values are defensively coerced to float.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Documentation claimed that ODS/XLSX output was to a given filename, but
the code actually writes files with generated names in a folder.
(also create the folder if necessary for convenience)
* Export_IfcCostSchedule_to_PDF_improvements
* IfcCostSchedule CSV export: Added ItemIsASum column
New column in the ifc export that tracks if IfcCostItem is a sum, also added a new static method to the IfcDataGetter class.
* IfcCostSchedule CSV export: Added cost quantities column
Cost quantities are a serialsed list containing the name of the quantity and the quantity value.
* IfcCostScheduel PDF export: add options to fine tune export
New options include nested_structure_depth, should_print_cover, should_print_description, should_print_rates, should_print_summary, should_print_cost_ids.
Also pass project currency to typst (still not used).
Added footer with "proudly created with IfcOpenShell".
Updated Cover with formatting and IfcCostSchedule Description
`settings` wasn't defined, so `create_shape` was always resulting in an error. Also, `create_shape` is returning `Triangulation` in this kind of cases, so there's no `.geometry`.
Also removed IfcCircleProfileDef if-check since it's covered by IfcParameterizedProfileDef.
I guess after all it's not very reliable idea since it's possible to have a cost schedule without quantities (even non-SoR) and it's giving users false assumptions that they don't need to worry about "Is Schedule of Rates" flag in some cases.
Petru Conduraru