Case study 15 / 17Computer Vision ML
Checking equipment investments against 50,000+ legacy drawings
Turned 50,000+ legacy CNC drawings into evidence for a capital decision: most cutting tables were oversized for the work they do.
Stack
- Python 3.8+
- NumPy
- Pandas
- Matplotlib
- Streamlit
- LibreOffice CLI
- pikepdf
- Tesseract OCR
- +10
01 · How it works
- TodaytoChanged in this work
- Data flow
What it does
A data platform that tests a capital decision against history: do the laser cutting machines being bought match the parts actually being cut? It reads dimensions from more than 50,000 legacy CNC drawings, stores them for SQL analysis and clusters real production by size.
Read more
I architected it as Python services, with a document-processing pipeline, an extraction engine and an analysis layer for payback and utilisation.
5 connections· select a part to trace it
- Legacy vector drawings to PDF convert + cleanup: batch converted to PDF
- PDF convert + cleanup to OCR engine: clean pages, no masks
- OCR engine to Table pattern parser: raw text and tableschanged
- Table pattern parser to SQL database: dimensions per drawing
- SQL database to Clustering + payback: table size vs. real use
02Results
- R01Higher is better
OCR confidence score (0 to 1)
Before 0.6, after 0.84, +40%. Higher is better.BeforeAfter
What it achieved
- Investment evidence: 73 % of laser cutting tables over-specified, by 40–60 %
- Right-sizing: 80 % of production fits tables 30 % smaller, found by clustering real part sizes
- Extraction quality: dimensions read from 50,000+ drawings at 95.7 % accuracy
Read more
- Decision support: payback and utilisation analysis in SQL, with utilisation heat maps
- Operations: about 240 files an hour at 99.2 % uptime, with automatic recovery
The challenge
The evidence was locked in legacy vector drawings that were never meant to be read by a machine. Their transparency layers corrupted OCR, so I rewrote the PDF streams to strip the masks before extraction, which raised OCR confidence from 0.6 to 0.84.
Dimension tables came in 504 different header layouts, so a fixed parser was hopeless; I built hierarchical pattern matching with named captures and an edit-distance fallback, which reached 95.7 % classification accuracy.
Read more
At this volume the pipeline also had to run unattended and recover on its own, so it got concurrent processing, structured logs, metrics and automatic retries with backoff.
What I learned
The hard part of an analytics project is often getting trustworthy data out of documents nobody designed for analysis. Fix the input first: cleaning the PDF streams before OCR is what made extraction usable at all. For messy formats, a hierarchy of patterns with tolerant matching scales better than a growing list of special cases.
Read more
And a capital question needs an answer people can check: keeping the extracted dimensions in SQL lets the payback analysis be reproduced and challenged instead of taken on trust.
Stack
- Python 3.8+
- NumPy
- Pandas
- Matplotlib
- Streamlit
- LibreOffice CLI
- pikepdf
- Tesseract OCR
- RESTful APIs
- JSON Schema Validation
- PostgreSQL
- Docker
- Git
- pytest
- Regular Expressions
- Multiprocessing
- Logging
- Error Handling
Skills
- Data platform architecture
- Document AI and OCR
- Pattern-based extraction
- Clustering and payback analysis
- Resilient batch processing
