Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

Turning this lesson into concrete progress on your SDS320 project

1. Motivation

This lesson introduced the training-data pipeline: inspecting imagery and annotations, converting vector labels to raster masks, generating chips, running batch workflows, checking quality and planning spatial splits.

For your own project, the goal is not necessarily to create a full training dataset immediately. The goal is to understand what training data your project would need, what is already available, and what needs careful checking before modelling.

After this page, you should be able to explain:

what the model should learn
→ what examples it needs
→ how labels are created or obtained
→ how quality will be checked
→ how data will be split and documented

2. Project checklist

Use this checklist for your project.

Task and label needs

Imagery and annotations

Tiling and pairing

Quality and splits


3. Decision points

What should the model learn?

A reasonable training-data plan begins with the target output. For example, a model might learn building pixels, tree crowns, water areas, crop classes or image-level scene labels.

If you cannot name the target output, the training-data plan is not ready.

What label format do I need?

Different tasks need different labels.

Project goalLikely label format
Classify whole image chipsFolder or table with one label per chip.
Detect objectsBounding boxes and class labels.
Segment pixelsRaster masks.
Separate objectsInstance masks or polygons.
Predict continuous valuesTarget raster or point measurements.

How will I create labels?

A reasonable label source may be an existing dataset, manual digitising, a public vector layer, a trusted raster product, field observations or a prompted foundation-model workflow.

Every label source needs a quality check.

What tile size and overlap make sense?

A reasonable tile contains the target feature and enough spatial context. Overlap is useful when objects are often cut by tile boundaries.

A tile setting is not reasonable if it creates huge numbers of files before you have inspected a small prototype.

How will I split the data?

A reasonable split tests whether the model generalises beyond the exact places it learned from. For spatial data, this usually means region-based, scene-based or buffered splits.


4. Common pitfalls


5. Mini deliverable

Produce a short Training Data Preparation Plan, plus a first small batch of tiles if your data is ready:

  1. A one-paragraph description of your imagery and annotation sources.

  2. Your chosen tile size, stride, and overlap ratio, with a one-sentence justification.

  3. Your chosen batch-pairing method, and why it fits your file naming.

  4. Your planned split strategy (region-, scene-, or buffer-based), including your target split ratio.

  5. If your data is ready: a small folder of generated tiles (even a few dozen), organized into train/, val/, and test/ subfolders, with a short note on what you saw when you visually checked a sample.

Keep this plan and this tile folder. You will build directly on them starting in the next task-specific lesson.


6. Reflection questions


7. Companion notebook

To revisit L04, download the training-data recap notebook. It combines imagery and annotation checks, mask creation, tiling, batch pairing and quality checks into one documented workflow, ending with a spatial split plan. Run it first with the prepared lesson data in your SDS320 Jupyter environment, then adapt the project-settings cell to one small area from your own project. Optional comparisons can remain disabled on your first run.