OCR for construction documents does not work, we fixed it (getanchorgrid.com)
So we've built an API and trained models that detects fixtures, extracts schedules, and analyzes construction documents. Check us out!
More examples: - https://www.getanchorgrid.com/developer/docs/endpoints/drawi...
Main website: - https://www.getanchorgrid.com/developer
Why we did it: https://www.getanchorgrid.com/developer/docs/changelog/const...
29 comments
[ 1.7 ms ] story [ 49.5 ms ] threadLove to give it to an arc client, not sure who the right person to implement this would be? Hmm…
I have to make a BOM and oh boy I hate my job
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=6m03s
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 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.
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.
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.
Anyway, cool product. Anything to help with estimation. Really hope it gets traction.
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.
Tailscale’s article about NAT traversal is an example of how to write “how we did it”: https://tailscale.com/blog/how-nat-traversal-works
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.
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.
Disclaimer: I'm a co-founder of Provision.
What is the maximum resolution you support for PDFs? The max gemini will do is 3072x3072. We have plans that are 10x that size.
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.
https://www.bluebeam.com/bluebeam-max/
Their first example is counting fixtures
The reality is people that work in construction (Excluding field work), refers to AI as a scam and compares it to the crypto hype back in 18 .. compares it to crypto in 2018 — all hype, no landing.. seriously they do not like it.
I built this selfishly. Eight months ago I wished I had a programmatic interface to interact with drawings. So I built one.
last point: our customers aren't just doing takeoffs and they aren't just subs or gc's either — they're building tools in the construction tech space and estimation is one use case. The broader opportunity is making all that structured data accessible.
great q!!
Also I didn't see Claude there "ai" tool (a bit weird they are letting the model providers own the entire interface) count any fixtures, and if it did it was probably pulling it from the markup's table which is enabled via their api, which you can technically just slap an llm on top of it. But hey kudos to them - this space is not easy. (https://developers.bluebeam.com/s/studio?language=en_US)