Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OCR for construction documents does not work, we fixed it

getanchorgrid.com

Post reply on HN
Print view View original

41–50 of 103 posts

Re: OCR for construction documents does not work, we fixed it

#41

Post by instig007 »

jsidney wrote: post #32
wang_li wrote: post #27

Earlier quoted context omitted.

Why does the workflow lie at the level of a real or virtual piece of paper and not in the metadata from the applications used to create that piece of paper? Seems like a CAD tool would allow you to identify each element of the drawing, assigning metadata as required.

Only a small set of construction stakeholders participate in the CAD ecosystem (e.g., architects, large GCs) while a broader set of stakeholders (subcontractors, trades, smaller GCs/CMs) do not receive BIM files and work with PDFs. CAD/BIM is a wonderful aspiration but for many the reality is PDFs.

Re. "CAD/BIM", technically speaking CAD doesn't imply BIM, and the industry's promotion of BIM is akin to AI promotion among software engineering teams - the benefits aren't clear upon detailed review of the advertised capabilities. The CAD part, on the other hand, is generally recognized as the essential tooling for the profession and I'm surprised to hear that it just is a "wonderful aspiration".

Re: OCR for construction documents does not work, we fixed it

#43

Post by dylan604 »

wcisco17 wrote: post #36
frogguy wrote: post #35

Looks cool! Where are you getting the data to finetune the cv models for element extraction? I'm worried there isn't a robust enough dataset to be able to build a detection model that will generalize to all of the slightly different standards each discipline (and each firm for that matter) use.

good q — we don't train on customer drawings. Our detection models are trained on a curated dataset of architectural drawings we've sourced and labeled ourselves, focused on the most common fixture and element types across CSI divisions. The generalization problem you're pointing at is real and it's the hardest part of this. Our approach is to keep the detection scope tight — rather than trying to generalize across e…

How in the world is an answer to a question from the account posting TFA replying directly to said question getting killed?

Re: OCR for construction documents does not work, we fixed it

#44

Post by dylan604 »

Iulioh wrote: post #26
oritron wrote: post #8

Earlier quoted context omitted.

What software made the bitmap? Seems like a step earlier in the pipeline could help generate a BOM more easily.

I'm not really sure and I don't have access to it, I just recive flat PDFs or TIFFs A lot of them are "archival" so I'm pretty OOL

You might even be SOL

It is telling that so many of the comments here assume the person with a thing that is not the most practical would be easily able to request thing in a different format. The assumption that the person with the inconvenient thing would never have thought to ask if more convenient thing was available and just willfully toiling with the inconvenient thing is kind of insulting.

Re: OCR for construction documents does not work, we fixed it

#45

Post by wcisco17 »

sreekanth850 wrote: post #39

We’re taking a different path, building a parsing engine that converts CAD (DWG/DXF) into fully structured JSON with preserved semantics (no ML in the critical path).We also have a separate GIS parser that extracts vector data (features, layers, geometries) independently, Like to know how you handle consistency and reproducibility across runs using models and how you make it affordable, especially at scale. because a…

interesting yeah parsing DWG/DXF natively makes sense when the source file is clean and well-structured. The precision argument is valid in controlled environments.

The challenge we kept running into is that construction drawings in the wild aren’t always that clean. Unresolved xrefs, exploded dynamic blocks, version incompatibilities, SHX font substitutions — by the time a PDF hits a GC’s desk it’s often the only reliable artifact left. The CAD source may not even be available.

That’s why we see vision becomes the more pragmatic path — not because it’s more precise than structured CAD parsing, but because PDFs are the actual lingua franca of construction. Every firm, every trade, every discipline hands off PDFs. So we made a bet on meeting the document where it actually lives.

On consistency and reproducibility — that’s a real challenge with vision models. Our approach is to keep detection scope narrow and validate confidence scores on every output rather than trying to generalize broadly. Happy to go deeper on that if useful.

Re: OCR for construction documents does not work, we fixed it

#46

Post by axus »

testUser1228 wrote: post #40
alexeischiopu wrote: post #12

Earlier quoted context omitted.

I’m building a similar platform, with electrical being furthest ahead - SLD, panels, lights, power, comms. Also do doors, windows, and mechanical equipment. dm, and I can include you in the next preview.

I'm not sure how to dm on here, but I'm very interested

You can paste "who is alexeischiopu" to a search engine, and since there isn't an athlete with the same name, a good candidate appears.

Re: OCR for construction documents does not work, we fixed it

#47

Post by oneneptune »

sreekanth850 wrote: post #39

We’re taking a different path, building a parsing engine that converts CAD (DWG/DXF) into fully structured JSON with preserved semantics (no ML in the critical path).We also have a separate GIS parser that extracts vector data (features, layers, geometries) independently, Like to know how you handle consistency and reproducibility across runs using models and how you make it affordable, especially at scale. because a…

Is this a service / product you plan to offer outwardly? I'd be interested in learning more. Use case: estimation.

Re: OCR for construction documents does not work, we fixed it

#48

Post by oneneptune »

dylan604 wrote: post #44
Iulioh wrote: post #26

Earlier quoted context omitted.

I'm not really sure and I don't have access to it, I just recive flat PDFs or TIFFs A lot of them are "archival" so I'm pretty OOL

You might even be SOL It is telling that so many of the comments here assume the person with a thing that is not the most practical would be easily able to request thing in a different format. The assumption that the person with the inconvenient thing would never have thought to ask if more convenient thing was available and just willfully toiling with the inconvenient thing is kind of insulting.

Also, in the construction industry you get an updated drawing file a day before the bidding closes... good luck getting the GC to send more detailed files (that they themselves got elsewhere) in that time. You're better off sending it to your estimation department in India and letting them work through the night to put together the new estimations.

Re: OCR for construction documents does not work, we fixed it

#50

Post by hackcasual »

Terr_ wrote: post #15

> OCR for construction documents does not work I'm reminded of the Xerox JBIG2 bug back in ~2013, where certain scan settings could silently replace numbers inside documents, and bad construction-plans were one of the cases that led to it being discovered. [0] It wasn't overt OCR per se , end-user users weren't intending to convert pixels to characters or vice-versa. [0] https://www.youtube.com/watch?v=c0O6UXrOZJo&t=…

JBIG2 does glyph binning, as you say not exactly OCR, but similar. So chunks of the image that look sufficiently similar get replaced with a reference to a single instance.
Post reply on HN