What you can learn from previous projects¶
As you browse, it helps to look specifically at:
Project scope — how broad or narrow the research question was, and whether that scope matched the time available.
Research question design — how a general interest was turned into a specific, answerable question.
Data choices — which sources were used, and why they were a reasonable fit.
Method choices — which techniques were applied, and how they connected back to the question.
Workflow structure — how the analysis moved from raw data to results.
Figures and maps — how results were communicated visually.
Repository documentation — how clearly the repository explains what it contains and how to run it.
Limitations — what the student identified as incomplete, uncertain, or out of scope.
None of these need to be perfect in any single project. Looking at how different students balanced them is more useful than looking for one ideal example.
Browse by year¶
Browse by theme¶
Once projects are added to the gallery, this section will group them by broad theme, such as:
urban analysis,
environmental monitoring,
remote sensing,
change detection,
segmentation,
foundation models,
public administration,
biodiversity or ecology.
Browse by method¶
Once projects are added to the gallery, this section will group them by the main method applied, following the method families covered in the course lessons:
data acquisition and preprocessing,
object detection,
semantic segmentation,
instance segmentation,
change detection,
regression,
foundation models,
satellite embeddings,
visualization.
How to read a project card¶
Project cards on the year pages use a consistent set of fields:
Question — the project’s core research question, stated in one or two sentences.
Data — the main data sources used.
Methods — the main techniques applied.
Repository — a link to the project’s public code repository, where the full implementation, data documentation, and outputs live.
Keywords — a short set of terms describing the project’s topic and methods, useful for browsing by theme or method above.
Limitations — where included, a brief, honest note on what the project does not cover or could not fully validate.
A card is intentionally short. It is meant to help you decide whether a project is relevant enough to open its repository, not to summarize the entire project on its own.
Responsible reuse¶
You are welcome to learn from previous projects’ repositories: how they are organized, how a specific method was implemented, how a notebook is documented. This is exactly what the gallery is for.
Do not copy project text, code, or structure without understanding it and adapting it to your own question. Beyond being an academic integrity concern, code copied without understanding tends to break in ways you cannot fix, and undermines the reproducibility your own project depends on. Use previous projects as a reference point for what is possible, not as a source to copy from directly.