Bonsai: find a sheet's drawing by path when its data-id is stale - #9469
Open
theoryshaw wants to merge 1 commit into
Open
theoryshaw wants to merge 1 commit into
theoryshaw wants to merge 1 commit into
Conversation
Closes IfcOpenShell#9468. SheetBuilder.remove_drawing located the drawing's <g> by comparing data-id against the reference's STEP id. Those ids only mean anything while the file keeps the numbering it had when the drawing was placed: merging a project, or any round trip that renumbers entities, leaves every data-id in every layout pointing at nothing. The loop then matched nothing and layout_tree.write() ran anyway, so the model lost the IfcDocumentReference while the layout kept the drawing - and the layout was reserialised, giving a changed mtime and a whole-file diff for a removal that never happened. Bonsai's own Sheets panel reads the IFC and showed the drawing gone, so the divergence stayed invisible until something built from the layout disagreed. Look the group up by drawing path when the id lookup fails; the file a drawing points at survives renumbering. Nothing is written when no group is found, and a warning names the layout that was left alone rather than failing silently. The same <g> already carries data-drawing (the drawing's GlobalId), and update_drawing_sizes resolves drawings through it, so remove_drawing was the one place keyed on the unstable half of the pair. Matching on the path rather than the GlobalId keeps this self-contained - no reference-to-drawing lookup is needed - and works on layouts written by any earlier version. Tested on a project whose entity ids had been renumbered by a merge: with the id match alone none of its references resolved, and with the fallback all of them did. Removing four drawings from a sheet then emptied the layout as expected, with no warnings.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #9468.
The problem
SheetBuilder.remove_drawinglocates a drawing's<g>by comparingdata-idagainst the reference's STEP id:STEP ids only mean anything while the file keeps the numbering it had when the drawing was placed. Merging a project — or any round trip that renumbers entities — leaves every
data-idin every layout pointing at nothing.The loop then matches nothing, and
layout_tree.write()runs regardless. The model loses theIfcDocumentReferencewhile the layout keeps the drawing, and the layout is reserialised on the way out: a changed mtime and a whole-file diff for a removal that never happened. Since the Sheets panel reads the IFC, it shows the drawing gone, so the divergence stays invisible until something built from the layout disagrees.The change
Look the group up by drawing path when the id lookup fails. The file a drawing points at survives renumbering; the id does not. Layout hrefs are relative to the layout and URL-encoded, so they are unquoted and joined before comparison.
Two smaller changes come with it:
The same
<g>already carriesdata-drawing(the drawing's GlobalId), andupdate_drawing_sizesresolves drawings through it —remove_drawingwas the one place keyed on the unstable half of the pair. Matching on the path rather than the GlobalId keeps this self-contained: no reference-to-drawing lookup is needed, and it works on layouts written by any earlier version. Happy to switch it to a GlobalId match if you would rather add that lookup.Testing
Three unit tests in
src/bonsai/test/tool/test_sheeter.py:data-idmatch when ids are current, path fallback when they are stale, andNonewhen the drawing is not on that sheet.Also exercised on a real project whose ids had been renumbered by a merge. With the id match alone, none of the sheet's references resolved to a group; with the fallback, all of them did. Removing drawings from that sheet then emptied its layout as expected, with no warnings, and the removals showed up in a downstream tool that reads layouts — which is how the divergence was noticed in the first place.