Floor plan vectorisation: a raster image into structured walls and openings

TL;DR. Floor plans usually exist as a picture: a scan, a JPEG, a page of a PDF. A PyTorch segmentation model trained on the CubiCasa5k dataset turns that image into structured vector data — wall and opening polygons that a CRM or an interior design service can actually use. The code is open.

Situation: the floor plan exists only as a picture

In interior design services, developers' CRMs and property record systems, a layout is usually stored as an image. You can show a picture to a person, but you can't compute with it: measure area per room, place objects, or compare two layouts against each other.

Converting a plan into vector form is done by hand, tracing it in a graphics editor. That doesn't scale to any real volume.

Task

1. Accept a raster image of a plan — a scan or a PDF export.
2. Identify the structural elements: walls and openings.
3. Return the result as structured data, not another picture.
4. Build a reproducible pipeline: dataset preparation, training, inference, tests.

What we built

The pipeline has three parts.

Data preparation. The CubiCasa5k dataset is annotated in COCO format. Scripts convert those annotations into segmentation masks suitable for training and assemble the splits.

The model. A PyTorch segmentation network learns to separate walls and openings from everything else on the plan — dimension lines, labels, furniture, hatching.

Vectorisation. The predicted mask is converted into polygons: wall and opening contours are extracted and simplified into a vector representation that can be passed on — into an interior editor, or into a property record.

The project is covered by tests, and the source is published at github.com/pimenoffd.

Result

• A working tool: an image of a plan goes in, structured wall and opening polygons come out.
• A reproducible pipeline, from annotation conversion through to inference.
• Test coverage with pytest.
• Open source: the implementation can be read before any conversation about a task.

Key technical decisions

1. Segmentation rather than rectangle detection. A wall on a plan isn't always a rectangle — curved and angled sections turn up regularly. A pixel mask describes that geometry; a bounding box doesn't.
2. COCO annotation conversion as its own step. Data preparation lives in standalone scripts rather than hidden inside training. The dataset can be rebuilt without rewriting the training code.
3. Vectorisation as a separate stage after inference. The model is responsible for the mask; contour simplification into polygons is geometry. The simplification threshold changes without retraining the model.

FAQ

Why open-source a project like this?

An open repository with tests answers a question a case study description can't: how this person writes code. Client projects can't be shown line by line; a pet project can.

Does the model work on low-quality scans?

Source quality matters directly: the model was trained on CubiCasa5k, and the closer the input is to that dataset's character, the more stable the result. For a specific document stream, the model gets fine-tuned.

Can I use this in my own service?

The code is open and available on GitHub. Fitting it to a specific service — integration, fine-tuning on your own layouts, output in the format you need — takes additional work.

What would come next

The natural continuation is recognising rooms as closed regions with area calculation, extracting labels and dimension lines, and exporting to interior editor formats.

If you have a stream of layouts as images and you need data out of them, let's talk it through in 30 minutes.