How to distinguish exterior wall outline lines from hatch, dimension, and view-crop lines in architectural elevation PDFs?

1

Hi everyone,

I’m building a construction plan takeoff pipeline for architectural drawings. I’m using Python and OpenCV to analyze architectural elevation PDFs that may be rasterized or converted to images.

The specific problem:

I can detect many lines from an exterior elevation, but the detected geometry includes different types of lines mixed together:

  • exterior wall outline / facade boundary lines
  • hatch or siding pattern lines
  • dimension extension lines
  • opening lines around windows and doors
  • view crop / title / annotation lines
  • roof/gable/context lines

I need a generic way to distinguish the main exterior wall/facade boundary from these other line types. I do not want to hardcode this for one specific PDF, sheet name, page number, address, or drawing style. The goal is to work across many architectural/construction drawing sets.

My current idea is to score line candidates using features such as:

  • line length
  • stroke width or apparent line weight
  • proximity to text/dimensions
  • whether the line is part of a connected contour
  • whether it forms a closed or nearly closed polygon
  • relationship to openings/windows/doors
  • orientation: horizontal/vertical/roof slope
  • repeated short parallel lines that may indicate hatch or siding
  • distance from view titles or dimension strings

Question:

For architectural elevation images, what OpenCV features or pipeline would you recommend to separate true exterior facade boundary lines from hatch lines, dimension lines, annotation lines, and opening lines?

Would you approach this with:

  1. morphological operations,
  2. connected components,
  3. contour hierarchy,
  4. Hough line detection,
  5. skeletonization,
  6. graph-based scoring,
  7. stroke width / line weight estimation,
  8. or a combination of these?

I’m especially interested in a robust, general approach rather than a one-off solution for a single drawing.

I can share a redacted cropped image and an overlay showing the detected lines if that helps.

Thank you!

2

How I would approach this? Not visually.

Whatever company made the program that made the PDF, tell them to embed the architectural source data into the PDF. Or work with the architectural source file itself. You should not scrape the data visually.

CV both is and isn’t magic. It’s “magic” (a marvel) to those who don’t know how it works. It’s “magic” (a “magic wand”) to those who are given it without having to engineer it. It’s not “magic” because it takes effort/engineering to make it work, and for many purposes it simply doesn’t work satisfactorily, whereas direct solutions do.

Mostly, it’s hard. And it should be a measure of last resort. Exhaust all other options. People often forget there are simpler solutions.

And don’t think you can just ask for a complete robust solution. That is what someone asks who’s looking to turn it into a product, make money from it.

If you’re set on “magic solutions”, you would need to hire someone who will train a neural network for the task.

1 Like
3

Thank you. This is a fair and helpful answer.

I agree with your point that visual scraping should not be the first choice if better source data is available. My intention is not to treat OpenCV as a magic wand or ask for a complete product-ready solution from the forum.

The practical issue I am trying to handle is that many residential construction users may only have PDFs, sometimes flattened/rasterized, and not the original CAD/BIM source. So I am trying to design the pipeline in the right order:

  1. Prefer source data when available: DWG/DXF/IFC/BIM/Revit exports, vector PDF data, schedules, layers, embedded metadata.
  2. Use PDF text/vector extraction where possible.
  3. Use CV only as a fallback/diagnostic layer when the PDF is flattened or incomplete.
  4. Do not treat CV results as final quantities unless there is defensible supporting evidence.

Your comment helps confirm that CV should be treated as a last-resort evidence tool, not as the primary source of truth.

A narrower question, then:

If CV is only used as a fallback to flag candidate exterior boundary lines for human review, not to produce final quantities automatically, would features like stroke width, connected components, contour hierarchy, text proximity, and repeated hatch-line detection be a reasonable starting point?

I understand this would not be fully robust across all drawings without significant engineering/training. I’m just trying to avoid the wrong approach early.

Thanks again for the honesty.

4

Hard to say. Those are very low-level features of such a diagram, and these diagrams are made for humans, who are very forgiving of inexact patterns. That is the major issue. If you approach this with “rules”, you’ll soon run into blueprints that violate the rules/assumptions. You will need some AI/ML model to learn how forgiving to be.

Example: the OpenCV logo itself. It’s derived from an optical illusion: It contains a triangle that “isn’t there”. It is negative space. You only see it from the gaps in the circles. The lines connecting the vertices are not there, they are broken. In the case of the OpenCV logo, even the vertices aren’t clearly there.

image
image2623×2436 230 KB
image
image1024×576 11.2 KB

some AI has a chance of seeing that, if trained for it, but nothing as simple as connected components or contour hierarchy will ever capture that.

Blueprints are mostly made of lines, faint lines, blurry lines, aliased and anti-aliased lines, curving lines, in different shades, perhaps dotted or dashed, perhaps broken by annotations, … humans shrug at that. Machines can’t.

By the way, I have a strong feeling that your reply was composed by some LLM. I’m stating that so that we don’t need to pretend differently.

What you’re asking is in the realm of OCR technology, but OCR is comparably easier. Recognition of document structure, table structure, recovery of the relationships…

It is also related to recovering the structure of charts, boxes-and-arrows diagrams, things of that kind. It might be manageable to get a demo to work, where you know the pitfalls and step around them without the audience noticing those pits nor that you avoid them intentionally, but going from easy cases to real-world cases is the hard part.

Some AI companies turned out to be a large bunch of humans pretending to be AI. In this situation, it might be cheaper to have some human with domain knowledge simply copy the diagram, compared to sinking significant development time into automating the process. Which side of this tradeoff is the better business decision depends on how often you have to do that to a diagram, how long it’s allowed to take, what quality the user expects, and what the user is willing to pay for the service.

5

Thank you. This is very helpful and I appreciate the honesty.

You are right that my English reply was helped by an LLM. Spanish is my first language, so I use it to make sure I communicate clearly and respectfully.

I understand your point now: simple OpenCV rules may work in controlled examples, but real architectural drawings require context and human-like interpretation. Broken lines, annotations, hatches, missing edges, and implied boundaries make this much harder than just detecting contours or connected components.

This helps me reframe the problem. I should not treat OpenCV as the main source of truth. A better workflow would be:

  • use CAD/BIM/DXF/IFC source data when available,
  • use PDF vector/text/schedule data when available,
  • use OCR/document-structure extraction where possible,
  • use CV only as a fallback to suggest candidate markups,
  • and keep human review when the evidence is not strong enough.

So I think the realistic goal is not fully automatic takeoff from any PDF, but human-assisted / evidence-based takeoff.

Thank you again. Your answer helps me avoid the wrong approach.