> OCR for construction documents does not work<p>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]<p>It wasn't overt OCR <i>per se</i>, end-user users weren't intending to convert pixels to characters or vice-versa.<p>[0] <a href="https://www.youtube.com/watch?v=c0O6UXrOZJo&t=6m03s" rel="nofollow">https://www.youtube.com/watch?v=c0O6UXrOZJo&t=6m03s</a>
If I recall it was an artifact of the compression algo.<p>Full context and details: <a href="https://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_are_switching_written_numbers_when_scanning" rel="nofollow">https://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres...</a>
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.
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.<p>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.<p>Imagine, all this information about quantities and door types (and everything else) is already available and produced by the architect's team, BUT they cannot share it! Because if they do, they are responsible for the numbers in case something is wrong.<p>So now there is this circus of:
Arch technologist making the base drawing with doors.
GC receives documents, counts doors for verification, and sends them to the sub.
Subcontractor looks at these drawings, counts them again, and sends data to the supplier.
Guess what, the supplier also looks, counts, confirms, and back we go.<p>Though I think robotics will change all of that. And when we have some sort of bot assistance, big tech players will have a bigger leverage in this, which will lead to the proper change management architecture.<p>Anyway, cool product. Anything to help with estimation. Really hope it gets traction.
I had a job as HVAC engineer for the upgraded Oslo Airport back in 2011; started doing HVAC work for 3 weeks the rest was programming trying to make the rest of people more efficient. Made an Excel sheet with a lot of macros to manage all the drawing of the airport. That’s why I switched to programming when I continued to study, and did not want to come back before I got more experience.<p>They even gave me a big desk at Trondheim/Tyholt so I could help them with the software during my studies.
Hey thanks!! For estimation we cover division 08 (doors and opening) you can use it for your estimating purposes with these two endpoints:<p>- Counting all the doors: <a href="https://www.getanchorgrid.com/developer/docs/endpoints/drawings-doors" rel="nofollow">https://www.getanchorgrid.com/developer/docs/endpoints/drawi...</a>
- Extracting schedules in architectural drawings:
<a href="https://www.getanchorgrid.com/developer/docs/endpoints/drawings-schedules" rel="nofollow">https://www.getanchorgrid.com/developer/docs/endpoints/drawi...</a><p>and use Claude or any other AI tool to wire up the UI<p>We're releasing toilets (division 10) later this week, then floors and pipes next.
I’ve worked on projects where a lot of work was done in highly collaborative drawings on Bluebeam, in which vendors add their markups and items and the program facilitates counting it all at the end of the phase. My role was only in things like wireless AP placement and low voltage cabling drop locations, not anything safety critical like doors, but I assume those vendors were able to keep track of those items in a similar way. For actual engineering projects I’m glad so many people have to take the time to count.
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 as far as i know CAD and GIS need precision and accuracy.
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.<p>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.<p>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.<p>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.
Dumbcad line barf will not help you with that at all.<p>There already is a format that is plain text and preserves the semantics: IFC. That's what it was made for.
Is this a service / product you plan to offer outwardly? I'd be interested in learning more. Use case: estimation.
First off, congrats on the launch! Construction is a tough market to build in. My personal view after being in it a for a few years is that there is no shortage of MVPs. In fact there is an MVP for every problem at every level (or at least it feels that way) but construction is /vast/ and the rough edges that seem juicy at first, in practice are optimizations rather than bottlenecks for constructors.<p>I hope you succeed because it would be great to have a standard API for this data, but I would advise on one of two directions: become the standard by being close to 100% accurate at finding symbols (one symbol doesn't seem to cut it in our testing) or make a great, comprehensive workflow for a small subset of the market and become standard that way.<p>In both cases, you cannot do a broad 'market test', you need to spend many hours with a specific sub-set of users in construction.<p>Disclaimer: I'm a co-founder of Provision.
I ran the example doors given and it missed 9 swinging doors, some that were in double swing pairs, and a few that were just out on their own not clustered. Not bad overall though
Do that for Finnish construction documents. My parser is 30000+ lines candidate based but the lack of standards and the Finnish language...
I have been working on an extension of this problem lately that involves extracting all doors + any details about those doors to produce quotes. I have found giving the pdf to codex pretty good at it as it can take subcrops of the plans to look at certain areas of high noise in more detail. Only downside is cost is quite high.
«Why we did it»; would rather have a “How we did it”. The why gave me AI generated marketing material feelings.<p>Tailscale’s article about NAT traversal is an example of how to write “how we did it”: <a href="https://tailscale.com/blog/how-nat-traversal-works" rel="nofollow">https://tailscale.com/blog/how-nat-traversal-works</a>
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.<p>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 every firm's conventions, we train on a small but high-quality set of fixtures and optimize for precision within that scope.<p>The result is high confidence outputs on the elements we support, rather than mediocre coverage across everything.<p>We're expanding the detection surface incrementally as we validate accuracy division by division!
What do you foresee being the end use case for this (or most valuable use case)?
Anyone building in or for construction tech — whether that's a startup building estimating or project management software, a construction company with an internal tech team solving this themselves, or a builder looking to automate their workflow. The common thread is drawings. Every one of those groups lives and dies by their ability to extract actionable data from a PDF that was never designed to be machine-readable. We're building the layer that makes that possible so they don't have to start from scratch.
When will this be available for 30000x8000px electrical diagrams?<p>I have to make a BOM and oh boy I hate my job
What software made the bitmap? Seems like a step earlier in the pipeline could help generate a BOM more easily.
I’m building a similar platform, with electrical being furthest ahead - SLD, panels, lights, power, comms.<p>Also do doors, windows, and mechanical equipment.<p>dm, and I can include you in the next preview.
I'm not sure how to dm on here, but I'm very interested
I work in the automotive field, I don't know if this complicates the things further but I appreciate any help!
What do you hate the most?
Great points raised!
Good idea :)
cool. What's pricing like?
Love it! <i>Starbucks Vente Machiato sip</i><p>Love to give it to an arc client, not sure who the right person to implement this would be? Hmm…
[flagged]
Yeah OCR for technical is largely solved we're targeting the construction documents space For construction specs we have a few endpoints:
- <a href="https://www.getanchorgrid.com/developer/docs/endpoints/specs-parse" rel="nofollow">https://www.getanchorgrid.com/developer/docs/endpoints/specs...</a>
- <a href="https://www.getanchorgrid.com/developer/docs/endpoints/specs-content-extract" rel="nofollow">https://www.getanchorgrid.com/developer/docs/endpoints/specs...</a><p>so you would want these documents translated lets say to German, mandarin, ect?
Of course it is not working. PDF and images are supposed to be tamper resistant. OCR tries to reverse engineer them.
Your smart features looks like a game changer? Nice job!