Use case
Revision comparison, element by element
Why it is awkward
The part that is not obvious
What comes back
- Elements added since the previous issue
- Elements removed
- Elements moved, with the distance
- Text and tag changes, including renamed rooms
- A per-sheet change list, not a coloured overlay
How it is read
From line art to a record
- Stage 1
Read both issues into elements
Each issue is analysed on its own first — rooms, doors, windows, text, dimensions. Comparison only becomes possible once both sides are structured data, which is why this is the last use case to add rather than the first.Two structured sheets - Stage 2
Register the sheets
Two issues are rarely plotted at the same origin, scale or paper size. They are aligned on stable features — the grid, the title block, the building outline — so that a difference in plotting is not reported as a difference in design.A common coordinate frame - Stage 3
Match element to element
Elements are paired across the two issues by position, tag and type. What fails to pair is the interesting part, and pairing is what distinguishes a door that moved from a door that was deleted and another added.Paired, added and removed elements - Stage 4
Classify and cross-check
Pairs are classified as unchanged, moved with a distance, or altered in text. Revision clouds are read where present as a cross-check — useful for confirming changes, and more useful for finding the ones nobody clouded.A change list per sheet
The output
What lands in your system
| Field | What it contains |
|---|---|
| changes[].type | Added, removed, moved or text-changed |
| changes[].element | What changed, with its type and tag on whichever issues carry it |
| changes[].distance | How far a moved element travelled, at drawing scale |
| changes[].from / .to | Previous and current values for text, tags and dimensions |
| summary | Which sheets in the set changed at all, so a hundred-page set can be triaged in one pass |
Where it goes wrong
The cases worth knowing about first
Detection misses read as changes
A door found in one issue and missed in the other is reported as a change that never happened. Comparison inherits whatever accuracy detection has on your drawings, which is why it is worth tuning detection before relying on a change list.
Replotted, not redesigned
A sheet reissued at a different scale, origin or paper size differs everywhere at pixel level and nowhere in substance. Registration is what prevents that, and a sheet that cannot be registered is reported as such rather than diffed anyway.
Sheets renumbered between issues
Pairing is done on sheet numbers from the title block, so a renumbered or split sheet has no partner. Those are listed as unpaired for someone to match by hand rather than being quietly compared against the wrong sheet.
What fine-tuning on your drawings adds
Start here
See it on a sheet of your own
- Elements added since the previous issue
- Elements removed
- Elements moved, with the distance
Send us one sheet
We run it through our floor plan models and send back the extracted data with an annotated overlay, so you can see what comes off your own drawings before anyone books a call.
- Back in about 2 business days
- PDF, DXF or a scan
- NDA on request
FAQ
Questions on this one
No. Clouds are read where present and are a useful cross-check, but the comparison is done on the elements themselves — which also catches changes nobody remembered to cloud.
Yes. Sheets are paired by number from the title blocks, and the output is a change list per sheet plus a set-level summary of which sheets changed at all.
Get in touch
Tell us what is on your drawings
Describe the sheets you get and what you need off them. We will tell you what our models already handle, what needs fine-tuning on your drawings, and what is not worth automating at all.
- Reply time
- Within 1 business day
Would rather show than tell? Send one sheet for a free analysis