Hacker News Reader

Comment by knollimar | Hacker News Reader

What kind of system to you have for parsing symbology?

Do you check anything like cross discipline coordination (e.g. online searching specification data for parts on drawings like mechanical units and detecting mismatch with electrical spec), or it wholly within 1 trades code at a time?

edit: there's info that answers this on the website. It seems limited to the common ones (e.g. elec vs arch), which makes sense.

View on HN

Symbol variation is a huge challenge across firms.

Our approach mixes OCR, vector geometry, and learned embeddings so the model can recognize a symbol plus its surrounding annotations (e.g., “6-15R,” “DIM,” “GFCI”).

When symbols differ by drafter, the system leans heavily on the textual/graph context so it still resolves meaning accurately. We’re actively expanding our electrical symbol library and would love sample sets from your workflow.

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

Mamy of the drawings in pdf space have some layer data from CAD/revit attached to them that might make it easier to cluster objects

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.

Reply on news.ycombinator.com