I use Notebook 1 to load the NUTS boundaries into a persistent DuckDB store and check the geometry before the rest of the project starts joining data to it.
That gives the weather, soil and yield notebooks the same district boundaries. I can then compare their coverage and results without wondering whether a different polygon assignment caused the change.
Technical lane: Data Ingestion Business lane: Product & DeliveryDecision relevance.
The district geometry stays consistent through coverage checks, feature engineering and risk scoring. You can trace those later results back to the same spatial base.
- Notebook role
- Foundational ingest and geospatial normalization
- Primary artifact
- DuckDB-backed NUTS region tables
- Granularity
- NUTS-0 to NUTS-3 hierarchy for later joins
NUTS-3 DuckDB Data Lake
Load NUTS 0-3 polygons, validate geometry ingest, and prepare spatial joins for all downstream notebooks.
Key output
The notebook loads the GISCO boundaries and creates a reusable nuts_regions table. Later
notebooks use it to assign points to districts and aggregate results by region.
You can use the same geometry to compare station coverage, weather features and final risk scores. Keeping that reference fixed helps avoid comparisons made on subtly different maps.
| Layer | What is stored | Why it matters |
|---|---|---|
| Spatial boundaries | NUTS polygons from level 0 to 3 | Keeps all later joins on one official administrative hierarchy |
| Reference keys | Region IDs and hierarchy links | Enables deterministic aggregation and roll-up checks |
| Geometry validation flags | Basic geometry sanity checks | Prevents silent failures in downstream point-in-polygon operations |
Using the district tables
With those tables ready, I can check where station coverage is thin and whether yield records join to the right districts. The same boundaries also let me test how soil and weather features change when I aggregate them to district level.
Open notebook source