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

81–90 of 103 posts

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

#81

Post by alexeischiopu »

h317 wrote: post #51

I cannot wait for the day when tech companies become players in the construction industry because it looks like it is the only way forward to make a change. To think that everything has been digitalized a long time ago, yet contract law cannot properly deal with delineating responsibilities between GC and Architects, who are still sending 2D drawings to each other. Imagine, all this information about quantities and d…

I couldn’t agree more. The fact this data isn’t programmable is really holding the industry behind.

When building PlanGrid there were so many things we wished we could have done had this been unlocked.

I’m now working on doing just that.

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

#82

Post by alexeischiopu »

copypaper wrote: post #80

Very interesting. Im on vacation but will check this out at work next week. What is the maximum resolution you support for PDFs? The max gemini will do is 3072x3072. We have plans that are 10x that size.

What divisions information do you need?

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

#83

Post by copypaper »

alexeischiopu wrote: post #82
copypaper wrote: post #80

Very interesting. Im on vacation but will check this out at work next week. What is the maximum resolution you support for PDFs? The max gemini will do is 3072x3072. We have plans that are 10x that size.

What divisions information do you need?

Mainly 09, but also 05 and 07.

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

#84

Post by Dylan16807 »

thaumasiotes wrote: post #79
Dylan16807 wrote: post #75

Earlier quoted context omitted.

You asked what the difference was, and I said the difference. Was it unclear that to fit the phrasing of your question, we add "OCR doesn't"? I would not personally call Jbig2 OCR.

> You asked what the difference was, and I said the difference. Take another look at my comment.

Let me try rephrasing to make the response to your original comment as clear as possible.

Question: "How can we describe OCR that wouldn't match this definition exactly?"

Answer: This definition largely fits OCR, but "reference to a single instance" is a weird way to phrase it. A better definition of OCR would include how it uses builtin knowledge of glyphs and text structure, unlike JBIG2 which looks for examples dynamically. And that difference in technique gives you a significant difference in the end results.

Is that better?

The definition you quoted is not an "exact" fit to OCR, it's a mildly misleading fit to OCR, and clearing up the misleading part makes it no longer fit both.

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

#85

Post by Terr_ »

thaumasiotes wrote: post #69
hackcasual wrote: post #50

Earlier quoted context omitted.

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.

> not exactly OCR, but similar. So chunks of the image that look sufficiently similar get replaced with a reference to a single instance. How can we describe OCR that wouldn't match this definition exactly?

It's not too hard, while they share some mechanics, the underlying use-cases and requirements are very different.

_______ Optical character recognition:

1. You have a set of predefined patterns of interest which are well-known.

2. You're trying your best to find all occurrences of those patterns. If a letter appears only once, you still need to detect it.

3. You don't care much about visual similarity within a category. The letter "B" written in extremely different fonts is the same letter.

4. You care strongly about the boundaries between categories. For example, "B+" must resolve to two known characters in sequence.

5. You want to keep details of exactly where something was found, or at the least in what order they were found. You're creating a layer of new details, which may be added to the artifact.

_______ "Glyph compression":

1. You don't have a predefined set of patterns, the algorithm is probably trying to dynamically guess at patterns which are sufficiently similar and frequent.

2. Your aren't trying to find all occurrences, only sufficiently similar and common ones, to maximize compression. If a letter appears only once, it can be ignored.

3. You do care strongly about visual similarity within a category, you don't want to mix-n-match fonts.

4. You don't care about clear category lines, if "B+" becomes its own glyph, that's no problem.

5. You're discarding detail from the artifact, to make it smaller.

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

#86

Post by ichamo »

Really interesting to see this space developing. I'm building a masonry-specific quantity takeoff tool (vision model extraction into a parametric domain model that spits out bid-ready quantities) and the "data prison" framing resonates hard.

One thing I've learned going deep in a single trade: the distance between "structured JSON from a drawing" and "numbers an estimator will bid with" is enormous. I've been really impressed with Bobyard and SketchDeck especially.

h317's point about the liability-driven re-counting circus is spot on. Each party in the chain needs to own their numbers. Revit could have solved this a long time ago had this not been the case. An API that makes each individual count faster is valuable but it doesn't collapse the chain.

Would love to talk to anyone else building in this space.

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

#87

Post by alexeischiopu »

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

Can reach me at alexei@usevawn.com

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

#89

Post by sreekanth850 »

oneneptune wrote: post #47
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.

Happy to say that yes. We are in final round of polishing. mostly opening in couple of weeks. We are mainly targeting such uses cases where you can add CAD files into RAG or analytics or search pipeline without losing source of truth or geometry. I will definitely post here when we are ready, keep an eye and it will be free during beta, so you can play how much you want with it.

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

#90

Post by sreekanth850 »

wcisco17 wrote: post #45
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 re…

As a part of our product development, we had fought with PDF so much, even we have a generic PDF parser with triple pipeline (One for single column, another for multi column and third for complex table based layouts) yet we are not getting 100% accuracy, I would say that it's bit risky to bet on PDF. PDF often is the most complex format ever made and it was never made for data extraction. And You are right that vision models are the only way but hallucination is real.
Post reply on HN