We parse symbols using a mix of vector geometry, OCR, and learned detection for common architectural/MEP symbols. Cross-discipline checks are a big focus as we already flag mismatches between architectural, structural, and MEP sheets, and we’re expanding into deeper electrical/mechanical spec alignment next. Would love to hear which symbols matter most in your workflow so we can improve coverage.
I do electrical so parsing lighting is often a big issue. (Subcontractor)
One big issue Ive had is drafters use the same symbol for different things per person. One person's GFCi is another's switched receptacle. People use the specialty putlet symbol sometimes very precisely and others not. Often accompanied by an annotation (e.g. 6-15R).
Dimmers being ambiguous is huge; avoiding dimming type mismatches is basically 80% the lutron value add.
This is exactly the hard part symbols aren’t enough when each drafter overloads them, so we lean on the annotation + schedule context (fixture tags, notes like “DIM,” control zones, panel/ckt callouts, and control intents) to disambiguate.
We're in a similar space doing machine assisted lighting take offs for contractors in AU/NZ, with bespoke models trained for identifying & measuring luminaires on construction plans.
Compliance is a space we've branched into recently. Would be super interested in seeing how you guys are currently approaching symbol detection.
Happy to swap notes. If you send a representative lighting plan set, we can run it and share how the detector clusters, resolves, and cross-references symbols across sheets. Always excited to compare approaches with teams solving adjacent problems.
What do you mean when you say "vector geometry"? Are you using the geometry extracted from PDFs directly? I'm curious how that interacts with the OCR and detection model portion of what you're doing
Great question. By “vector geometry” we mean we’re using the underlying CAD-style vector data embedded in many PDFs (lines, arcs, polylines, hatches, etc.), not just raster images. We reconstruct objects and regions from that geometry, then fuse it with OCR (for annotations, tags, labels) and a detection model that operates on rendered tiles. The detector + OCR tells us what something is; the vector layer tells us exactly where and how it’s shaped so we can run dimension/clearance and cross-sheet checks reliably.
Woah! What determines if something is an object at that vector level? I've done some light PDF investigations before and the whole PDF spec is super intimidating. Seems insane that you can understand which things are objects in the actual drawing at the PDF vector level
Yep, exactly, when layer data survives the PDF export, it’s a huge help. We use it as a weak signal for clustering and object grouping, but never rely on it fully since it’s often inconsistent or stripped. When it’s there, accuracy and speed both improve noticeably.
