Andrés C. Zúñiga-González https://ancazugo.github.io/blog.html PhD Student @ University of Cambridge en quarto-1.10.1 Sun, 05 Apr 2026 00:00:00 GMT Weekly Notes - 2026-04-05 Andrés C. Zúñiga-González https://ancazugo.github.io/posts/2026-04-05-weekly-notes.html

Introduction

This is a short update on the Local Climate Zones (LCZs) classification project. It’s a collection of notes and experiments I did last week particularly about using label propagation and other sources of information to increase the number of labels and/or features, namely using OpenStreetMap (OSM) data for labels (with osm-rasterizer), height data for buildings and a canopy height model (CHM) and label propagation to increase the number of labels.

Label Propagation

So the label propagation has a few constraints. If done at the pixel level, it misses the context behind the patch labels, as these were done considering the entire scene. One road pixel can be any built type depending on what’s around. So I built a label propagation at the pixel label using the following steps:

  • Aggregate embeddings (mean, std, max) per patch
  • Generate 320x320 m grid and use Knn on the entire ROI
  • Filter out <.8 confidence patch pseudo-labels

This approach effectively increments the number of possible patches to use in a classifier, but it presents one key problem: None of the cities have all possible classes, so for instance, Nairobi doesn’t have classes 4-5 in the labels even though they might be present there. Low representation also plays a role, as water has few labels and no pseudolabels.

Probably the best approach would be to do label propagation in multicity instances. At the moment, I’m trying to use Paris due to its size and varied LCZ classes, so I could combine the Knn results of the label propagation with those of Nairobi.

Including other features

OSM data, at least for Nairobi is insufficient to get good labels for built types, because of lack of height information. For natural types it’s better, but quality is bad when going back in time, for instance, artificial lakes that were present in 2017 were not in OSM at the time. So the key here is to grab as many useful OSM tags as possible, including those that are currently deprecated as they might include useful information in the past (see previous tags for the Ngong river in Nairobi). Claude was very helpful in this regard. I think OSM information is useful for natural types, and so far I’ve used the water class (G class in LCZs) because water bodies have a distinct spectral signature and there aren’t many water patches for Nairobi in the So2Sat dataset.

I tried creating some manual labels for built types, but it is very difficult since many of those classes overlap in some way, as pointed by most research papers. With that said, I thought it would be a good oportunity to add some other features to the embeddings, in particular height data from trees and buildings. The reason behind this is that built-up density should get picked up by the embeddings and the CNNs, because it’s information related to the spatial distribution of the features (plus their spectral signatures). However, Tessera doesn’t have height data, which I believe is the reason why in most tests AlphaEarth performs better, as it was trained with DSM and DTM layers as well as Sentinel images. So, I’m testing adding the Meta’s Global Canopy Height Model (CHM) and Google’s Temporal Open Buildings dataset as features in the model. There are a few things to keep in mind about including these:

  • Resolution (GEE does the re-sampling to 10 m resolution)
  • AI predicted on AI-generated data: Both datasets are AI-generated, so not using the best available human-labelled data might be a problem.

Model architecture

With the small literature review I did the previous week, most, if not all, papers that use the SO2Sat labels, treat the problem as a classification task. Aside from initial experiments, I’ve mostly treated this as a segmentation task, assuming that all pixels in a patch belong to the same class. In realit, it depends a lot on the context, even outside a given patch.

This makes me re-evaluate the best way forward in terms of the model architecture, especially because most literature that I would use to benchmark my results talks about classification of the patches.

Going back to the label propagation, what I did was to create a grid of 320x320 m tiles and aggregate the embeddings (mean, std, max) per patch, and select those that have a significant score, and then feed them to the U-net with the original labels. So, in a way the label propagation is not done at the pixel level, which I think is the right approach. I will come back next week with updated results on these experiments.

Label Propagation using KNN in Nairobi and Tessera 2017
Back to top ]]> phd https://ancazugo.github.io/posts/2026-04-05-weekly-notes.html Sun, 05 Apr 2026 00:00:00 GMT OSM Rasterizer Andrés C. Zúñiga-González https://ancazugo.github.io/posts/2026-03-31-osm-rasterizer.html Hello!! I want to introduce you to osm-rasterizer, a package that I’ve been meaning to publish for a while now (available here). It’s sole purpose is to take features from OpenStreetMap (OSM) and rasterize them into a tif file with a given resolution. This is useful if you want to use OSM data as labels for machine learning models.

The way it works is by creating layers of features that the user can choose from using the OSM tags. osm-rasterizer will query said tags for a specific bounding box and burn the features into an image. The user can decide whether all those features are one hot encoded or not, depending on preferences.

Most importantly, osm-rasterizer uses Overpass API to query OSM data by date, so the user can specify a point in time from which the data is to be queried. This is a useful feature if you want features from different time periods.

CLI Usage

This is an example of extracting water and forest features in a single layer in Nairobi, Kenya as a case study, if you add the --date flag, you will get the data for that particular date. The resulting image is in the projected UTM CRS for the bounding box.

osm-rasterizer 
    --bbox "36.55363766400003,-1.442601803999969,37.06313313600007,-1.0646565169999689" \
    --feature 'water:{"natural": "water", "waterway": true, "landuse": "reservoir"}' \
    --feature 'forest:{"natural": "wood", "landuse": "forest"}' \
    --resolution 10 \
    --single-layer \
    # --date "2017-12-31" \
    --output nairobi_output.tif

Nairobi OSM Labels 2017

Nairobi OSM Labels 2026

The package is still in development so if you find it useful or have any suggestions, please let me know!

Back to top ]]> python osm https://ancazugo.github.io/posts/2026-03-31-osm-rasterizer.html Tue, 31 Mar 2026 00:00:00 GMT Weekly Notes - 2026-03-29 Andrés C. Zúñiga-González https://ancazugo.github.io/posts/2026-03-29-weekly-notes.html

Introduction

This is mostly an update on the literature review I’ve been doing for the LCZ classification project I’ve been working on plus an initial update from the Anglesey project in Architecture.

LCZ Classification

I want to summarize what I’ve read so far about LCZ classification papers. So, LCZ classes were established in 2012 by Stewart and Oke and they have been used largely by the urban climate community ever since. The methods to create LCZ for a given city vary widely depending on available data (Huang, 2023). There are three main types of methods: 1. Remote sensing-based methods 2. GIS-based methods 3. Hybrid methods

Each one of this has their own advantages. For instance, RS models can be extrapolated to many areas due to the availability of data but not all sensors have the same resolution so that might hinder definition of classes. GIS methods can enjoy from greater resolution but rely on the quality of local data, like building footprints and height. Hybrid methods are a combination of both but are not that common in the literature.

Among RS-methods, which is what I’m working on at the moment, there are three main approaches: 1. Pixel-based methods 2. Scene-based methods 3. Patch-based methods

The most common approach is the pixel-based ones, particularly using Landsat data, because of two main reason: thermal information and resolution. Scene-based are considered object-based approaches and patch-based are like image classification problems where an entire patch is classified as a single class.

Now, the standard LCZ unit is a big topic of discussion in the literature as it depends largely on the type of method and data used for that. The standard size in most papers to define a LCZ is 100x100 m, particularly in RS-based papers, but 300x300 m is also common. However, in GIS-based papers, census units or neighbourhoods are used as well.

Most literature about LCZ classification using RS datasets uses a combination of Sentinel-1 and 2 and Landsat data. This is in part because the only available dataset with global coverage is the So2Sat LCZ42 dataset for ML purposes. All papers that use this dataset could be considered in the patch-based approach. Howver, I found there are a couple of large-scale benchmark datasets for China and South Korea.

In general, the papers that I’ve encountered had a good discrimination between built (1-10) and natural classes (A-G) but models seem to struggle when identifying similar classes, particularly those that depend on height and density of buildings. One paper that caught my attention, on top of doing a general model for the 17 classes, created a separate model for classes 6 and 9 and for classes C and D (Liu, 2025).

Crucially, the only global LCZ dataset is the Demuzere 2022 one that I’ve referenced in the past. They use 46 different bands from various sources to classify the 17 classes. These include: Landsat 8, Sentinel-1 and 2, PALSAR, VIIRS, + DEM (from MERIT), DSM (ALOS) and a global canopy height model. They also argue that using anthropogenic heat flux is key to determining built classes. To determine the labels they use a curated list of labels from WUDAPT.

Of importance from these papers is why LCZs are so important: even though they were created using cities in Europe in mind, they have extended globally and the community has proven their usefulness in spite of regional climatic context. Moreover, these LCZ classes are used as a base for urban weather simulations as Urban Canopy Parameters (UCP), so getting a higher resolution (well, not higher but more precise) would improve local climate models. In addition, in Liu, et al. (2025) they demonstrated that LCZ classification is of great significance for studying the cooling effect of green infrastructure and the impact on the microclimate around towns.

Deep learning based methods

Following discussions with Anil and Sadiq, I was advised to use semi supervised methods to train the classifier, so I’ve been reading the blog posts from Lilian Weng about implementations and theory behind them. Sadiq suggested label propagation is probably the way to go, so after reading that I wanted to see if there were papers using similar approaches and this is what I found as part of the literature review.

While the Demuzere, 2022 dataset uses random forest, most recent literature uses a mix of CNNs and Transformers. I will talk mostly about papers that use the So2Sat LCZ42 dataset.

  • Lin, et al. (2024) uses transformers and semi-supervised learning. The way they do it is via a teacher model that will create the pseudo labels that the student will use alongside the real labels to get a better model. They benchmarked the model against the So2Sat LCZ42 as well as the CHN15-LCZ and SouthKorea6-LCZ datasets. They mention that the patch labels are crucial for training and thye think it’s better if images are larger than the 320x320 m size of the So2Sat LCZ42 dataset, which they note is noisy because the were labeled by experts using an entire Sentinel-1 and 2 scene, not just the patch, so contextual information is important for determining the labels. They mention that classes whose difference is height are hard to classify. Receptive field is something to be considered in my models.

  • Liu, et al. (2025) uses a standalone CNN-based architecture. I found this very clear on their approach. It’s interesting to see that they used and Overall accuracy for built and natural types separately, compared to the rest that use a general one. They used a Milan dataset to test the model but that raises the question of the different methodologies to determine an LCZ, using a different dataset might result in class mismatch just because of the different methodology, which is not an error in the model. As mentioned before, they use separate models for classes 6 and 9 and for classes C and D.

  • Nanni, et al. (2025) uses a combination of CNN architectures including ResNet50 (RN), MobileNetV2 (MN), and DenseNet201 (DN). I found this paper a bit confusing because they used pretrained models and did a randomized selection of Sentinel 1 and 2 bands to train the 3-channel architectures. I feel like you will lose a lot of information that way. They mentioned something that I missed from the So2Sat paper, agreement between human labelers is 85% which shows how difficult it is even to experts to agree on the labels.They sued an ensemble of those models and their results seem to outperform other models.

  • Nawaz, et al. (2025) uses self-supervised learning in an attention-based model. They used only Sentinel-1 and 2 data in a three branch model. They say that in this particular problem using negative samples is not ideal because there is a big overlap between classes so what they do is use few positive samples and train the model on them and the finetuning using the So2Sat dataset. I’m still not sure how they avoid data leakage in this process, but I will need to review the methods in more detail.

Other stuff

Related to the LCZ project, I was admitted to the urban climate summer school in Bochum, Germany in September. This is a great chance to meet people who are working on similar problems and showcase my work. Hopefully I will have something more tangible by then.

I started working on the Anglesey fens project where they want to evaluate vegetation health of the fenlands using remote sensing and drone imagery. I started by gathering all information available in open platforms and created a data source. Using the code I’ve developed for accessing GEE data in Python and using them as xarrays, I’ve developed pilot evaluations of NDVI around the fenlands. There are aerial images from 2013, 2015, 2018 and 2021 but unfortunately they don’t include Infrared bands, so no NDVI can be calculated. What I’m gonna work on now using CLAUDE is to convert the 3-30-300 project into a package that can be used for a smaller region using similar datasets (buildings, trees, parks and roads). For this purpose, I need to create the Vegetation Object Model (VOM) from scratch using the DSM and DTM from Wales, as Defra’s dataset only covers England (thus the reason why I only worked in English counties in the 3-30-300 paper).

Back to top ]]> phd https://ancazugo.github.io/posts/2026-03-29-weekly-notes.html Sun, 29 Mar 2026 00:00:00 GMT 2026-03-15 U-net example with Tessera and Torchgeo Andrés C. Zúñiga-González https://ancazugo.github.io/posts/2026-03-15-weekly-notes.html
Code 
%load_ext autoreload
%autoreload 2
import sys
sys.path.append('../src')

This notebook presents a minimal example of how to create a deep learning model for classification of LCZ classes using Tessera embeddings and a couple of labels for Nairobi. It uses Torchgeo to handle dataloaders and Sadiq’s U-net architecture for solar farm detection with a couple of tweaks on the loss because most of the ROI is not labeled.

Code 
import glob
import warnings
warnings.filterwarnings('ignore')

import numpy as np
import geopandas as gpd
import rasterio
import rasterio.windows
from rasterio.merge import merge
from shapely.geometry import box as shapely_box

import torch
import torch.nn as nn
import torch.optim as optim
from torch.utils.data import Dataset, DataLoader
import matplotlib.pyplot as plt

from train_unet import UNet, MulticlassDiceLoss

1. Configuration

Code 
TIF_DIR    = '/maps/acz25/phd-thesis-data/input/Embeddings_test/GeoTessera/2017/'
LABEL_PATH = '/maps/acz25/phd-thesis-data/input/So2Sat-LCZ42/v4/patches_reference_Nairobi.gpkg'
LABEL_COL  = 'LCZ_class'

IN_CHANNELS = 128
NUM_CLASSES = 17
PATCH_SIZE  = 32    # pixels (320 m at 10 m/px)
BATCH_SIZE  = 16
EPOCHS      = 5
DICE_WEIGHT = 0.5

DEVICE = torch.device('cuda' if torch.cuda.is_available() else 'cpu')
print('device:', DEVICE)
device: cuda
Code 
from matplotlib.colors import ListedColormap, BoundaryNorm
from matplotlib.patches import Patch

lcz_dict = {
    1:  {"name": "Compact High-Rise",    "alt_code": "1",  "color": "#8c0000"},
    2:  {"name": "Compact Mid-Rise",     "alt_code": "2",  "color": "#d10000"},
    3:  {"name": "Compact Low-Rise",     "alt_code": "3",  "color": "#ff0000"},
    4:  {"name": "Open High-Rise",       "alt_code": "4",  "color": "#bf4d00"},
    5:  {"name": "Open Mid-Rise",        "alt_code": "5",  "color": "#ff6600"},
    6:  {"name": "Open Low-Rise",        "alt_code": "6",  "color": "#ff9955"},
    7:  {"name": "Lightweight Low-Rise", "alt_code": "7",  "color": "#faee05"},
    8:  {"name": "Large Low-Rise",       "alt_code": "8",  "color": "#bcbcbc"},
    9:  {"name": "Sparsely Built",       "alt_code": "9",  "color": "#ffccaa"},
    10: {"name": "Heavy Industry",       "alt_code": "10", "color": "#555555"},
    11: {"name": "Dense Trees",          "alt_code": "A",  "color": "#006a00"},
    12: {"name": "Scattered Trees",      "alt_code": "B",  "color": "#00aa00"},
    13: {"name": "Bush, Scrub",          "alt_code": "C",  "color": "#648525"},
    14: {"name": "Low Plants",           "alt_code": "D",  "color": "#b9db79"},
    15: {"name": "Bare Rock or Paved",   "alt_code": "E",  "color": "#000000"},
    16: {"name": "Bare Soil or Sand",    "alt_code": "F",  "color": "#fbf7ae"},
    17: {"name": "Water",               "alt_code": "G",  "color": "#6a6aff"},
}

# Colormap: index 0 = LCZ 1, ..., index 16 = LCZ 17
lcz_colors = [lcz_dict[c]['color'] for c in range(1, 18)]
lcz_cmap   = ListedColormap(lcz_colors, name='lcz')
lcz_norm   = BoundaryNorm(boundaries=np.arange(-0.5, 17.5, 1), ncolors=17)

def lcz_legend_handles():
    return [
        Patch(facecolor=lcz_dict[c]['color'],
              label=f"LCZ {lcz_dict[c]['alt_code']}: {lcz_dict[c]['name']}")
        for c in range(1, 18)
    ]

2. Build TIF Spatial Index

Read every TIF’s bounding box into a GeoDataFrame.
This lets us quickly look up which tiles cover any given polygon.

Code 
tif_paths = sorted(glob.glob(TIF_DIR + '*.tif'))
print(f'{len(tif_paths)} TIF tiles')

# Read CRS from the first tile
with rasterio.open(tif_paths[0]) as src:
    TIF_CRS = src.crs
    print('CRS:', TIF_CRS)
    print('resolution:', src.res)
    print('bands:', src.count)

records = []
for p in tif_paths:
    with rasterio.open(p) as src:
        records.append({'path': p, 'geometry': shapely_box(*src.bounds)})

tif_index = gpd.GeoDataFrame(records, crs=TIF_CRS)
tif_index.plot(figsize=(6, 6), edgecolor='steelblue', facecolor='none')
plt.title('TIF tile coverage')
plt.show()
56 TIF tiles
CRS: EPSG:32737
resolution: (10.0, 10.0)
bands: 128

3. Load Labels

So2Sat patches are 320 m × 320 m polygons (32 px at 10 m/px), each with a single LCZ class.
The polygons overlap — adjacent patches share boundary pixels.
We handle this by treating each polygon as an independent training sample,
so overlaps never appear within a single patch.

Code 
gdf_wgs84 = gpd.read_file(LABEL_PATH)
gdf = gdf_wgs84.to_crs(TIF_CRS)
print(f'Polygons: {len(gdf)}  |  CRS: {gdf.crs}')
print(f'LCZ range: {gdf[LABEL_COL].min()} - {gdf[LABEL_COL].max()}')

fig, axes = plt.subplots(1, 2, figsize=(14, 5))

# Map: colour each polygon by its exact LCZ hex colour
gdf.plot(color=gdf[LABEL_COL].map(lambda c: lcz_dict[c]['color']), ax=axes[0], alpha=0.9)
axes[0].set_title('So2Sat LCZ patches (Nairobi)')
axes[0].set_xlabel('Easting (m)')
axes[0].set_ylabel('Northing (m)')

# Bar chart: one bar per class, coloured with LCZ palette
counts = gdf[LABEL_COL].value_counts().sort_index()
bar_colors = [lcz_dict[c]['color'] for c in counts.index]
counts.plot.bar(ax=axes[1], color=bar_colors, edgecolor='grey', linewidth=0.4)
axes[1].set_title('Class distribution')
axes[1].set_xlabel('LCZ class')
axes[1].set_ylabel('Count')
axes[1].set_xticklabels(
    [f"{c}\n{lcz_dict[c]['alt_code']}" for c in counts.index], rotation=0
)

# Shared legend
fig.legend(handles=lcz_legend_handles(), fontsize=9, ncol=6,
           loc='lower center', bbox_to_anchor=(0.5, -0.12), framealpha=0.8)

plt.tight_layout()
plt.show()
Polygons: 4828  |  CRS: PROJCS["WGS 84 / UTM zone 37S",GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4326"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",39],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",10000000],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["EPSG","32737"]]
LCZ range: 1 - 17

4. Polygon Patch Dataset

Each item in the dataset is one So2Sat polygon: - image: (128, 32, 32) Tessera embedding cropped to the polygon bounds
- mask: (32, 32) filled with the polygon’s LCZ class (0-indexed)

When a polygon crosses multiple TIF tiles, rasterio.merge mosaics them first.
Overlapping polygons are not a problem — each is an independent sample.

Code 
class PolygonPatchDataset(Dataset):
    """One sample per So2Sat polygon: (128, 32, 32) embedding + (32, 32) class mask."""

    def __init__(self, gdf, tif_index, label_col, patch_size=32):
        self.gdf = gdf.reset_index(drop=True)
        self.tif_index = tif_index
        self.label_col = label_col
        self.patch_size = patch_size

    def __len__(self):
        return len(self.gdf)

    def __getitem__(self, idx):
        row = self.gdf.iloc[idx]
        bounds = row.geometry.bounds          # (minx, miny, maxx, maxy)
        label = int(row[self.label_col]) - 1  # 1-based -> 0-based

        covering = self.tif_index[self.tif_index.intersects(row.geometry)]
        import rasterio
        if covering.empty:
            image = torch.zeros(IN_CHANNELS, self.patch_size, self.patch_size)
        elif len(covering) == 1:
            
            with rasterio.open(covering.iloc[0]['path']) as src:
                win = rasterio.windows.from_bounds(*bounds, transform=src.transform)
                data = src.read(window=win, out_shape=(src.count, self.patch_size, self.patch_size),
                                resampling=rasterio.enums.Resampling.bilinear,
                                boundless=True, fill_value=0.0)
            image = torch.from_numpy(data.astype(np.float32))
        else:
            # Polygon spans multiple tiles — mosaic them first
            srcs = [rasterio.open(p) for p in covering['path']]
            mosaic, mosaic_transform = merge(srcs, bounds=bounds)
            for s in srcs:
                s.close()
            # Resize mosaic to fixed patch_size
            from rasterio.transform import from_bounds as tfm_from_bounds
            import rasterio.warp
            out = np.zeros((mosaic.shape[0], self.patch_size, self.patch_size), dtype=np.float32)
            dst_transform = tfm_from_bounds(*bounds, self.patch_size, self.patch_size)
            for b in range(mosaic.shape[0]):
                rasterio.warp.reproject(
                    source=mosaic[b].astype(np.float32),
                    destination=out[b],
                    src_transform=mosaic_transform,
                    src_crs=TIF_CRS,
                    dst_transform=dst_transform,
                    dst_crs=TIF_CRS,
                    resampling=rasterio.enums.Resampling.bilinear,
                )
            image = torch.from_numpy(out)

        mask = torch.full((self.patch_size, self.patch_size), label, dtype=torch.long)
        return image, mask

5. Train / Val Split

Code 
rng = np.random.default_rng(42)
perm = rng.permutation(len(gdf))
n_train = int(0.8 * len(gdf))

train_gdf = gdf.iloc[perm[:n_train]]
val_gdf   = gdf.iloc[perm[n_train:]]

train_ds = PolygonPatchDataset(train_gdf, tif_index, LABEL_COL, PATCH_SIZE)
val_ds   = PolygonPatchDataset(val_gdf,   tif_index, LABEL_COL, PATCH_SIZE)

train_loader = DataLoader(train_ds, batch_size=BATCH_SIZE, shuffle=True,  num_workers=4)
val_loader   = DataLoader(val_ds,   batch_size=BATCH_SIZE, shuffle=False, num_workers=4)

print(f'Train: {len(train_ds)}  |  Val: {len(val_ds)}')

# Sanity check
img, mask = train_ds[0]
print(f'image: {img.shape} {img.dtype}  |  mask: {mask.shape} {mask.dtype}  |  label: {mask[0,0].item()}')
Train: 3862  |  Val: 966
image: torch.Size([128, 32, 32]) torch.float32  |  mask: torch.Size([32, 32]) torch.int64  |  label: 6

Visualise a batch

Code 
images, masks = next(iter(train_loader))
n_show = 4
fig, axes = plt.subplots(n_show, 2, figsize=(6, 3 * n_show))
for i in range(n_show):
    img = images[i, :3].permute(1, 2, 0).numpy()
    img = (img - img.min()) / (img.max() - img.min() + 1e-8)
    cls = masks[i, 0, 0].item() + 1  # 0-indexed -> 1-indexed
    axes[i, 0].imshow(img)
    axes[i, 0].set_title('Tessera bands 0-2')
    axes[i, 0].axis('off')
    axes[i, 1].imshow(masks[i].numpy(), cmap=lcz_cmap, norm=lcz_norm)
    axes[i, 1].set_title(f'LCZ {cls}: {lcz_dict[cls]["name"]}')
    axes[i, 1].axis('off')
plt.tight_layout()
plt.show()

6. UNet Model

Using the UNet from train_unet.py with the small preset (depth=3, base=32).
Available: nano (2,8), small (3,32), base (3,48), medium (4,32), large (4,48).

Code 
PRESET = 'small'
depth, base_features = UNet.PRESETS[PRESET]

model = UNet(
    in_channels=IN_CHANNELS,
    num_classes=NUM_CLASSES,
    depth=depth,
    base_features=base_features,
    bottleneck_dropout=0.3,
).to(DEVICE)

print(f'Preset: {PRESET}  (depth={depth}, base={base_features})')
print(f'Parameters: {sum(p.numel() for p in model.parameters()):,}')
Preset: small  (depth=3, base=32)
Parameters: 1,963,537

7. Training Loop

Loss: (1 − dice_weight) × CrossEntropy + dice_weight × MulticlassDice
MulticlassDiceLoss is macro-averaged over present classes, ignoring ignore_index=-1.

Code 
ce_loss   = nn.CrossEntropyLoss()
dice_loss = MulticlassDiceLoss(NUM_CLASSES)
optimizer = optim.Adam(model.parameters(), lr=1e-3, weight_decay=1e-4)
scheduler = optim.lr_scheduler.CosineAnnealingLR(optimizer, T_max=EPOCHS)

def combined_loss(logits, masks):
    ce   = ce_loss(logits, masks)
    dice = dice_loss(logits, masks)
    return (1.0 - DICE_WEIGHT) * ce + DICE_WEIGHT * dice, ce, dice

for epoch in range(1, EPOCHS + 1):
    # --- train ---
    model.train()
    t_loss = t_ce = t_dice = 0.0
    for images, masks in train_loader:
        images, masks = images.to(DEVICE), masks.to(DEVICE)
        optimizer.zero_grad()
        loss, ce, dice = combined_loss(model(images), masks)
        loss.backward()
        optimizer.step()
        t_loss += loss.item(); t_ce += ce.item(); t_dice += dice.item()
    n = len(train_loader)
    t_loss /= n; t_ce /= n; t_dice /= n
    scheduler.step()

    # --- val ---
    model.eval()
    v_loss = v_ce = v_dice = 0.0
    correct = total = 0
    with torch.no_grad():
        for images, masks in val_loader:
            images, masks = images.to(DEVICE), masks.to(DEVICE)
            logits = model(images)
            loss, ce, dice = combined_loss(logits, masks)
            v_loss += loss.item(); v_ce += ce.item(); v_dice += dice.item()
            preds = logits.argmax(dim=1)
            correct += (preds == masks).sum().item()
            total   += masks.numel()
    m = len(val_loader)
    v_loss /= m; v_ce /= m; v_dice /= m

    print(
        f'Epoch {epoch:02d}/{EPOCHS}'
        f'  train={t_loss:.4f} (ce={t_ce:.4f} dice={t_dice:.4f})'
        f'  val={v_loss:.4f} (ce={v_ce:.4f} dice={v_dice:.4f})'
        f'  val_acc={correct/total:.4f}'
    )
Epoch 01/5  train=0.8171 (ce=1.1119 dice=0.5223)  val=0.4026 (ce=0.5040 dice=0.3013)  val_acc=0.8433
Epoch 02/5  train=0.4562 (ce=0.6010 dice=0.3114)  val=0.3021 (ce=0.3795 dice=0.2247)  val_acc=0.8929
Epoch 03/5  train=0.3594 (ce=0.4779 dice=0.2409)  val=0.2186 (ce=0.2721 dice=0.1650)  val_acc=0.9143
Epoch 04/5  train=0.2891 (ce=0.3783 dice=0.1999)  val=0.1821 (ce=0.2249 dice=0.1394)  val_acc=0.9303
Epoch 05/5  train=0.2536 (ce=0.3308 dice=0.1763)  val=0.1641 (ce=0.2019 dice=0.1264)  val_acc=0.9421

8. Visualise Predictions

Code 
model.eval()
images, masks = next(iter(val_loader))
with torch.no_grad():
    preds = model(images.to(DEVICE)).argmax(dim=1).cpu()

n_show = 4
fig, axes = plt.subplots(n_show, 3, figsize=(9, 3 * n_show))
for i in range(n_show):
    img = images[i, :3].permute(1, 2, 0).numpy()
    img = (img - img.min()) / (img.max() - img.min() + 1e-8)
    gt_cls   = masks[i, 0, 0].item() + 1
    pred_cls = preds[i].flatten().mode().values.item() + 1
    axes[i, 0].imshow(img)
    axes[i, 0].set_title('Bands 0-2')
    axes[i, 0].axis('off')
    axes[i, 1].imshow(masks[i].numpy(), cmap=lcz_cmap, norm=lcz_norm)
    axes[i, 1].set_title(f'GT: LCZ {gt_cls} ({lcz_dict[gt_cls]["alt_code"]})')
    axes[i, 1].axis('off')
    axes[i, 2].imshow(preds[i].numpy(), cmap=lcz_cmap, norm=lcz_norm)
    axes[i, 2].set_title(f'Pred: LCZ {pred_cls} ({lcz_dict[pred_cls]["alt_code"]})')
    axes[i, 2].axis('off')
plt.tight_layout()
plt.show()

9. Full-ROI Prediction with torchgeo

Use torchgeo’s RasterDataset + GridGeoSampler to tile the entire label area,
run inference on each patch, then mosaic the results into a single prediction map.

Code 
from torchgeo.datasets import RasterDataset
from torchgeo.samplers import GridGeoSampler, Units
from torchgeo.datasets.utils import stack_samples

class TesseraDataset(RasterDataset):
    filename_glob = '*.tif'

tessera_ds = TesseraDataset(paths=TIF_DIR)
print(f'Tiles: {len(tessera_ds.index)}  CRS: {tessera_ds.crs}  res: {tessera_ds.res}')

# Restrict inference to the So2Sat label area
roi_minx, roi_miny, roi_maxx, roi_maxy = gdf.total_bounds
roi = shapely_box(roi_minx, roi_miny, roi_maxx, roi_maxy)

pred_sampler = GridGeoSampler(
    tessera_ds, size=PATCH_SIZE, stride=PATCH_SIZE, roi=roi, units=Units.PIXELS
)
print(f'Inference patches: {len(pred_sampler)}')
Tiles: 56  CRS: PROJCS["WGS 84 / UTM zone 37S",GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4326"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",39],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",10000000],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["EPSG","32737"]]  res: (10.0, 10.0)
Inference patches: 8008
Code 
def pred_collate(batch):
    # stack_samples handles stacking tensor fields; 'bounds' is a (9,) tensor per sample
    # -> stacked to (N, 9): [minx, maxx, xstep, miny, maxy, ystep, tmin, tmax, tstep]
    return stack_samples(batch)

pred_loader = DataLoader(
    tessera_ds, batch_size=BATCH_SIZE, sampler=pred_sampler,
    num_workers=4, collate_fn=pred_collate,
)

# Run inference, collect (pred_patch, minx, miny, maxx, maxy) per patch
model.eval()
patch_results = []  # list of (H, W) arrays with their spatial bbox
res = tessera_ds.res[0]  # scalar pixel size in CRS units

with torch.no_grad():
    for batch in pred_loader:
        logits = model(batch['image'].float().to(DEVICE))
        preds  = logits.argmax(dim=1).cpu().numpy()  # (N, H, W)
        bounds = batch['bounds']                     # (N, 9) tensor
        for i in range(preds.shape[0]):
            minx = float(bounds[i, 0])
            maxx = float(bounds[i, 1])
            miny = float(bounds[i, 3])
            maxy = float(bounds[i, 4])
            patch_results.append((preds[i], minx, miny, maxx, maxy))

print(f'Collected {len(patch_results)} patches')
Collected 8008 patches
Code 
# Assemble patches into a full raster
all_minx = min(p[1] for p in patch_results)
all_miny = min(p[2] for p in patch_results)
all_maxx = max(p[3] for p in patch_results)
all_maxy = max(p[4] for p in patch_results)

out_w = int(round((all_maxx - all_minx) / res))
out_h = int(round((all_maxy - all_miny) / res))
raster = np.full((out_h, out_w), fill_value=-1, dtype=np.int16)

for pred, minx, miny, maxx, maxy in patch_results:
    col = int(round((minx - all_minx) / res))
    row = int(round((all_maxy - maxy) / res))
    ph, pw = pred.shape
    raster[row:row + ph, col:col + pw] = pred

print(f'Raster: {out_h} × {out_w} px  ({out_h * res / 1000:.1f} × {out_w * res / 1000:.1f} km)')

extent_utm = [all_minx, all_maxx, all_miny, all_maxy]
masked_raster = np.ma.masked_where(raster < 0, raster)

fig, axes = plt.subplots(1, 2, figsize=(16, 7))

# Left: predicted LCZ map
axes[0].imshow(masked_raster, cmap=lcz_cmap, norm=lcz_norm,
               extent=extent_utm, origin='upper', interpolation='nearest')
gdf.boundary.plot(ax=axes[0], color='white', linewidth=0.3, alpha=0.4)
axes[0].set_title('Predicted LCZ (full ROI)')
axes[0].set_xlabel('Easting (m)')
axes[0].set_ylabel('Northing (m)')

# Right: ground-truth labels
gdf.plot(color=gdf[LABEL_COL].map(lambda c: lcz_dict[c]['color']), ax=axes[1], alpha=0.9)
axes[1].set_title('Ground truth (So2Sat patches)')
axes[1].set_xlabel('Easting (m)')
axes[1].set_ylabel('Northing (m)')

# Shared legend
fig.legend(handles=lcz_legend_handles(), fontsize=9, ncol=6,
           loc='lower center', bbox_to_anchor=(0.5, -0.09), framealpha=0.8)

plt.tight_layout()
plt.show()
Raster: 2441 × 3297 px  (24.4 × 33.0 km)

10. Export Prediction to GeoTIFF

Code 
from rasterio.transform import from_bounds as rasterio_from_bounds

output_path = f'nairobi_lcz_{PRESET}_prediction.tif'

transform = rasterio_from_bounds(all_minx, all_miny, all_maxx, all_maxy, out_w, out_h)

# Write 1-indexed classes (0 = nodata) so the file is self-consistent with lcz_dict
export_raster = np.where(raster >= 0, raster + 1, 0).astype(np.uint8)

with rasterio.open(
    output_path, 'w',
    driver='GTiff',
    height=out_h, width=out_w,
    count=1,
    dtype='uint8',
    crs=TIF_CRS,
    transform=transform,
    nodata=0,
) as dst:
    dst.write(export_raster, 1)

print(f'Saved: {output_path}  ({out_h}×{out_w} px, CRS={TIF_CRS.to_epsg()})')
Saved: nairobi_lcz_small_prediction.tif  (2441×3297 px, CRS=32737)
Back to top ]]> phd tessera https://ancazugo.github.io/posts/2026-03-15-weekly-notes.html Sun, 15 Mar 2026 00:00:00 GMT Weekly Notes - 2026-03-08 Andrés C. Zúñiga-González https://ancazugo.github.io/posts/2026-03-08-weekly-notes.html

Introduction

The last two weeks have been entirely dedicated to working on the model for LCZ zones. I will talk about experiment design and some preliminary results I’ve gotten from the model so far.

LCZ Classification

As mentioned in previous posts, I intend to use the So2Sat LCZ42 dataset to train a model to classify LCZ zones in major urban areas. Choosing an initial case study was crucial for evaluating the feasibility of the project. The two main reasons for selection were:

  1. There are So2Sat patches in said city
  2. There are embeddings (AlphaEarth and TESSERA) readily available for the city for 2017

With that said, with Anil we had decided to work with Paris or Madrid. However, we had ignored on key factor: change in land use over time. (Most) major European cities have not had major changes in land use for urban expansion for the last decade, so seeing change in LCZ distribution over time was very unlikely. On the other hand, cities in Latin America and Africa have massively grown in extension so even in a 10-year span land use can vary a lot. I can talk about this from experience (see Bogotá in Google Earth). For this reason, Nairobi was an obvious choice and also because I happen to be working on a project with Saitabau Kumary on building efficiency there.

Model Design

Initially, I treated the problem as a classification task (the kind of cat vs dog in images), but after many different combinations of models and embeddings, the results were not promising. I tried using ResNet18 and ResNet50 with ImageNet weights and sensor-agnostic weights from torchgeo with both Tessera and AlphaEarth but none of them were able to perform at the same level as standard RF or MLP models that use pixel sampling and do not consider the spatial information. So with this is mind, I adapted Sadiq’s U-net example for Tessera embeddings for solar power detection. In this case, it uses Dice and Cross-entropy losses to train the model, but it doesn’t punish misclassification in areas where labels are not available, which is in pretty much all the ROI. And the results look pretty good, but I did encounter an issue with stitiching the tiles together. I tried the models with zero padding first and then reflection padding, but they still have a 32-px wide artifact in the edges. Worth noting that implementing reflection padding improved the models a bit.

In these models both Tessera and AlphaEarth perform similarly, at least according to training metrics. Below is a preliminary map Saitabau and I designed for his project. Interestingly, the best models were those trained using the medium size U-net, not the larger ones. Overall it is able to differentiate between built-up and natural areas, but it misclassifies some of the classes (notably water, which is not very present in Nairobi). It does well between the first 7 classes (compact and open). In those underrepresented classes is where simpler models perform better, but it’s because they use a similar number of pixels per class.

Since I want to see change in time, I used the weights from these models to do inference on embeddings from 2025, but the results were reversed than what actually happened in Nairobi (the results show less densification of built-up areas).

A big shout-out to the team behind So2Sat dataset for kindly updating and correcting the georeferencing metadata for the patches. At the moment, I’m trying to do experiments with European cities, starting with London and then Paris.

Nairobi LCZs from 2017 as predicted from AlphaEarth embeddings

Other Stuff

I recently started working on a project to use ariborne images to evaluate vegetation health in Wales (details to be shared in time). Likely this will include some of the methods I’ve already used but incorporating ground surveys and drone imagery from the area.

In addition to this, the last few days have been pretty busy preparing and running the half-marathon in Cambridge (I survived, my left knee didn’t 😂). Expect a post about how I used Gemini and Garmin data to prepare for the race.

Also, I’ve been preparing a visit from Colombian government officials to the university this coming week to commemorate the 10th anniversary of the peace agreement with FARC, which I’ll be moderating and translating. This is the first of a series of seminars we will host at CUCOL until the end of the academic year in June. This comes in a very interesting timing, not only due to the context of international relationships in the Americas in the last few months, but also because Colombia is going through general elections, which started today with congressional elections and will end in couple of months with the presidential elections. So this is a good opportunity to showcase the work Colombian researchers are doing in Cambridge and hopefully draw some (much needed) attention towards R+D in the country.

Back to top ]]> phd https://ancazugo.github.io/posts/2026-03-08-weekly-notes.html Sun, 08 Mar 2026 00:00:00 GMT Weekly Notes - 2026-02-15 Andrés C. Zúñiga-González https://ancazugo.github.io/posts/2026-02-15-weekly-notes.html

Introduction

This is quite a large update as it includes everything I’ve done for the past two weeks. I’ll talk about the LCZ classification and road mapping projects as well as my first actual experience with Claude Code and a cool toy example.

LCZ Classification

It turns out that getting the right labels for LCZ classes is more complicated than expected. As mentioned in previous posts, I intended to use the So2Sat LCZ42 dataset, which was manually created by the authors. They provide a helpful script to download and decompress the datarray of 320 x 320 m patches, including Sentinel-1 and 2 data. For the past two weeks I’ve been trying to make sense of the data and making sure that I’m following the right steps to get the labels and coordinates of the patches. I’ve downloaded the ~400k dataset three times to triple check that they are right but unfortunately, I think they are actually wrong, as some of the georeferencing metadata seems to be corrupted. For instance, all the patches that (I assume) belong to London, actually fall in Celtic Sea, roughly at the same latitude as London. This is easily solvable by adjusting the metadata, but the biggest issue so far is that some of the lables are not correct, not even remotely close to what you would expect. Ignoring the georeferencing problem, features are still visible in the Sentinel-2 images and some clearly urban high rise areas are mislabelled as natural areas.

At the moment, I’ve reached out to the authors of the dataset to ask for their clarification on the labels and georeferencing. For now, I’m working with the Demuzere labels that are part of WUDAPT. And to be able to compare both Tessera and AlphaEarth at the same point in time, I’ve requested the Tessera embeddings for the same 42+10 cities present in the So2Sat dataset.

I guess related to this, I applied to go to the Urban Climate Summer School in September in Bochum, Germany. This school apparently only takes place every 4 years so I’m crossing my fingers that I get in.

Road Mapping

This week I resumed work on this project by searching what the best strategy is for categorising different features from OSM. Critically, OSM stores data in different layers: buildings are polygons that may be on the landuse=residential layer. This means that in order to map roads and other features, such as trees, croplands, water bodies, how to merge them is crucial. Merging them is not the hard part, but defining what belongs to what is, given the heterogeneity of OSM tags. With the help of LLMs and some initial categorisation I did with Charles, I think I’ve more or less defined most categories, but there will likely be and undefined label for stuff that is not captured by any of the tags/layers.

Claude Code work

I feel a bit embarrassed to say that I hadn’t used Claude code until a few days ago. Most of my coding was done by a combination of my input and cursor (pro version) and ChatGPT + Gemini. While this coding setup was way more efficient than just doing it on my own, I did find that when I wanted larger tasks or reforms of the code, it would become messy and hard to track. Nonetheless, a couple of days ago I attended the Claude Society workshop in the Engineering Department, where I actually “learned” how to use Claude Code and WOW!!!!

First, with just two prompts I was able to do a globe with time zones using three.js. Obviously a lot can be improved, but it still is a better and faster starting point than someone learning JavaScript and three.js from scratch. First, it splitted the globe into 24 equal parts, but then I asked it to use the real time zones and where to get them. My point was to prove that the Iberian peninsula has a weird timezone, and should be the same as the UK not the Central European Time.

Then, I used Claude to change the Quarto base styles for my website (as you can see if you’ve been here before 😉) and generate the listings and tabs for additional content in the website like Projects and talks (this last one is still a work in progress).

Finally, I had this repo concept that started from the LCZ project where I wanted to make it possible to download and use in a standard way both AlphaEarth and Tessera embeddings. The idea was to use the backbone of torchgeo, which uses Pytorch lightning for easier training and inference. It was taking a long time for me to develop this from scratch, so I gave Claude my codebase, which contained functions that I had created with xarray, gee, xee and geotessera to retrieve the embeddings, store them as zarr, read them as xarray arrays and use them with Torchgeo. And Claude delivered!!!! Not without errors, of course, but I think that’s where the specialist comes in, because I was able to direct the agent to the specific error, or even I would make the changes myself. So far it’s working close to what I had in mind. I will report back on this next week as I’m still working on it.

Time Zones Globe

Weekly Objectives

  • Run multi city models for LCZ classification
  • Have a look at how to get the Embedded Seamless Data embeddings (if there’s an API for that)
  • Clean code for the OSM tags to be used for road mapping
  • Ne ratez pas l’examen d’écoute de français 🇫🇷😬
Back to top ]]> phd dataviz llm https://ancazugo.github.io/posts/2026-02-15-weekly-notes.html Sun, 15 Feb 2026 00:00:00 GMT Catching up with stuff Andrés C. Zúñiga-González https://ancazugo.github.io/posts/2026-02-01-weekly-notes.html

Introduction

The last week was my first back in the UK, which meant that most of the week was spent reviewing where I left things in December last year. That also included doing supervision work for the Maths and programming course I was teaching in the Department of Architecture.

3-30-300 Project

As mentioned in the previous post, the paper didn’t even make it to the review process so I’ve been working on tailoring it to fit the new journal. What this means is that I’ve had to tone down on certain topics like urban planning in order to make more emphasis in the environmental and natural aspect of the paper.

Although not related to the paper, I started the transition of the main module attached to the paper to a new project so it can be installed as a package. The idea is for the metrics to be calculated for a given city or region, regardless of whether they are in England or not (as the current code works). How I’m doing it is by extending the capabilities of the code to extract buildings from OSM, but also to give the user the option to provide their own building polygons. In addition to this, users would need to provide a tree dataset and a park one (which could be from OSM as well). The reason behind this work is because in the meetings with Ronita, we had discussed the possibility of doing a comparative study with cities outside the UK, and I wanted to reduce the amount of work required to do so, by standardising the existing one and turning it into a package.

Other work

As part of his PhD project, my fellow SDG member Saitabau Kumary, is working on the built up infrastructure of Nairobi in Kenya. I am part of the project and I measured some of the spectral signature across the years that Sentinel-2 is available to see how built up areas and vegetation have changed over time (see image below). Although the urban growth is not very clear, there are some patterns of NDVI reduction. We’ll likely have to narrow the analysis to a specific period in the year (e.g. rainy season) to avoid misinterpretation of the data due to seasonal variations.

Average NDVI for Nairobi between 2016 and 2025

Weekly Objectives

  • Prepare slides for SDG meeting next week
  • Finish corrections for the new version of the manuscript
Back to top ]]> phd https://ancazugo.github.io/posts/2026-02-01-weekly-notes.html Sun, 01 Feb 2026 00:00:00 GMT 2025 in review Andrés C. Zúñiga-González https://ancazugo.github.io/posts/2026-01-12-year-in-review.html Late to the party as it’s already mid-January, but here’s a quick review of 2025. I will mostly talk about the projects I’ve worked on, events I’ve attended and lessons learned in the process. It’s nice to reflect on what I’ve done to have more clarity of what’s coming in 2026 as it is the last full year of my PhD.

First and foremost, I have to say that the thing I’m most proud of from 2025 is actually this blog. It’s been so useful to keep myself accountable for my work and see my thoughts and progress written somewhere that I can come back and review later. Not only that, but some friends and colleagues have found my posts useful too. Safe to say that I will continue posting here in 2026, probably with a bit more order to keep things tidy.

I got two attend two conferences this year: BIOSPACE25 in Frascati and PROPL25 in Singapore. Not only was this the first time I visited those countries, but it was also my first time doing oral presentations, as my previous experiences were only posters. The feedback I got from both of these events were very constructive to my work, particularly for the 3-30-300 project. The highlight of BIOSPACE was the opportunity to visit ESA HQ for the first time and see what people from all over the world were working on to preserve biodiversity. On the other hand, PROPL served as the first time I presented in a CS conference, which was a very enriching experience, as many of the people I interacted with were not necessarily related to environmental sciences, so it was a great to get feedback from a different perspective.

From a personal development standpoint, I feel like this is the year where things started to click for me in terms of how to approach my PhD. I think I know now how to structure better the projects both from technical and non-technical perspectives. One of the things I set myself to do was to write better code, almost as software engineers do. This led me to learn how to use different tools for writing documentation, coding efficiently and more modularly. This year I really understood tools like Sedona or Xarray or complex topics behind the Foundation Models. This just goes to highlight one of the biggest realisations of academia: iterative learning is the key to progress.

I think it wouldn’t be a fair recap of the year if I didn’t mention stuff that didn’t go as planned, because part of a PhD, and life itself, is learning from mistakes and improving the next time. At the end of the day, the goal is to fail less because that means you are learning. With that said, one year ago I set myself the goal of doing an internship during the summer, which didn’t happen in the end, despite applying to three different positions. Hopefully 2026 will be different. Also, at the very end of the year, I got the 3-30-300 paper rejected from the journal my supervisors and I had planned since the beginning, so now I’m working on making the changes to get it submitted to a different journal.

I want to finish this post by mentioning the things I’m really looking forward to in 2026. This is my last full year of the PhD, so I’ll be looking into wrapping up the projects I’ve been working on with the 3-30-300 and Tessera, as well as some smaller projects I’ve started recently (more info in previous posts). I will also be looking into attending more conferences and do networking. One of the things I set myself to do in 2026 is to continue my learning path of SW good practices with the goal of getting ready for what comes after the PhD, so I’m very eager to finally start learning DS&A and MLOps, as those seem to be very in-demand skills in the job market.

Finally, I want to share one of my favorite photos of the year for the post thumbnail 😅: For the first time in my life I got to see the national tree1 of Colombia in its natural habitat. The wax palm (Ceroxylon quindiuense) can grow up to 60 meters tall, making it the tallest palm in the world, which is impressive, but sounds even cooler when you realise that these bad boys are only found in the middle of the Andes in altitudes up to 3,000 meters above sea level. Not exactly the best place to grow a giant plant and definitely not the warm beach-like environment one would associate with a palm tree. These ones are found in the Cocora Valley (Valle del Cocora) as part of the Los Nevados National Park in the middle of the Coffee Axis, the coffee growing region of Colombia.

Wax Palms in the Cocora Valley
Back to top

Footnotes

  1. Fun fact: palms aren’t even real trees, so what are we doing here 🤣???↩︎

Reuse

]]> phd https://ancazugo.github.io/posts/2026-01-12-year-in-review.html Mon, 12 Jan 2026 00:00:00 GMT 2025-11-23 Weekly Notes Andrés C. Zúñiga-González https://ancazugo.github.io/posts/2025-11-23-weekly-notes.html

Intro

It’s been a while since I last posted so thought I would give an update on everything that’s been going on in the last couple of weeks, including the 3-30-300 project and related presentations, the new project I’m working on for my PhD and more Tessera stuff (ft. Charles Emogor).

3-30-300 Project

In the last 6 weeks I’ve had the chance to present my work on this paper to different audiences, and I’ve got very good impressions. The overall consensus of the presentations is that it is very clear, and despite the technical nature of the project and the complexity of it, I’ve made myself clear.

  • Imperial College at the introductory lecture for the “From Data to Product” course (invited by Pierre Pinson)
  • Talk + Poster @ PROPL25 Conference (part of ICFP/SPLASH 2025) in Singapore (organised by Anil)1
  • Group Meeting at the Sustainable Design Group (SDG) (my group in Architecture with Ronita)
  • EEG meeting (Computer Science, led by Keshav)
  • PhD Conference at the Department of Architecture (for 3rd year PhD students)

In the Imperial talk, I got some interesting takes from Masters students in the Design Engineering course who were very curious on how I got from the raw data to the fancy dashboards (which is what they have to do at the end of the term, I believe). In both the EEG and SDG group meetings, I got some interesting questions about how my metrics can actually impact policymaking and how they can be applied in other countries. In the PhD Conference I got some very good comments from actual architects and people who don’t necessarily work with data-related projects. It was definitely challenging to adjust the language, particularly when talking about the methods and technical stuff.

Overall, having all these talks so close to each other was quite intense but the fact that I had to adjust my language and slides to accommodate to the audience definitely helped me to clarify my own thoughts about the project and made me realise which parts are more relevant to different people, which as researchers is crucial when you want to engage with colleagues, policymakers or the general public.

Paper

The paper saw some slight changes due to missing some key citations and mixing of terms, e.g. I was using the terms (in)equity and (in)equality interchangeably, which is not correct. As much as I would like to measure green equity, that is beyond the scope of using proximity or count-based metrics (equality), which don’t really account how nature provision actually impacts people. Furthermore, I’m using the Gini metric which is a direct measure of inequality.

After meeting with Ronita and Anil, I rewrote part of the discussion to highlight the key findings, which are (hopefully) the catch for the editors: only 0.1% of the country lives in areas where the 3-30-300 is attained, and contrary to what one would expect, deprived areas live in closer proximity to green spaces. The reason behind this could be due to several factors: (i) affluent neighbourhoods may have more private gardens and wealthier families may make use of other green spaces; (2) the quality of green spaces in rich and poor neighbourhoods is not the same, for instance, when you look at crime and health-related metrics, the relationship between the distance to park is clear, meaning that those parks in poor areas are seen as less safe and the kind of vegetation in those areas may not provide the same ecosystem services like air pollution reduction. While this is not directly measured in the paper, I think it is an important point to make because in some neighbourhoods green equity (not equality) can be improved, not by creating more spaces, but by working on making the existing ones better.

Tessera Stuff

Mapping Human Infrastructure in Nature Reserves

Alongside Charles Emogor, we’ve been working on a project to map human infrastructure in nature reserves around the world using Tessera embeddings (and other GeoFMs). The original idea was to use the high-resolution embeddings to identify and classify different types of infrastructure, such as trails, buildings, and other human-made structures within protected areas. We met several times and brainstormed for a while on which datasets are available as labels. The obvious choice was OpenStreetMaps, but the first attempt we did was using Google’s Open Buildings dataset. The binary classifier was pretty good, but Anil pointed out that using AI-derived data might not be the best approach. So we used Overture Maps data, filtering for only OSM-derived features, including roads, buildings and infrastructure.

As case studies, we initially wanted to use the Cross River park in Nigeria where Charles has worked in, thus has a lot of local info, but realised that the polygons we used for querying the embeddigns (World Database on Protected Areas, WDPA) did not include all the areas, so we picked the Parc National de Taï in Cotê d’Ivoire and the Nairobi National Park in Kenya.

Using the same logic behind the classifier for local climate zones in my last post, I rasterised the built-up infrastructure from overture and sampled equally for all classes and trained an MLP classifier. The results are not that bad considering the limited amount of data and that it is not using spatial information.

After meeting with Anil, Sadiq and Robert Fletcher, we agreed that the best approach would be to map only roads, so Charles and I are working with using road data from OSM as well as from Sentinel to detect new roads. We are going to work with areas where new roads have been built.

A super short notebook, similar to the one in the LCZ classification project is available here.

LCZ Classification

This project has been dorman for a while but I found something that will be super useful. So, going back to what I had posted about it. I want to reclassify the local climate zones (LCZ) using Tessera embeddings. As labels, I was using Geoclimate and a dataset from a paper (Demuzere et al), however, the former uses data from OSM, which is incomplete for most Global South cities, so some attributes like building height are likely missing or wrong, thus the classification is not right, while the latter is an AI-derived product and that is not ideal (see comments for mapping infrastructure in nature reserves). But last week I found SoSat2-LCZ42 (published by the Data Science in Earth Observation in TUM), which is a manually labelled dataset for 42 cities around the world, including cities in Africa, Asia and South America. The dataset includes Sentinel-2 imagery and LCZ labels, with splits for training, validation and testing. That is exactly for I needed, and with this I can do a fair comparison between Tessera, AlphaEarth and other GeoFMs.

Nex PhD project

So after meeting with Anil and Ronita, we discussed the next steps for my PhD after the 3-30-300. A very exciting idea came out of it and is ussing GeoFMs like Tessera for a Health Impact Assessment (HIA) of green space policies like the 3-30-300 in England. For those not familiar with HIA, it is a process that helps evaluate the potential health effects of a policy, program, or project on a population. There are multiple approaches to develop a HIA. According to this paper, there are 7 main cateogries of methods for a HIA, including what they name AI/ML but it’s mostly just regressions. Based on this and using some literature published in The Lancet suggested by Ronita (in Philadelphia and globally), I think the best approach is to use Tessera to fill in the gaps in the Vegetation Object Model (VOM) I used for the 3-30-300 project. As mentioned in the paper this is a LiDAR-derived model that contains only vegetation information at 1 m resolution. The data is only available for 2018-2023, but it doesn’t have data for all areas and all years, in fact, some areas only have for one or two years. That’s where GeoFMs come in, as they can provide the missing information for the years where VOM wasn’t available. And, I can get access to mortality data for all of England from 2014 to 2024, plus access to buildings and parks for all years as well. This would give me a strong data foundation for a HIA and potentially for causal-related methods, which are very common in public health studies.

Using that information, with a health-related metric like mortality for the same years, we can do a HIA of canopy cover change in English cities. Alternatively, and following similar methodologies in other papers, we could use NDVI to see the changes in greenness instead of canopy cover, which in theory it’s easier but also less exciting, I would say 😅.

Website Changes

I removed google analytics and cookies request from this website. I’m also changing the website to include a new tab for talks and projects where I can embedd the slides I’ve done with revealjs. What I’m trying to do is to publish a different repo as part of the main website. I attempted to do it during PROPL25 so that people could follow the slides live and watch them later, but my website crashed completely and 1 hour before the talk I had to revert the changes 😭. I’ll probably update this over the Christmas period.

Back to top

Footnotes

  1. Notes in a different post↩︎

Reuse

]]> phd https://ancazugo.github.io/posts/2025-11-23-weekly-notes.html Sun, 23 Nov 2025 00:00:00 GMT 2025-11-16 Tessera Example Andrés C. Zúñiga-González https://ancazugo.github.io/posts/2025-11-16-tessera_example.html

Libraries

Code 
%load_ext autoreload
%autoreload 2
import sys
sys.path.append('../src')

from utils.paths import national_parks_dir, wdpa_dir
from gee_helpers import authenticate_ee, request_gee_image
from protected_area import ProtectedArea
from infrastructure.open_buildings import OpenBuildings
from classifiers.pixel_classifier import PixelClassifier
from embeddings.alpha_earth import AlphaEarthEmbeddings
from embeddings.geotessera import GeoTesseraEmbeddings
import pandas as pd
import geopandas as gpd
import ee
import xee
import eemont
from overturemaps import core
import xarray as xr
import rasterio
from rasterio import features
import numpy as np
import affine
import matplotlib.pyplot as plt
import matplotlib.colors as mcolors
import matplotlib.cm as cm
from matplotlib.colors import ListedColormap

authenticate_ee()

To authorize access needed by Earth Engine, open the following URL in a web browser and follow the instructions:

https://code.earthengine.google.com/client-auth?scopes=https%3A//www.googleapis.com/auth/earthengine%20https%3A//www.googleapis.com/auth/cloud-platform%20https%3A//www.googleapis.com/auth/drive%20https%3A//www.googleapis.com/auth/devstorage.full_control&request_id=xbH3faffvz8qRwyOQ3msXBCESmRB0Um8ljRA94w7AcQ&tc=uM8DkjWbRu40VR-ElOaLlKB2dLoEwfJvWWJmdHc3sSA&cc=byj4PTB3f7JT9vuUWYB2w_u01OltClo93hP3WiNvKpw

The authorization workflow will generate a code, which you should paste in the box below.


Successfully saved authorization token.

Data

Code 
wdpa_files = list(wdpa_dir.rglob("*polygons.shp"))
Code 
wdpa_polygons = pd.concat([gpd.read_file(f) for f in wdpa_files])
wdpa_polygons['WDPAID'] = wdpa_polygons['WDPAID'].astype(int).astype(str)
Code 
# example_row = wdpa_polygons[wdpa_polygons["WDPAID"] == "555784094"]  # CIV: 555784094
# example = ProtectedArea(name=example_row["NAME"].values[0], 
#                         wdpaid=example_row["WDPAID"].values[0], 
#                         country_code=example_row["ISO3"].values[0],
#                         bbox=example_row.total_bounds.tolist())
example = ProtectedArea(name='Nairobi National Park', 
                        wdpaid='000000', 
                        country_code='KEN',
                        bbox=[36.747789403997196, -1.4398202050048914, 36.97884561842, -1.3045898658971178])
example
ProtectedArea(name='Nairobi National Park', wdpaid='000000', country_code='KEN', bbox=[36.747789403997196, -1.4398202050048914, 36.97884561842, -1.3045898658971178], climate_type='Csb', utm_crs='EPSG:32737', utm_bbox=[249399.0491072322, 9840732.461804673, 275107.1157634887, 9855713.033102514])

Embeddings

AlphaEarth Embeddings

Code 
year = 2023
ae_2023 = AlphaEarthEmbeddings(protected_area=example, year=year)
ae_embeddings_2023_da = ae_2023.get_embeddings()
ae_embeddings_2023_da
2025-11-24 10:33:58.212 | INFO     | embeddings.base:get_embeddings:46 - Loading cached 'AlphaEarth' embeddings from /maps/acz25/phd-thesis-data/input/Google/AlphaEarth/2023/KEN/000000_ae.zarr

2025-11-24 10:33:58.746 | INFO     | embeddings.base:get_embeddings:53 - Chunking 'AlphaEarth' embeddings

<xarray.DataArray (band: 64, y: 1498, x: 2571)> Size: 986MB
dask.array<rechunk-merge, shape=(64, 1498, 2571), dtype=float32, chunksize=(64, 512, 512), chunktype=numpy.ndarray>
Coordinates:
  * band     (band) object 512B 'A00' 'A01' 'A02' 'A03' ... 'A61' 'A62' 'A63'
  * y        (y) float64 12kB 9.841e+06 9.841e+06 ... 9.856e+06 9.856e+06
  * x        (x) float64 21kB 2.494e+05 2.494e+05 ... 2.751e+05 2.751e+05
Attributes:
    crs:      EPSG:32737

Tessera Embeddings

Code 
year = 2024
gt_2024 = GeoTesseraEmbeddings(protected_area=example, year=year)
gt_embeddings_2024_da = gt_2024.get_embeddings()
gt_embeddings_2024_da
2025-11-24 10:34:00.447 | INFO     | embeddings.base:get_embeddings:46 - Loading cached 'GeoTessera' embeddings from /maps/acz25/phd-thesis-data/input/GEOTESSERA/clipped/2024/KEN/000000.zarr

2025-11-24 10:34:00.585 | INFO     | embeddings.base:get_embeddings:53 - Chunking 'GeoTessera' embeddings

<xarray.DataArray (band: 128, y: 1500, x: 2572)> Size: 2GB
dask.array<rechunk-merge, shape=(128, 1500, 2572), dtype=float32, chunksize=(128, 512, 512), chunktype=numpy.ndarray>
Coordinates:
  * band         (band) object 1kB 'A001' 'A002' 'A003' ... 'A126' 'A127' 'A128'
  * y            (y) float64 12kB 9.856e+06 9.856e+06 ... 9.841e+06 9.841e+06
  * x            (x) float64 21kB 2.494e+05 2.494e+05 ... 2.751e+05 2.751e+05
    spatial_ref  int64 8B ...
Attributes:
    GEOTESSERA_VERSION:       0.6.0
    TESSERA_DATASET_VERSION:  v1
    TESSERA_DESCRIPTION:      GeoTessera satellite embedding tile
    TESSERA_TILE_LAT:         -1.45
    TESSERA_TILE_LON:         36.75
    TESSERA_YEAR:             2024
    AREA_OR_POINT:            Area
    scale_factor:             1.0
    add_offset:               0.0
    long_name:                ['Tessera_Band_0', 'Tessera_Band_1', 'Tessera_B...

Infrastructure

Overture Maps

Code 
bbox = [ 0.08756552498492204, 52.16590292629015, 0.18025552851118945, 52.242523558881146]
bbox = example.bbox
Code 
roads = core.geodataframe('segment', bbox)
buildings = core.geodataframe('building', bbox)
infrastructure = core.geodataframe('infrastructure', bbox)
roads.crs = 'EPSG:4326'
buildings.crs = 'EPSG:4326'
infrastructure.crs = 'EPSG:4326'
Code 
# sources column contains a ndarray/dict per row, filter out both 'Google Open Buildings' and 'Microsoft ML Buildings'
def exclude_open_and_ml_buildings(sources):
    # sources can be a dict or a list/np.ndarray of dicts
    srcs = sources if isinstance(sources, (list, np.ndarray)) else [sources]
    wanted = {'OpenStreetMap'}
    # If any source has an unwanted dataset, exclude this row
    return any(src.get('dataset') in wanted for src in srcs)

mask = buildings['sources'].apply(exclude_open_and_ml_buildings)
filtered_buildings = buildings.copy()[mask]
filtered_infrastructure = infrastructure.copy()[infrastructure.geom_type.isin(['MultiPolygon', 'Polygon', 'LineString', 'MultiLineString'])]
Code 
osm_classes = {'roads': {'rail': {'rail': ['funicular', 'light_rail', 'monorail', 'narrow_gauge', 'standard_gauge', 'tram'], 
                                  'other_rail': ['unknown']},
                         'road': {'road': ['living_street', 'motorway', 'residential', 'primary', 'secondary', 'service', 'tertiary', 'track'], 
                                           'truck': ['truck'],
                                           'other_road': ['unclassified', 'unknown']},
                         'water': {'water': ['water']}},
               'buildings': ['outbuilding']}
Code 
def get_new_class(value, dict):
    for k, v in dict.items():
        if value in v:
            return k
    return 'other'

roads['new_class'] = roads.apply(lambda x: get_new_class(x['class'], osm_classes['roads'][x['subtype']]), axis=1)
filtered_buildings = filtered_buildings[filtered_buildings['subtype'] != 'outbuilding']
filtered_buildings['new_class'] = 'building'
filtered_infrastructure['new_class'] = 'infrastructure'
Code 
# 1. Choose the reference transform and shape (use AlphaEarth embeddings, infra, or buildings as reference)
# We'll use the ae_infra_pred_roi_da (assumed to be an xarray DataArray with x/y dims and crs)
reference_da = ae_embeddings_2023_da  # Should be defined in the notebook above

transform = reference_da.rio.transform() if hasattr(reference_da, "rio") else affine.Affine(
    (reference_da.x[1] - reference_da.x[0]).item(), 0, reference_da.x[0].item(),
    0, (reference_da.y[1] - reference_da.y[0]).item(), reference_da.y[0].item()
)
out_shape = (len(reference_da.y), len(reference_da.x))

# Prepare the geometries and their values for rasterization
# Assign values:
#   1 = building  (filtered_buildings)
#   2 = road      (roads)
#   3 = infrastructure

shapes = []
filtered_buildings = filtered_buildings.to_crs(example.utm_crs)
roads = roads.to_crs(example.utm_crs)
filtered_infrastructure = filtered_infrastructure.to_crs(example.utm_crs)
# Buildings
for g in filtered_buildings.geometry:
    if g is not None and not g.is_empty:
        shapes.append((g, 1))
# Roads
for g in roads.geometry:
    if g is not None and not g.is_empty:
        shapes.append((g, 2))
# Infrastructure
for g in filtered_infrastructure.geometry:
    if g is not None and not g.is_empty:
        shapes.append((g, 3))

# Rasterize
raster = features.rasterize(
    shapes=shapes,
    out_shape=out_shape,
    transform=transform,
    fill=0,
    dtype='float32'
)
Code 
# Add "band" coordinate with value "overture" to the raster DataArray
overture_da = xr.DataArray(
    raster[None, :, :],  # add a new axis for band
    dims=('band', 'y', 'x'),
    coords={'band': ['overture'], 'y': reference_da.y, 'x': reference_da.x},
).rio.write_crs(example.utm_crs)

overture_da
<xarray.DataArray (band: 1, y: 1498, x: 2571)> Size: 15MB
array([[[0., 0., 0., ..., 0., 0., 0.],
        [0., 0., 0., ..., 0., 0., 0.],
        [0., 0., 0., ..., 0., 0., 0.],
        ...,
        [2., 0., 2., ..., 0., 0., 0.],
        [0., 2., 2., ..., 0., 0., 0.],
        [0., 2., 0., ..., 0., 0., 0.]]],
      shape=(1, 1498, 2571), dtype=float32)
Coordinates:
  * band         (band) <U8 32B 'overture'
  * y            (y) float64 12kB 9.841e+06 9.841e+06 ... 9.856e+06 9.856e+06
  * x            (x) float64 21kB 2.494e+05 2.494e+05 ... 2.751e+05 2.751e+05
    spatial_ref  int64 8B 0

Classifier

Binary

Code 
from sklearn.neural_network import MLPClassifier
from sklearn.metrics import ConfusionMatrixDisplay

mlp_classifier = MLPClassifier(hidden_layer_sizes=(100, 100), max_iter=2000, random_state=411)

new_class_dict = {0:0, 1: 1, 2:1, 3:1}

AlphaEarth

Code 
ae_infra_classifier = PixelClassifier()
ae_infra_classifier._classifier = mlp_classifier
X, y, coords, labels_da = ae_infra_classifier.prepare_data(overture_da, ae_embeddings_2023_da, "overture", 2000)
2025-11-24 10:41:19.248 | INFO     | classifiers.pixel_classifier:prepare_data:90 - Preparing data for band overture

2025-11-24 10:41:19.382 | INFO     | classifiers.pixel_classifier:_sample_classes:26 - Sampling classes for band overture

2025-11-24 10:41:21.091 | INFO     | classifiers.pixel_classifier:_extract_embeddings:55 - Extracting embeddings for 8000 coordinates
Code 
ae_infra_classifier.train()
2025-11-24 10:41:54.241 | INFO     | classifiers.pixel_classifier:train:129 - ✅ Model training complete.

MLPClassifier(hidden_layer_sizes=(100, 100), max_iter=2000, random_state=411)
In a Jupyter environment, please rerun this cell to show the HTML representation or trust the notebook.
On GitHub, the HTML representation is unable to render, please try loading this page with nbviewer.org.
Code 
y_ae_infra_test_pred = ae_infra_classifier.evaluate()
ConfusionMatrixDisplay.from_estimator(ae_infra_classifier._classifier, ae_infra_classifier._X_test, ae_infra_classifier._y_test)
2025-11-24 10:41:54.293 | INFO     | classifiers.pixel_classifier:evaluate:137 - 

--- 📊 Classification Report ---

              precision    recall  f1-score   support

           0       0.69      0.70      0.70       600
           1       0.67      0.72      0.69       600
           2       0.55      0.53      0.54       600
           3       0.88      0.83      0.85       600

    accuracy                           0.70      2400
   macro avg       0.70      0.70      0.70      2400
weighted avg       0.70      0.70      0.70      2400

Code 
ae_infra_pred_roi_da = ae_infra_classifier.classify_roi(ae_embeddings_2023_da)
ae_infra_pred_roi_da = ae_infra_pred_roi_da.rio.write_crs(example.utm_crs)
ae_infra_pred_roi_da
2025-11-24 10:41:54.575 | INFO     | classifiers.pixel_classifier:classify_roi:148 - Classifying entire ROI

<xarray.DataArray 'predicted_class' (y: 1498, x: 2571)> Size: 31MB
array([[0, 0, 0, ..., 1, 1, 1],
       [0, 0, 0, ..., 1, 1, 1],
       [0, 0, 0, ..., 1, 1, 1],
       ...,
       [2, 0, 0, ..., 0, 0, 0],
       [2, 2, 2, ..., 0, 0, 0],
       [2, 2, 2, ..., 0, 0, 0]], shape=(1498, 2571))
Coordinates:
  * y            (y) float64 12kB 9.841e+06 9.841e+06 ... 9.856e+06 9.856e+06
  * x            (x) float64 21kB 2.494e+05 2.494e+05 ... 2.751e+05 2.751e+05
    spatial_ref  int64 8B 0

Tessera

Code 
gt_infra_classifier = PixelClassifier()
gt_infra_classifier._classifier = mlp_classifier
X, y, coords, labels_da = gt_infra_classifier.prepare_data(overture_da, gt_embeddings_2024_da, "overture", 2000)
2025-11-24 10:42:43.902 | INFO     | classifiers.pixel_classifier:prepare_data:90 - Preparing data for band overture

2025-11-24 10:42:44.006 | INFO     | classifiers.pixel_classifier:_sample_classes:26 - Sampling classes for band overture

2025-11-24 10:42:46.176 | INFO     | classifiers.pixel_classifier:_extract_embeddings:55 - Extracting embeddings for 8000 coordinates
Code 
gt_infra_classifier.train()
2025-11-24 10:43:09.032 | INFO     | classifiers.pixel_classifier:train:129 - ✅ Model training complete.

MLPClassifier(hidden_layer_sizes=(100, 100), max_iter=2000, random_state=411)
In a Jupyter environment, please rerun this cell to show the HTML representation or trust the notebook.
On GitHub, the HTML representation is unable to render, please try loading this page with nbviewer.org.
Code 
y_gt_infra_test_pred = gt_infra_classifier.evaluate()
ConfusionMatrixDisplay.from_estimator(gt_infra_classifier._classifier, gt_infra_classifier._X_test, gt_infra_classifier._y_test)
2025-11-24 10:43:09.079 | INFO     | classifiers.pixel_classifier:evaluate:137 - 

--- 📊 Classification Report ---

              precision    recall  f1-score   support

           0       0.69      0.66      0.68       600
           1       0.67      0.69      0.68       600
           2       0.51      0.53      0.52       600
           3       0.78      0.76      0.77       600

    accuracy                           0.66      2400
   macro avg       0.66      0.66      0.66      2400
weighted avg       0.66      0.66      0.66      2400

Code 
gt_infra_pred_roi_da = gt_infra_classifier.classify_roi(gt_embeddings_2024_da)
gt_infra_pred_roi_da = gt_infra_pred_roi_da.rio.write_crs(example.utm_crs)
gt_infra_pred_roi_da
2025-11-24 10:43:09.323 | INFO     | classifiers.pixel_classifier:classify_roi:148 - Classifying entire ROI

<xarray.DataArray 'predicted_class' (y: 1500, x: 2572)> Size: 31MB
array([[2, 2, 2, ..., 0, 0, 2],
       [2, 2, 2, ..., 0, 0, 2],
       [2, 2, 2, ..., 0, 0, 2],
       ...,
       [0, 0, 0, ..., 1, 1, 2],
       [0, 0, 0, ..., 1, 0, 2],
       [0, 0, 0, ..., 1, 2, 2]], shape=(1500, 2572))
Coordinates:
  * y            (y) float64 12kB 9.856e+06 9.856e+06 ... 9.841e+06 9.841e+06
  * x            (x) float64 21kB 2.494e+05 2.494e+05 ... 2.751e+05 2.751e+05
    spatial_ref  int64 8B 0
Code 
import matplotlib.cm as cm
# --- Your Setup Code ---
num_classes = 4
# Get the viridis colormap, sampled into num_classes discrete colors
viridis = plt.get_cmap('viridis', num_classes)
# Create a ListedColormap
discrete_cmap = ListedColormap([viridis(i) for i in range(num_classes)])

cmap = discrete_cmap
# Create boundaries for the discrete classes. 
# For classes 0, 1, 2, boundaries are -0.5, 0.5, 1.5, 2.5
boundaries = np.arange(num_classes + 1) - 0.5
# Create a BoundaryNorm to map data values to colors
norm = mcolors.BoundaryNorm(boundaries, cmap.N)

# --- Plotting ---

# Create the figure and axes
# We can use constrained_layout=True to help manage space
fig, axs = plt.subplots(1, 3, figsize=(14, 7), constrained_layout=True)

# Plot the OpenBuildings infrastructure band
overture_da.sel(band='overture').plot(
    ax=axs[0],
    alpha=0.7,
    cmap=cmap,       # Apply discrete cmap
    norm=norm,       # Apply discrete norm
    add_colorbar=False # --- KEY: Disable individual colorbar
)
# Plot the example_row geometry outline on top
# A boundary line usually has a single color
axs[0].set_title("Overture Data")
axs[0].set_xlabel(None)
axs[0].set_ylabel(None)


# Plot the ground truth data
gt_infra_pred_roi_da.plot(
    ax=axs[1],
    alpha=0.7,
    cmap=cmap,       # Apply discrete cmap
    norm=norm,       # Apply discrete norm
    add_colorbar=False # --- KEY: Disable individual colorbar
)
axs[1].set_title("Tessera Predictions (MLP)")
axs[1].set_xlabel(None)
axs[1].set_ylabel(None)

# Plot the ground truth data
ae_infra_pred_roi_da.plot(
    ax=axs[2],
    alpha=0.7,
    cmap=cmap,       # Apply discrete cmap
    norm=norm,       # Apply discrete norm
    add_colorbar=False # --- KEY: Disable individual colorbar
)
axs[2].set_title("AlphaEarth Predictions (MLP)")
axs[2].set_xlabel(None)
axs[2].set_ylabel(None)

# --- Create the single, discrete colorbar at the bottom ---

# 1. Create a ScalarMappable object to pass to the colorbar function
# This object links the colormap and normalization
sm = cm.ScalarMappable(cmap=cmap, norm=norm)
sm.set_array([]) # You can pass an empty array

# 2. Add the colorbar to the figure
# - orientation='horizontal' places it at the bottom
# - ax=axs places it relative to the axes array
# - shrink, pad, aspect are for styling
cbar = fig.colorbar(
    sm,
    ax=axs, # Use the array of axes
    orientation='horizontal',
    pad=0.1,    # Padding from the subplots
    shrink=0.7, # Make it 70% of the total width
    aspect=30   # Ratio of long to short side
)

# 3. Set discrete ticks and labels
# We want ticks to be in the *middle* of each class boundary
# For classes 0, 1, 2, the centers are 0, 1, 2
tick_locs = np.arange(num_classes)
cbar.set_ticks(tick_locs)
# You can set custom labels here if you want
cbar.set_ticklabels(['Natural/Non-Built-up', 'Buildings', 'Roads', 'Infrastructure'])
cbar.set_label("Infrastructure Class", fontsize=12)

# Show the plot
plt.show()

Code 
import branca.colormap as cm
import folium
# --- Colormap Setup (for Folium/Branca) ---
num_classes = 4
# Get the same discrete viridis colors from matplotlib
viridis = plt.get_cmap('viridis', num_classes)
# Get the hex codes, which branca understands
colors_hex = [mcolors.to_hex(viridis(i)) for i in range(num_classes)]

# Create the boundaries for classes 0, 1, 2
boundaries = np.arange(num_classes + 1) - 0.5
# Create a StepColormap for Branca
# This maps values in bins:
# [-0.5, 0.5] -> color 0
# [ 0.5, 1.5] -> color 1
# [ 1.5, 2.5] -> color 2
cmap_branca = cm.StepColormap(
    colors_hex,
    index=boundaries,
    vmin=boundaries[0],
    vmax=boundaries[-1],
    caption=f'Infrastructure Class (Discrete {num_classes}-class Viridis)'
)

bbox = example.bbox  # [min_lon, min_lat, max_lon, max_lat]
bounds = [[bbox[1], bbox[0]], [bbox[3], bbox[2]]]  # [[south, west], [north, east]]

# Center for the map
center = [(bbox[1] + bbox[3]) / 2, (bbox[0] + bbox[2]) / 2]

# --- Create the Folium Map ---
m = folium.Map(location=center, zoom_start=14, tiles="OpenStreetMap")

# --- Add Data Layers ---
# We use FeatureGroups to make the layers toggleable

# 1. Overture Data Layer
overture_group = folium.FeatureGroup(name='Overture Data', show=True).add_to(m)
folium.raster_layers.ImageOverlay(
    image=np.flipud(overture_da.sel(band='overture').values), # Pass the 2D numpy array
    bounds=bounds,
    opacity=0.7,
    colormap=cmap_branca, # Pass the branca colormap
).add_to(overture_group)

# 2. Ground Truth Layer
gt_group = folium.FeatureGroup(name='Tessera', show=False).add_to(m)
folium.raster_layers.ImageOverlay(
    image=np.flipud(gt_infra_pred_roi_da.values), # This array is already 2D
    bounds=bounds,
    opacity=0.7,
    colormap=cmap_branca
).add_to(gt_group)

# 3. AE Infra Prediction Layer
ae_group = folium.FeatureGroup(name='AlphaEarth', show=False).add_to(m)
folium.raster_layers.ImageOverlay(
    image=np.flipud(ae_infra_pred_roi_da.values), # This array is already 2D
    bounds=bounds,
    opacity=0.7,
    colormap=cmap_branca
).add_to(ae_group)

# --- Add the Colormap Legend and Layer Control ---
cmap_branca.add_to(m)
folium.LayerControl().add_to(m)
m
Make this Notebook Trusted to load map: File -> Trust Notebook
Code 
# Ensure the DataArray has proper dtype, integer values (for class IDs), and CRS before saving

# Convert to integer type (class IDs)
out_da = ae_infra_pred_roi_da.astype("uint8")

# Ensure the spatial_ref CRS attribute exists and is valid
if not out_da.rio.crs:
    # Try to set CRS from original source if missing
    out_da = out_da.rio.write_crs("EPSG:32629", inplace=False)  # Adjust to your actual UTM CRS

# Remove any singleton bands dimension (make 2D)
if "band" in out_da.dims and out_da.sizes["band"] == 1:
    out_da = out_da.squeeze("band", drop=True)

# Remove NaNs (replace with a nodata value)
nodata_value = 255
out_da = out_da.fillna(nodata_value)
out_da.rio.write_nodata(nodata_value, inplace=True)

out_da.rio.to_raster("ae_infra_pred_roi_da.tif")

Google Earth

Code 
collection = request_gee_image('COPERNICUS/S2_HARMONIZED', date='2024-11-05', date_end='2025-11-05', bbox=example.bbox).filter(ee.Filter.lt('CLOUDY_PIXEL_PERCENTAGE', 20))
composite = collection.median()
Code 
import geemap
# Visualization parameters for Sentinel-2 RGB
vis_params = {
    'bands': ['B4', 'B3', 'B2'],  # Red, Green, Blue
    'min': 0,
    'max': 3000,
    'gamma': 1.4
}

roi = ee.Geometry.Rectangle(example.bbox)

# Create a geemap interactive map, centered on the ROI
center = [(example.bbox[1] + example.bbox[3])/2, (example.bbox[0] + example.bbox[2])/2]
m = geemap.Map(center=center, zoom=9)
m.addLayer(composite, vis_params, 'Sentinel-2 RGB Composite')
m.addLayer(geemap.gdf_to_ee(example_row), {}, 'ROI')
m.addLayer(roi, {}, 'bbox')

m
Back to top ]]> phd quarto https://ancazugo.github.io/posts/2025-11-16-tessera_example.html Sun, 16 Nov 2025 00:00:00 GMT 2025-09-21 Weekly Notes Andrés C. Zúñiga-González https://ancazugo.github.io/posts/2025-09-21-weekly-notes.html

Intro

This is code-focused post of how I’m building this project for more reproducibility. Also, this is the first post made entirely with a Jupyter notebook (and on an iPad using codespaces 😅), so not too sure if it will render as expected.

So, as mentioned in last week’s post, I’ve been working on how to use geo foundation models (GeoFMs) to classify Local CLimate Zones (LCZ). I managed to structure this project nicely using xarray, dask, and geefrom the beginning. Currently, it is using two GeoFMs: Google’s AlphaEarth and Cambridge’s GeoTessera and as labels, it uses the Demuzere’s global map of LCZs (2018) and the classification made with OpenStreeMaps (OSM) data created by Geoclimate (present).

Code

Packages and Classes import

Code 
%load_ext autoreload
%autoreload 2
import sys

sys.path.append('../src')

from utils.paths import guppd_path, lcz_dir
from utils.constants import lcz_dict
from gee_helpers import authenticate_ee
from city import City
from classifiers.pixel_classifier import PixelClassifier
from embeddings.geotessera import GeoTesseraEmbeddings
from embeddings.alpha_earth import AlphaEarthEmbeddings
from lcz.demuzere import Demuzere
from lcz.geoclimate import Geoclimate
import numpy as np
import xarray as xr
import geopandas as gpd
import matplotlib.pyplot as plt
from matplotlib.colors import ListedColormap
import matplotlib.colors as mcolors

City boundaries setup

Code 
guppd_gdf = gpd.read_file(guppd_path, layer="urbanspatial_guppd_v1_polygons")
guppd_gdf.sort_values(by="GHSPOP_R23_2025", inplace=True)
# guppd_gdf = guppd_gdf[guppd_gdf["GHSPOP_R23_2025"] > 1e6]
guppd_gdf.reset_index(drop=True, inplace=True)
Code 
city_example_gdf = guppd_gdf[(guppd_gdf["ISO"] == "GBR") & (guppd_gdf["JRC_NAME_MAIN"] == "Cambridge")]
city_example = City(
    city=city_example_gdf["JRC_NAME_MAIN"].values[0],
    smod_id=city_example_gdf["SMOD_ID"].values[0],
    country_code=city_example_gdf["ISO"].values[0],
    bbox=city_example_gdf.total_bounds.tolist(), # minx, miny, maxx, maxy
)
city_example
City(city='Cambridge', smod_id='30_4732', country_code='GBR', bbox=[0.08131345500004272, 52.17205629800003, 0.18967890600004012, 52.249807786000076], climate_type='Cfb', utm_crs='EPSG:32631', utm_bbox=[300421.00688341603, 5784191.7236782815, 308164.895357511, 5792544.390988352])

Embeddings Setup

Because of the nature of how LCZs were obtained, I am using AlphaEarth and GeoTessera’s embeddings from 2018 and 2024, where available, to classify LCZs. THis step will either load files from .zarr files or extract the features from Google Earth Engine. In addition, because it is built on dask and xarray it is very easy to see the structure of the dataset (3-dimensional array). The code is capable of sorting the bounding box, resolution, and alignment of the datasets so they are compatible for pixel-level classification.

Code 
year = 2024
ae_2024 = AlphaEarthEmbeddings(city=city_example, year=year)
# authenticate_ee()
ae_embeddings_2024_da = ae_2024.get_embeddings()
ae_embeddings_2024_da
2025-09-19 13:42:38.365 | INFO     | embeddings.base:get_embeddings:46 - Loading cached 'AlphaEarth' embeddings from /maps/acz25/phd-thesis-data/input/Google/AlphaEarth/2024/GBR/30_4732_Cambridge_ae.zarr

2025-09-19 13:42:38.730 | INFO     | embeddings.base:get_embeddings:53 - Chunking 'AlphaEarth' embeddings

<xarray.DataArray (band: 64, y: 835, x: 774)> Size: 165MB
dask.array<rechunk-merge, shape=(64, 835, 774), dtype=float32, chunksize=(64, 512, 512), chunktype=numpy.ndarray>
Coordinates:
  * y        (y) float64 7kB 5.784e+06 5.784e+06 ... 5.793e+06 5.793e+06
  * x        (x) float64 6kB 3.004e+05 3.004e+05 ... 3.081e+05 3.082e+05
  * band     (band) object 512B 'A36' 'A04' 'A41' 'A60' ... 'A15' 'A34' 'A49'
Attributes:
    crs:      EPSG:32631
Code 
gt_2024 = GeoTesseraEmbeddings(city=city_example, year=year)
gt_embeddings_2024_da = gt_2024.get_embeddings()
gt_embeddings_2024_da
2025-09-19 13:42:38.809 | INFO     | embeddings.base:get_embeddings:46 - Loading cached 'GeoTessera' embeddings from /maps/acz25/phd-thesis-data/input/GEOTESSERA/clipped/2024/GBR/30_4732_Cambridge.zarr

2025-09-19 13:42:38.895 | INFO     | embeddings.base:get_embeddings:53 - Chunking 'GeoTessera' embeddings

<xarray.DataArray (band: 128, y: 836, x: 775)> Size: 332MB
dask.array<rechunk-merge, shape=(128, 836, 775), dtype=float32, chunksize=(128, 512, 512), chunktype=numpy.ndarray>
Coordinates:
  * x            (x) float64 6kB 3.004e+05 3.004e+05 ... 3.082e+05 3.082e+05
    spatial_ref  int64 8B ...
  * y            (y) float64 7kB 5.793e+06 5.793e+06 ... 5.784e+06 5.784e+06
  * band         (band) object 1kB 'A049' 'A034' 'A043' ... 'A073' 'A097' 'A103'
Attributes:
    AREA_OR_POINT:  Area
    scale_factor:   1.0
    add_offset:     0.0
Code 
year = 2018
ae_2018 = AlphaEarthEmbeddings(city=city_example, year=year)
# authenticate_ee()
ae_embeddings_2018_da = ae_2018.get_embeddings()
ae_embeddings_2018_da
2025-09-19 13:42:38.956 | INFO     | embeddings.base:get_embeddings:46 - Loading cached 'AlphaEarth' embeddings from /maps/acz25/phd-thesis-data/input/Google/AlphaEarth/2018/GBR/30_4732_Cambridge_ae.zarr

2025-09-19 13:42:39.367 | INFO     | embeddings.base:get_embeddings:53 - Chunking 'AlphaEarth' embeddings

<xarray.DataArray (band: 64, y: 835, x: 774)> Size: 165MB
dask.array<rechunk-merge, shape=(64, 835, 774), dtype=float32, chunksize=(64, 512, 512), chunktype=numpy.ndarray>
Coordinates:
  * y        (y) float64 7kB 5.784e+06 5.784e+06 ... 5.793e+06 5.793e+06
  * x        (x) float64 6kB 3.004e+05 3.004e+05 ... 3.081e+05 3.082e+05
  * band     (band) object 512B 'A22' 'A46' 'A55' 'A04' ... 'A18' 'A12' 'A20'
Attributes:
    crs:      EPSG:32631
Code 
gt_2018 = GeoTesseraEmbeddings(city=city_example, year=year)
gt_embeddings_2018_da = gt_2018.get_embeddings()
gt_embeddings_2018_da
2025-09-19 13:42:39.438 | INFO     | embeddings.base:get_embeddings:46 - Loading cached 'GeoTessera' embeddings from /maps/acz25/phd-thesis-data/input/GEOTESSERA/clipped/2018/GBR/30_4732_Cambridge.zarr

2025-09-19 13:42:39.525 | INFO     | embeddings.base:get_embeddings:53 - Chunking 'GeoTessera' embeddings

<xarray.DataArray (band: 128, y: 836, x: 775)> Size: 332MB
dask.array<rechunk-merge, shape=(128, 836, 775), dtype=float32, chunksize=(128, 512, 512), chunktype=numpy.ndarray>
Coordinates:
  * x            (x) float64 6kB 3.004e+05 3.004e+05 ... 3.082e+05 3.082e+05
    spatial_ref  int64 8B ...
  * y            (y) float64 7kB 5.793e+06 5.793e+06 ... 5.784e+06 5.784e+06
  * band         (band) object 1kB 'A066' 'A088' 'A011' ... 'A080' 'A021' 'A126'
Attributes:
    AREA_OR_POINT:  Area
    scale_factor:   1.0
    add_offset:     0.0

LCZs Setup

Behind the scenes, Geoclimate was already executed to extract the LCZ labels for the city bounding box. If it doesn’t exist, it will generate it but this step can take a while depending on the size of the city (e.g. ~15 hours for a London-sized area). On the other hand, the Demuzere dataset is directly extracted from Google Earth Engine and it does it quite fast regardless of ROI size.

Code 
gc = Geoclimate(workflow="OSM", city=city_example)
gc_lcz_da = gc.get_lcz()
gc_lcz_da
2025-09-19 13:42:39.587 | INFO     | lcz.base:get_lcz:36 - Loading cached 'Geoclimate' LCZ from /maps/acz25/phd-thesis-data/output/lcz_classification/geoclimate/GBR/30_4732_Cambridge/30_4732_Cambridge_geoclimate.zarr

2025-09-19 13:42:39.603 | INFO     | lcz.base:get_lcz:43 - Chunking 'Geoclimate' LCZ

<xarray.DataArray (band: 3, y: 900, x: 780)> Size: 8MB
dask.array<rechunk-merge, shape=(3, 900, 780), dtype=float32, chunksize=(3, 512, 512), chunktype=numpy.ndarray>
Coordinates:
  * y            (y) float64 7kB 5.793e+06 5.793e+06 ... 5.784e+06 5.784e+06
  * x            (x) float64 6kB 3.004e+05 3.004e+05 ... 3.082e+05 3.082e+05
    spatial_ref  int64 8B ...
  * band         (band) object 24B 'SVF' 'ASPECT_RATIO' 'LCZ_PRIMARY'
Code 
dz = Demuzere(city=city_example)
# authenticate_ee()
dz_lcz_da = dz.get_lcz()
dz_lcz_da
2025-09-19 13:42:39.656 | INFO     | lcz.base:get_lcz:36 - Loading cached 'Demuzere' LCZ from /maps/acz25/phd-thesis-data/input/LCZ/GBR/30_4732_Cambridge_demuzere.zarr

2025-09-19 13:42:39.668 | INFO     | lcz.base:get_lcz:43 - Chunking 'Demuzere' LCZ

<xarray.DataArray (band: 3, y: 835, x: 774)> Size: 8MB
dask.array<rechunk-merge, shape=(3, 835, 774), dtype=float32, chunksize=(3, 512, 512), chunktype=numpy.ndarray>
Coordinates:
  * y        (y) float64 7kB 5.784e+06 5.784e+06 ... 5.793e+06 5.793e+06
  * x        (x) float64 6kB 3.004e+05 3.004e+05 ... 3.081e+05 3.082e+05
  * band     (band) object 24B 'LCZ_Probability' 'LCZ' 'LCZ_Filter'
Attributes:
    max_mirrored_version:  1696930913272071
    crs:                   EPSG:32631

Pixel Classifier

Another class for the actual ML model takes as inputs the embeddings, the labels, a number of sampling points per class, and an optional dictionary that maps the 17 LCZs to reduce the number of labels, if necessary. In addition to this, the class receives an sklearn.classifier object as attribute that will inherit all the necessary methods to train (in this case, a Random Forest model).

Code 
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import ConfusionMatrixDisplay
# Built vs Natural
new_class_dict = {1: 1, 2: 1, 3: 1, 4: 1, 5: 1, 
                  6: 1, 7: 1, 8: 1, 9: 1, 10: 1, 
                  11: 2, 12: 2, 13: 2, 14: 2, 
                  15: 2, 16: 2, 17: 2}
# Urban vs Rural vs Natural
new_class_dict = {1: 1, 2: 1, 3: 1, 4: 3, 5: 3, 
                  6: 3, 7: 3, 8: 1, 9: 3, 10: 1, 
                  11: 2, 12: 2, 13: 2, 14: 2, 
                  15: 2, 16: 2, 17: 2}
rf_classifier = RandomForestClassifier(n_estimators=100, random_state=411)

Predicting Demuzere’s LCZ classes (2018)

AlphaEarth

Without finetuning, AlphaEarth seems to be performing better than GeoTessera, but there is a big caveat here: Demuzere’s dataset was created using pretty much the same list of datasets that were used to train AlphaEarth so the results are not surprising. What is surprising is the performance of GeoTessera with just Sentinel 1 and 2 data. The scores and metrics presented here are on the test dataset.

Code 
%time
ae_dz_classifier = PixelClassifier()
X, y, coords, labels_da = ae_dz_classifier.prepare_data(dz_lcz_da, ae_embeddings_2018_da, "LCZ_Filter", 2000)
ae_dz_classifier._classifier = rf_classifier
ae_dz_classifier.train()
2025-09-19 13:42:39.895 | INFO     | classifiers.pixel_classifier:prepare_data:103 - Preparing data for band LCZ_Filter

2025-09-19 13:42:40.076 | INFO     | classifiers.pixel_classifier:_sample_classes:26 - Sampling classes for band LCZ_Filter

CPU times: user 3 μs, sys: 2 μs, total: 5 μs
Wall time: 11.4 μs
2025-09-19 13:42:40.139 | INFO     | classifiers.pixel_classifier:_extract_embeddings:55 - Extracting embeddings for 20250 coordinates

2025-09-19 13:42:57.288 | INFO     | classifiers.pixel_classifier:train:141 - ✅ Model training complete.

RandomForestClassifier(random_state=411)
In a Jupyter environment, please rerun this cell to show the HTML representation or trust the notebook.
On GitHub, the HTML representation is unable to render, please try loading this page with nbviewer.org.
Code 
y_ae_dz_test_pred = ae_dz_classifier.evaluate()
ConfusionMatrixDisplay.from_estimator(ae_dz_classifier._classifier, ae_dz_classifier._X_test, ae_dz_classifier._y_test)
2025-09-19 13:42:57.355 | INFO     | classifiers.pixel_classifier:evaluate:149 - 

--- 📊 Classification Report ---

              precision    recall  f1-score   support

           2       0.85      0.92      0.89       600
           3       0.97      0.95      0.96       129
           4       0.73      0.77      0.75       600
           5       0.72      0.64      0.68       600
           6       0.71      0.69      0.70       600
           8       0.75      0.61      0.67       600
           9       0.78      0.92      0.84       600
          11       0.90      0.92      0.91       600
          12       0.72      0.71      0.71       600
          14       0.91      0.87      0.89       600
          17       0.95      0.98      0.97       546

    accuracy                           0.81      6075
   macro avg       0.82      0.82      0.81      6075
weighted avg       0.80      0.81      0.80      6075

Code 
ae_dz_pred_roi_da = ae_dz_classifier.classify_roi(ae_embeddings_2018_da)
ae_dz_pred_roi_da
2025-09-19 13:42:57.927 | INFO     | classifiers.pixel_classifier:classify_roi:158 - Classifying entire ROI

<xarray.DataArray 'predicted_class' (y: 835, x: 774)> Size: 5MB
array([[14, 14, 14, ..., 14, 14, 14],
       [14, 14, 14, ..., 14, 14, 14],
       [14, 14, 14, ..., 14, 14, 14],
       ...,
       [14, 12, 12, ..., 14, 14, 14],
       [12, 12, 12, ..., 14, 14, 14],
       [14, 12, 12, ..., 14, 14, 14]], shape=(835, 774))
Coordinates:
  * y        (y) float64 7kB 5.784e+06 5.784e+06 ... 5.793e+06 5.793e+06
  * x        (x) float64 6kB 3.004e+05 3.004e+05 ... 3.081e+05 3.082e+05

GeoTessera

Code 
%time
gt_dz_classifier = PixelClassifier()
X, y, coords, labels_da = gt_dz_classifier.prepare_data(dz_lcz_da, gt_embeddings_2018_da, "LCZ_Filter", 2000)
gt_dz_classifier._classifier = rf_classifier
gt_dz_classifier.train()
2025-09-19 13:44:45.130 | INFO     | classifiers.pixel_classifier:prepare_data:103 - Preparing data for band LCZ_Filter

2025-09-19 13:44:45.215 | INFO     | classifiers.pixel_classifier:_sample_classes:26 - Sampling classes for band LCZ_Filter

2025-09-19 13:44:45.276 | INFO     | classifiers.pixel_classifier:_extract_embeddings:55 - Extracting embeddings for 20250 coordinates

CPU times: user 0 ns, sys: 12 μs, total: 12 μs
Wall time: 27.2 μs
2025-09-19 13:45:16.710 | INFO     | classifiers.pixel_classifier:train:141 - ✅ Model training complete.

RandomForestClassifier(random_state=411)
In a Jupyter environment, please rerun this cell to show the HTML representation or trust the notebook.
On GitHub, the HTML representation is unable to render, please try loading this page with nbviewer.org.
Code 
y_gt_dz_test_pred = gt_dz_classifier.evaluate()
ConfusionMatrixDisplay.from_estimator(gt_dz_classifier._classifier, gt_dz_classifier._X_test, gt_dz_classifier._y_test)
2025-09-19 13:45:16.771 | INFO     | classifiers.pixel_classifier:evaluate:149 - 

--- 📊 Classification Report ---

              precision    recall  f1-score   support

           2       0.62      0.75      0.68       600
           3       0.84      0.33      0.47       129
           4       0.49      0.42      0.45       600
           5       0.42      0.40      0.41       600
           6       0.42      0.51      0.46       600
           8       0.53      0.40      0.46       600
           9       0.53      0.55      0.54       600
          11       0.62      0.73      0.67       600
          12       0.54      0.58      0.56       600
          14       0.87      0.77      0.82       600
          17       0.90      0.90      0.90       546

    accuracy                           0.59      6075
   macro avg       0.62      0.57      0.58      6075
weighted avg       0.60      0.59      0.59      6075

Code 
gt_dz_pred_roi_da = gt_dz_classifier.classify_roi(gt_embeddings_2018_da)
gt_dz_pred_roi_da
2025-09-19 13:45:17.362 | INFO     | classifiers.pixel_classifier:classify_roi:158 - Classifying entire ROI

<xarray.DataArray 'predicted_class' (y: 836, x: 775)> Size: 5MB
array([[12, 12, 12, ..., 14, 14, 14],
       [12, 12, 12, ..., 12, 14, 12],
       [12, 12, 12, ..., 12, 12, 12],
       ...,
       [14, 14, 14, ..., 14, 14, 14],
       [12, 14, 14, ..., 14, 14, 14],
       [14, 14, 14, ..., 14, 14, 14]], shape=(836, 775))
Coordinates:
  * y        (y) float64 7kB 5.793e+06 5.793e+06 ... 5.784e+06 5.784e+06
  * x        (x) float64 6kB 3.004e+05 3.004e+05 ... 3.082e+05 3.082e+05

Predicting Geoclimate’s LCZ classes (2024)

AlphaEarth

Unlike Demuzere’s global data, Geoclimate is using the data available in OSM to classify patches of land in one of the 17 categories. This means that LCZs are only of the present day, and rely on the quality of OSM data, which as many folks know, it varies significantly from country to country (or by city, in this case). In this case, AlphaEarth outperforms GeoTessera as well, although both of them tend to make the same missclassifications (LCZ 4). Not really sure why, but the power of using Geoclimate as label is in the fact that it includes more information about built-up areas like roads or new buildings that are not present in Demuzere’s dataset.

Code 
%time
ae_gc_classifier = PixelClassifier()
X, y, coords, labels_da = ae_gc_classifier.prepare_data(gc_lcz_da, ae_embeddings_2024_da, "LCZ_PRIMARY", 2000)
ae_gc_classifier._classifier = rf_classifier
ae_gc_classifier.train()
2025-09-19 13:57:19.761 | INFO     | classifiers.pixel_classifier:prepare_data:103 - Preparing data for band LCZ_PRIMARY

2025-09-19 13:57:19.862 | INFO     | classifiers.pixel_classifier:_sample_classes:26 - Sampling classes for band LCZ_PRIMARY

2025-09-19 13:57:19.924 | INFO     | classifiers.pixel_classifier:_extract_embeddings:55 - Extracting embeddings for 20110 coordinates

CPU times: user 1e+03 ns, sys: 12 μs, total: 13 μs
Wall time: 27.7 μs
2025-09-19 13:57:36.202 | INFO     | classifiers.pixel_classifier:train:141 - ✅ Model training complete.

RandomForestClassifier(random_state=411)
In a Jupyter environment, please rerun this cell to show the HTML representation or trust the notebook.
On GitHub, the HTML representation is unable to render, please try loading this page with nbviewer.org.
Code 
y_ae_gc_test_pred = ae_gc_classifier.evaluate()
ConfusionMatrixDisplay.from_estimator(ae_gc_classifier._classifier, ae_gc_classifier._X_test, ae_gc_classifier._y_test)
2025-09-19 13:57:36.257 | INFO     | classifiers.pixel_classifier:evaluate:149 - 

--- 📊 Classification Report ---

              precision    recall  f1-score   support

           2       0.73      0.87      0.79       600
           4       0.91      0.97      0.94        33
           5       0.74      0.72      0.73       600
           6       0.49      0.41      0.45       600
           8       0.65      0.73      0.69       600
           9       0.50      0.52      0.51       600
          11       0.70      0.82      0.76       600
          12       0.73      0.76      0.74       600
          14       0.84      0.68      0.75       600
          15       0.58      0.46      0.51       600
          17       0.95      0.95      0.95       600

    accuracy                           0.69      6033
   macro avg       0.71      0.72      0.71      6033
weighted avg       0.69      0.69      0.69      6033

Code 
ae_gc_pred_roi_da = ae_gc_classifier.classify_roi(ae_embeddings_2024_da)
ae_gc_pred_roi_da
2025-09-19 13:57:36.841 | INFO     | classifiers.pixel_classifier:classify_roi:158 - Classifying entire ROI

<xarray.DataArray 'predicted_class' (y: 835, x: 774)> Size: 5MB
array([[14, 14, 12, ..., 14, 14, 14],
       [14, 12, 12, ..., 14, 14, 14],
       [12, 12, 12, ..., 14, 14, 14],
       ...,
       [14, 14, 15, ..., 14, 14, 14],
       [14, 14, 15, ..., 14, 14, 14],
       [14, 14, 14, ..., 14, 14, 14]], shape=(835, 774))
Coordinates:
  * y        (y) float64 7kB 5.784e+06 5.784e+06 ... 5.793e+06 5.793e+06
  * x        (x) float64 6kB 3.004e+05 3.004e+05 ... 3.081e+05 3.082e+05

GeoTessera

Code 
%time
gt_gc_classifier = PixelClassifier()
X, y, coords, labels_da = gt_gc_classifier.prepare_data(gc_lcz_da, gt_embeddings_2024_da, "LCZ_PRIMARY", 2000)
gt_gc_classifier._classifier = rf_classifier
gt_gc_classifier.train()
2025-09-19 13:59:10.557 | INFO     | classifiers.pixel_classifier:prepare_data:103 - Preparing data for band LCZ_PRIMARY

2025-09-19 13:59:10.638 | INFO     | classifiers.pixel_classifier:_sample_classes:26 - Sampling classes for band LCZ_PRIMARY

2025-09-19 13:59:10.715 | INFO     | classifiers.pixel_classifier:_extract_embeddings:55 - Extracting embeddings for 20100 coordinates

CPU times: user 1 μs, sys: 11 μs, total: 12 μs
Wall time: 23.8 μs
2025-09-19 13:59:48.400 | INFO     | classifiers.pixel_classifier:train:141 - ✅ Model training complete.

RandomForestClassifier(random_state=411)
In a Jupyter environment, please rerun this cell to show the HTML representation or trust the notebook.
On GitHub, the HTML representation is unable to render, please try loading this page with nbviewer.org.
Code 
y_gt_gc_test_pred = gt_gc_classifier.evaluate()
ConfusionMatrixDisplay.from_estimator(gt_gc_classifier._classifier, gt_gc_classifier._X_test, gt_gc_classifier._y_test)
2025-09-19 13:59:48.445 | INFO     | classifiers.pixel_classifier:evaluate:149 - 

--- 📊 Classification Report ---

              precision    recall  f1-score   support

           2       0.49      0.61      0.55       600
           4       0.78      0.23      0.36        30
           5       0.44      0.27      0.33       600
           6       0.28      0.30      0.29       600
           8       0.49      0.50      0.49       600
           9       0.31      0.39      0.34       600
          11       0.49      0.64      0.55       600
          12       0.43      0.41      0.42       600
          14       0.69      0.66      0.68       600
          15       0.44      0.33      0.38       600
          17       0.87      0.76      0.81       600

    accuracy                           0.48      6030
   macro avg       0.52      0.46      0.47      6030
weighted avg       0.49      0.48      0.48      6030

Code 
gt_gc_pred_roi_da = gt_gc_classifier.classify_roi(gt_embeddings_2024_da)
gt_gc_pred_roi_da
2025-09-19 13:59:48.981 | INFO     | classifiers.pixel_classifier:classify_roi:158 - Classifying entire ROI

<xarray.DataArray 'predicted_class' (y: 836, x: 775)> Size: 5MB
array([[14, 14, 14, ..., 14, 14, 14],
       [14, 14, 14, ..., 14, 14, 14],
       [14, 14, 14, ..., 14, 12, 12],
       ...,
       [14, 14, 14, ..., 14, 14, 14],
       [14, 14, 14, ..., 14, 14, 14],
       [14, 14, 14, ..., 14, 14, 14]], shape=(836, 775))
Coordinates:
  * y        (y) float64 7kB 5.793e+06 5.793e+06 ... 5.784e+06 5.784e+06
  * x        (x) float64 6kB 3.004e+05 3.004e+05 ... 3.082e+05 3.082e+05

Conclusions

So, in general both AlphaEarth and GeoTessera are more than capable of classifying LCZs with Google’s model performing slightly better. This is only a test using Cambridge as test study, so more experiments and fine-tuning are necessary. Clear improvements on the current state of LCZs are clear: Because of the resolution of the embeddings, they are picking up features at finer detail like roads or rivers that are not present in the labels; this means that although they are misclassified, they are actually correctly classified by the models (it’s easier to see in the interactive map). You can see below a plot comparing the different embeddings and labels, and an additional interactive plot for an overlay on an OSM basemap. I’m more interested in how it performs in not so common places in Africa, Asia or Latin America, as the lack of data in OSM maps means that many attributes like building height are missing, which could mean that either AlphaEarth or GeoTessera can fill in the gap with the satellite data they were trained on.

Currently, I’m training a couple of models on Cambridge, London and Bogotá using a MLP classifier, as suggested by Frank Feng. To fine-tune the model, and more importantly, to track the results and performance I am implementing a Weights & Biases Sweep configuration so I can use the dashboard to make better informed decisions on where to go from there.

Code 
# 1. Get all unique values from the data.
# raw_unique_values = np.unique(np.concatenate([
#     labels_da.sel(band='LCZ_Filter').values.ravel(),
#     gt_pred_roi_da.values.ravel()
# ]))
raw_unique_values = np.unique(np.concatenate([
    dz_lcz_da.sel(band='LCZ_Filter').values.ravel(),
    gt_dz_pred_roi_da.values.ravel(),
    ae_dz_pred_roi_da.values.ravel(),
    gc_lcz_da.sel(band='LCZ_PRIMARY').values.ravel(),
    gt_gc_pred_roi_da.values.ravel(),
    ae_gc_pred_roi_da.values.ravel()
]))
# 2. Create a clean array for logic and ticks by filtering out NaN.
colorbar_ticks = raw_unique_values[~np.isnan(raw_unique_values)]

# 3. Handle the edge case where there is no valid data to plot.
if len(colorbar_ticks) == 0:
    print("⚠️ Warning: Data contains only NaN values. Cannot generate plot with colorbar.")
    # Draw blank plots as a fallback
    fig, axes = plt.subplots(1, 2, figsize=(14, 7))
    axes[0].set_title("LCZ (Demuzere, 2022)\n(No data)")
    axes[1].set_title("Predicted LCZ (RF - GeoTessera)\n(No data)")
    plt.show()

else:
    # 4. Use the clean ticks to decide on the colormap.
    if colorbar_ticks.max() <= 2:
        print("Detected reclassified data. Using 'viridis' colormap. 🎨")
        num_classes = len(colorbar_ticks)
        cmap = plt.get_cmap('viridis', num_classes)
        boundaries = np.append(colorbar_ticks - 0.5, colorbar_ticks[-1] + 0.5)
        norm = mcolors.BoundaryNorm(boundaries, cmap.N)
    else:
        print("Detected original LCZ data. Using custom LCZ colormap. 🗺️")
        lcz_colors = [x['color'] for x in lcz_dict.values()]
        lcz_keys = list(lcz_dict.keys())
        cmap = ListedColormap(lcz_colors)
        boundaries = np.arange(min(lcz_keys) - 0.5, max(lcz_keys) + 1.6, 1)
        norm = mcolors.BoundaryNorm(boundaries, cmap.N+1)

    # 5. IMPORTANT: Tell the colormap how to render NaN values from the data.
    cmap.set_bad(color='white', alpha=0) # Make bad values (like NaN) fully transparent

    # --- Plotting ---
    fig, axes = plt.subplots(2, 3, figsize=(15, 12))

    im0 = dz_lcz_da.sel(band='LCZ_Filter').plot(ax=axes[0][0], add_colorbar=False, cmap=cmap, norm=norm)
    axes[0][0].set_title("LCZ (Demuzere)")

    im1 = gt_dz_pred_roi_da.plot(ax=axes[0][1], add_colorbar=False, cmap=cmap, norm=norm)
    axes[0][1].set_title("Predicted LCZ (RF - GeoTessera (2018))")
    im2 = ae_dz_pred_roi_da.plot(ax=axes[0][2], add_colorbar=False, cmap=cmap, norm=norm)
    axes[0][2].set_title("Predicted LCZ (RF - AlphaEarth (2018))")

    im3 = gc_lcz_da.sel(band='LCZ_PRIMARY').plot(ax=axes[1][0], add_colorbar=False, cmap=cmap, norm=norm)
    axes[1][0].set_title("LCZ (Geoclimate)")

    im4 = gt_gc_pred_roi_da.plot(ax=axes[1][1], add_colorbar=False, cmap=cmap, norm=norm)
    axes[1][1].set_title("Predicted LCZ (RF - GeoTessera (2024))")

    im5 = ae_gc_pred_roi_da.plot(ax=axes[1][2], add_colorbar=False, cmap=cmap, norm=norm)
    axes[1][2].set_title("Predicted LCZ (RF - AlphaEarth (2024))")

    # --- Layout and Colorbar ---
    axes[0][0].set_xlabel('')
    axes[0][0].set_ylabel('')
    axes[0][1].set_xlabel('')
    axes[0][1].set_ylabel('')
    axes[0][2].set_xlabel('')
    axes[0][2].set_ylabel('')
    axes[1][0].set_xlabel('')
    axes[1][0].set_ylabel('')
    axes[1][1].set_xlabel('')
    axes[1][1].set_ylabel('')
    axes[1][2].set_xlabel('')
    axes[1][2].set_ylabel('')
    fig.subplots_adjust(bottom=0.2, top=0.9)

    cbar = fig.colorbar(im1, ax=axes.ravel().tolist(), orientation='horizontal',
                        ticks=colorbar_ticks, shrink=0.8, aspect=35, pad=0.1)
    cbar.set_label('LCZ Class')

    plt.show()
Detected original LCZ data. Using custom LCZ colormap. 🗺️

Code 
import folium
import numpy as np
import matplotlib
import matplotlib.pyplot as plt
import tempfile
import os
from folium.raster_layers import ImageOverlay

def add_overlay_to_map(fmap, da, ax_title, cmap, norm, bounds, opacity=0.6):
    """
    Plots a DataArray as an image overlay on a folium map.
    """
    # Plot to a temporary PNG file
    with tempfile.NamedTemporaryFile(suffix='.png', delete=False) as tmpfile:
        fig, ax = plt.subplots(figsize=(6, 6))
        # Remove axis
        ax.axis('off')
        # Plot the data
        im = da.plot.imshow(ax=ax, cmap=cmap, norm=norm, add_colorbar=False)
        plt.tight_layout(pad=0)
        plt.savefig(tmpfile.name, bbox_inches='tight', pad_inches=0, transparent=True)
        plt.close(fig)
        img_path = tmpfile.name

    # Overlay on folium
    img_overlay = folium.raster_layers.ImageOverlay(
        name=ax_title,
        image=img_path,
        bounds=bounds,
        opacity=opacity,
        interactive=True,
        cross_origin=False,
        zindex=1,
    )
    img_overlay.add_to(fmap)

    # Remove the temp file after folium loads it
    os.remove(img_path)

# --- Get bounds for folium (in lat/lon) ---
# We'll use the city.bbox for the Cambridge example
# bbox = [min_lon, min_lat, max_lon, max_lat]
bbox = city_example.bbox  # [min_lon, min_lat, max_lon, max_lat]
bounds = [[bbox[1], bbox[0]], [bbox[3], bbox[2]]]  # [[south, west], [north, east]]

# Center for the map
center = [(bbox[1] + bbox[3]) / 2, (bbox[0] + bbox[2]) / 2]

# --- Prepare the six DataArrays to overlay ---
# Each should be 2D (y, x) and correspond to the correct region
# 1. Demuzere LCZ
dz_lcz_img = dz_lcz_da.sel(band='LCZ_Filter')
# 2. Predicted LCZ (RF - GeoTessera)
gt_dz_pred_img = gt_dz_pred_roi_da
# 3. Predicted LCZ (RF - AlphaEarth)
ae_dz_pred_img = ae_dz_pred_roi_da
# 4. Geoclimate LCZ
gc_lcz_img = gc_lcz_da.sel(band='LCZ_PRIMARY')
# 5. Predicted LCZ (RF - GeoTessera, Geoclimate)
gt_gc_pred_img = gt_gc_pred_roi_da
# 6. Predicted LCZ (RF - AlphaEarth, Geoclimate)
ae_gc_pred_img = ae_gc_pred_roi_da

# --- Create a folium map ---
fmap = folium.Map(location=center, zoom_start=13, tiles='cartodbpositron')

# --- Overlay each plot ---
add_overlay_to_map(fmap, dz_lcz_img, "LCZ (Demuzere)", cmap, norm, bounds)
add_overlay_to_map(fmap, gt_dz_pred_img, "Predicted LCZ (RF - GeoTessera, Demuzere)", cmap, norm, bounds)
add_overlay_to_map(fmap, ae_dz_pred_img, "Predicted LCZ (RF - AlphaEarth, Demuzere)", cmap, norm, bounds)
add_overlay_to_map(fmap, gc_lcz_img, "LCZ (Geoclimate)", cmap, norm, bounds)
add_overlay_to_map(fmap, gt_gc_pred_img, "Predicted LCZ (RF - GeoTessera, Geoclimate)", cmap, norm, bounds)
add_overlay_to_map(fmap, ae_gc_pred_img, "Predicted LCZ (RF - AlphaEarth, Geoclimate)", cmap, norm, bounds)

# Add layer control
folium.LayerControl().add_to(fmap)

# Display the map in the notebook
fmap
Make this Notebook Trusted to load map: File -> Trust Notebook

Objectives

Last Week

  • Fix the rasterisation bug from Geoclimate using the projection of the FM embeddings (AlphaEarth or TESSERA)
    • Test the pixel classifier with the Geoclimate labels
  • Test other cities with the pixel classifier
  • Experiment with other models or try with cross validation to improve the performance

This Week

  • Start preparing the talk for PROPL25 and Imperial College talk
  • Add customised plots to Wandb dashboard
Back to top ]]> phd quarto https://ancazugo.github.io/posts/2025-09-21-weekly-notes.html Sun, 21 Sep 2025 00:00:00 GMT 2025-09-14 Weekly Notes Andrés C. Zúñiga-González https://ancazugo.github.io/posts/2025-09-14-weekly-notes.html

Intro

As mentioned in previous posts, for the second big project of my PhD I want to use Geo Foundation Models (GeoFMs) to (re)classify urban areas into Local Climate Zones (LCZs). I’ve been working on this for the last two weeks and I’ve made some progress.

LCZ Classification

Geoclimate

The running of Geoclimate has caused some issues with /tmp directory being full and usage of memory in kinabalu, for which I har to reduce the number of parallel operations from 8 to 2. This has taken way longer than expected for such a small number of cities (515). I’m only missing around 15 of the largest cities in the world, mostly located in Asia. However, with some early inspection of the output of Geoclimate, I found several problems with the classification of grids, likely due to lack of details in OSM data to obtain fabric and building height, which the algorithm uses to determine, for instance, between a high-rise and low-rise area. I haven’t inspected all the outputs yet but I suspect that this problem will be more common in Asia, Africa and Latin America. Moreover, the output of the model is a vector file that needs to be rasterised but I stumbled upon a bug with rasterio that I’m trying to fix. Essentially when rasterising, it is not picking the value of the classification and it is creating a 2D array of 0s.

Global LCZ Map

Due to the setback with Geoclimate, I decided to use the Global LCZ Map from Demuzere et al., 2022, which is a raster file with the LCZ classification for the entire world for 2018. However, instead of accessing the whole raster from memory, I decided to rely on GEE and the xarray extension for it called xee. This allows me to access the raster as an xarray object and manipulate the multiple dimensions as one would normally do it with a tif or netcdf file. In addition, it can be optimised using Dask, which is a library for parallel computing with arrays.

Project Structure

Because I was dealing with multiple datasets, I decied to spend a good chunk of time on standardising the data structures for the different GeoFMs and the LCZ datasets. The basis of the project is a City object that contains the basic information from the ´GUPPD´ dataset, plus the bounding box in EPSG:4326 and the Koppen-Geiger Climate Zone. It will also automatically calculate the coordinates of the bounding box in UTM for the given object, which is essential for xee and useful for aligning the LCZ labels with the GeoFM embeddings.

Then there is a superclass called GeoFM that is the basis for the GeoTessera and the AlphaEarth classes. These classes contain the methods to download the tiles for the embeddings that overlap the bounding box of the city. All these processes are done while handling the data as xarray.DataArray objects, which I found to be easier to work with than as regular numpy.ndarrays, due to the spatial capabilities of the library (particularly rioxarray). Combining it with dask allows for chunking the data and understanding the data structure (see image below), which could come in handy if time was a variable (e.g. using embeddings from different years).

In the case of GeoTessera, the geotessera library downloads the tiles in tif format, but I decided to clip them using the bounding box from the City object. Initially, I thought it was easy to implement the clipping method but it was not as intuitive as the arrays cannot be concatenated but merged. Merging takes longer but it handles the correct positioning of the tiles, while keeping the dimensions of the array. I am also experimenting with writing the embeddings as zarr files which is a new format for raster data that is supposed to be more efficient for cloud-based datasets; it definitely uses less space than regular tifs and they load faster using xarray/dask. However, this clipping step is the longest part of the process and it depends on the size of the arrays, so I would expect bigger cities like London or Tokyo to take up to an hour to process.

Array structure of the GeoTessera embeddings for Cambridge

Pixel Classifier

Finally, as Anil suggested I implemented a pixel classifier, based on the geotessera-interactive tutorials. But this time is using xarray methods to sample the pixels from a given city to keep the classes balanced. The PixelClassifier object receives an sklearn classifier as an attribute and fits the model as one would normally do it. As of now, I have only tested with Random Forest and K-Nearest Neighbours, but it looks promising.

There are 17 classes in total, but the cities that I have worked with (Cambridge and Bogotá) don’t have all of them. Initially what I did was to re-classify the pixels in Built-up (LCZ1-10) vs Natural (LCZ11-17) areas, and it worked pretty well, particularly because the resolution of the GeoFM embeddings is 10x10 m and the LCZs are 100x100 m, so I get more detail in the predictions. I also tried with 3, 4, and 5 classes and both GeoTessera and AlphaEarth worked pretty well. However, it is worth noting that AlphaEarth was trained with many of the datasets that were used to create the LCZ from Demuzere et al., 2022. The image below shows the comparison in the classification of all LCZs for Cambridge in 2018 using GeoTessera (acc=0.59) and AlphaEarth (acc=0.8) using a Random Forest model with 2000 points for training.

Comparison of the LCZ classification for Cambridge in 2018 using GeoTessera and AlphaEarth

Objectives

Past Weeks

  • Figure out what the most efficient way to get the embeddings from TESSERA is
  • Resample the embeddings to the same resolution as the LCZ classification from Geoclimate (100x100m)
  • Define the model to be used for the classification

This Week

  • Fix the rasterisation bug from Geoclimate using the projection of the FM embeddings (AlphaEarth or TESSERA)
    • Test the pixel classifier with the Geoclimate labels
  • Test other cities with the pixel classifier
  • Experiment with other models or try with cross validation to improve the performance
  • Start preparing the talk for PROPL25
  • Start designing the classes for CNN-based models(?)
Back to top ]]> phd https://ancazugo.github.io/posts/2025-09-14-weekly-notes.html Sun, 14 Sep 2025 00:00:00 GMT 2025-08-24 Weekly Notes Andrés C. Zúñiga-González https://ancazugo.github.io/posts/2025-08-24-weekly-notes.html

Intro

This is officially the first post in the new website, meaning that this is the first one written in Quarto Markdown format and not plain Markdown. I’ll make use of the advantages of this new website and organise the posts accordingly with headers that can be accessed from the right side of the window (desktop).

LCZ Classification

Geoclimate

So, most of last week was spent working on getting the data for Local Climate Zones for cities. As said in the previous post, I used the GUPPD dataset from NASA to access the geometries of urban areas around the world. However, as I quickly realised when testing it for London, running Geoclimate for a whole city takes some time (15 hours to be precise). This is mostly a result of Geoclimate querying OSM data for a limited size for a given location, which meant that I had to tile the boundaries of cities to less than 1000 km2 (15 tiles in London). This is variable for each city and due to the CRS of the OSM, I decided to tile in unprojected coordinates so each tiles is 0.25x0.25 degrees, ensuring that even in the equator (looking at you Bogotá!!) the tiles do not surpass the 1000 km2 limit.

The second problem I encounter was that GUPPD has >300k cities, which is a lot and given the time it takes to calculate LCZs with Geoclimate, I decided to trim the dataset to cities with only more than 1M inhabitants, which resulted in only 515 cities. This is still a lot of cities to process, but it is manageable.

So, I left the script working for the whole long weekend expecting to find all the LCZs for major cities, but I found that some cities did not have any results and it took me a while to find out why because Geoclimate is written in Java but I am excuting it as a subprocess in Python, so I couldn’t see the error messages. With the help of Gemini, I found that my allocated /temp directory was full and Geoclimate couldn’t create the spatial databases based on OSM features. Now, that is sorted and it is running in parallel to speed up the process.

EO Foundation Models

In parallel to Geoclimate, I started getting the data for the predictors in this project. Earlier this year I had used the AlphaEarth model from Google to make some PCAs of London using their v2 of the embeddings. I had used XEE to convert directly in Python the ImagCollections to Numpy Arrays for easier processing in DL models. So I resumed that and based on the boundaries from GUPPD, I created a script to download only the embeddings matching the areas covered by the LCZ classes from Geoclimate. I decided on this approach instead of downloading all the tiles from Google Earth Engine because I didn’t want to use pixels from non-urbanised areas, which is most of the world. In addition to this, I tried to do something similar using the embeddings from TESSERA, where I only request those that match the boundaries from the Geoclimate classification, but I found some bugs in the Python API. Then I realised that it’s better to use the development version of TESSERA, instead of the one in PyPi. But, I’m still working on that.

Weekly Objectives

  • Rasterise and co-register the LCZ classification from Geoclimate using the projection of the FM embeddings (AlphaEarth or TESSERA)
  • Figure out what the most efficient way to get the embeddings from TESSERA is
  • Resample the embeddings to the same resolution as the LCZ classification from Geoclimate (100x100m)
  • Define the model to be used for the classification

Visualization

Comparison of the LCZ classification from Geoclimate and the only global map available in GEE (WUDAPT) for Bogotá (same colour palette for both)
Back to top ]]> phd https://ancazugo.github.io/posts/2025-08-24-weekly-notes.html Sun, 24 Aug 2025 00:00:00 GMT 2025-08-17 Weekly Notes Andrés C. Zúñiga-González https://ancazugo.github.io/posts/2025-08-17-weekly-notes.html

Intro

Lot of things have happened in the last week: I had my first batch of summer school lectures where I talked about data visualisation and urban planning to undergraduate students from Chinese universities. Overall the feedback was good and I got to present my work in the urban planning session.

Website

In addition to this, as you can probably see, I spent more time than expected on the new website. This change was something that I had planned months ago and decided to do it over the summer. I switched from Jekyll to Quarto because that would allow me to use Jupyter notebooks or R Markdown notebooks on my posts. In addition, I have more options when it comes to pagination of the posts and filtering, so people can find more easily different posts. The whole design is not even close to being done as it is currently using one of the default Bootstrap themes, so it will change in the coming weeks.

More sections will also appear to highlight academic content like papers and talks and services for possible consulting opportunities. If someone who reads this and has some comments, please do so below!!!! That will create a pull request on the repo and I can see it more clearly, which is super cool. Also, by doing this I learned something about Continuous Integration (CI) and Deployment with GitHub Actions, which also comes in handy for other stuff. Another key change is that the feed is now RSS, instead of Atom, which I’m not sure if it’s going to crash with Recoillama in the Matrix, but if it does I may have found a workaround using CI and a small Python script.

Kudos to Mickaël Canouil and Silvia Canelón for being inspiration on the structure of the new website. They were more useful than any agentic tool because none of them structured the website as I was looking for. I spent a good chunk of time prompting on the editor with different models using the old website as reference but they struggled to sort the files and create the right YAML headers for the different sections. They also created CSS files that I had explicitly asked not to create and messed up the default design. Safe to say that agentic tools are cool and can be useful for certain things but in this case they made me spend more time on finding errors and then doing it from scratch myself.

3-30-300 Project

When it comes to the project, I finally gave it a name (plus some other candidates) and created the Zenodo repo (private for now) for the aggregated data to be accessed because there will be a collaboration with other postgraduate students from Epidemiological MRC in Cambridge. I have also updated the documentation of the project on GitHub to include the Carto dashboards, so people can navigate there instead of going to weird links that might go down in the future.

LCZ classification with FM

I set up Geoclimate to work on Python, but the only problem is that it is only capable of getting the local climate zones classification of small areas (like one London borough at a time) due to restrictions in processing OSM data. I initially wanted to use FAO’s GAUL political boundaries to access data from different cities, but I had to change it to a dataset that only had the boundaries of urban areas, for which there were a couple of options but I decided to go with the Global Urban Polygons and Points Dataset (GUPPD) by NASA that has the largest coverage and doesn’t clip natural areas that are inside cities. This is crucial because natural areas are one of the categories in LCZ classification. With this, what I have to do is get the bounding box of the urban areas and create 1000 km^2 grids inside it to calculate LCZ and then merge them and rasterise them. After that, the next step is to co-register the rasterisation of the LCZ classification from Geoclimate, with the embeddings from TESSERA (or other FM like AlphaEarth) and the global LCZ map, which should facilitate the future steps of the project.

Past Weekly Objectives

  • Design UI for Earth Engine App of aggregated data
  • Actually put a good name on the paper
    • Prepare cover letter for submission
  • LCZ classification
    • Create script to run Geoclimate from python (no java)
    • Delineate cities using boundaries or bbox from GAUL
  • Prepare summer schools batch 2

Weekly Objectives

  • Prepare the cover letter for submission
  • Clean up the repo documentation
  • Coregister the LCZ classification with EO embeddings/Global LCZ map
Back to top ]]> phd quarto https://ancazugo.github.io/posts/2025-08-17-weekly-notes.html Sun, 17 Aug 2025 00:00:00 GMT 2025-08-10 Weekly Notes Andrés C. Zúñiga-González https://ancazugo.github.io/posts/2025-08-10-weekly-notes.html So last week I updated the results with the spatial error models and worked on the supplementary material of the paper mostly. The app to visualise all the trees is done (see below). Building it was surprisingly easier than it looked. Just let Sedona partition the data and upload that to a Google Cloud bucket, then create a table that CARTO can read and make the connection between the two. With this I realised that it is impossible to upload the tree partitions to Zenodo because there is a restriction to the number fo files, even though the 183 million trees only take 6 GB as parquet files (highly recommended format for those that still use .shp or .gpkg). Big plus from this that I actually got to play around with GCP.

Going back to the app, it is possible to count the trees in the viewport, in a selection area by the user and see the distribution of crown areas and heights. In order for it to perform well and load more-or-less fast, trees had to be simplified to points, but the radius encodes the crown size and the colours do it for the height.

On the other hand, I met with Michael and Finley to discuss some ideas on how to take my data or some derivate of it to a physical form with 3D printers. Always a nice visit to the makespace lab. I also played with rayshader in R a bit to see what 3D modesl can be made out of sf objects in R, but they aren’t as good, plus they rely on colour, so not ideal for 3D printing.

Finally, I started the work on using TESSERA for my project. As explained in previous posts, I have the idea to use it to test LCZ classification scheme that dominates the urban science landscapet. For that, I need labels of the actual land use in cities. Currently, there are three main sources: (i), community data from WUDAPT, (ii) the 2022 paper that uses multiple satellite products (similar to those used by Google’s AlphaEarth model) and, (iii) Geoclimate, which I actually discovered in EGU24 last year. It uses OpenStreetMap to define LCZ classifications at different scales. So, I’ve been setting it up and already got classification for London and other cities. The biggest obstacle is the coregistration of pixels from this tool and the embeddings from any FM model, so that’s the next problem to solve.

Summer school season started and I’ve been preparing lectures to undergraduate and high school students from all over the world about my PhD project, AI and urban planning. It’s always nice to talk to people unfamiliar with your project and get good feedback from a younger audience (which makes me feel super old 👴).

Past Weekly Objectives

  • Move the trees dataset to an CARTO App
  • Make the corrections to the manuscript
    • Update methods and results
  • Design UI for Earth Engine App of aggregated data
  • Start working with TESSERA
  • Prepare content for summer schools

Weekly Objectives

  • Design UI for Earth Engine App of aggregated data
  • Actually put a good name on the paper
    • Prepare cover letter for submission
  • LCZ classification
    • Create script to run Geoclimate from python (no java)
    • Delineate cities using boundaries or bbox from GAUL
  • Prepare summer schools batch 2

Interactive Version

Back to top ]]> phd carto map dataviz https://ancazugo.github.io/posts/2025-08-10-weekly-notes.html Sun, 10 Aug 2025 00:00:00 GMT 2025-08-03 Weekly Notes Andrés C. Zúñiga-González https://ancazugo.github.io/posts/2025-08-03-weekly-notes.html After a week of slow progress in the project with nothing worth highlighting, hence the two week-hiatus in the blog, last week I made a lot of progress on the paper, with Ronita and Anil’s corrections:

First and probably most importantly, I felt that the paper was missing some actual statistical tests that could validate my results. Plots look good on paper but without actual support from stats, they can be misleading from my point of view. For this reason I added three spatial error models to demonstrate the usefulness of the remote sensing-derived metrics in explaining inequality. This kind of models accounts for spatial correlation. This change led to a new section in the paper’s methods and results sections and more discussion content that I’m finalising this week.

Furthermore, with the errors in the tree count functions now corrected, I re did all the plots in the paper for better accuracy, even though visually they don’t change that much. In addition to this, some of the choropleth maps I’ve shown here in the blog have been redesigned to include barplots/histograms as legends, partially inspired by posts on LinkedIn where I’ve seen this more commonly used. This blogpost helped me come up with a way to do it in R. Also, this was also motivated by the book How to Lie with Maps by Mark Monmonier that I recently finished. It’s a good resource on cartography for newbies, especially about theory and history of maps, but it lacks on the current trends and tools for map making.

Finally, following the FAIR principles, in addition to making the code available and writing proper documentation (see the brand new code’s repo), I aimed at creating two ways of making my results accessible via web apps: (1) one depicting the aggregated results for each LSOA in England and the other showing the tree segmentation results. I had done small attempts in the past months using CARTO for [aggregated data] (2025-03-23-weekly-notes.html) and tree locations. I wanted to build one with Google Earth Engine Apps but there are downsides in user friendliness and scalability. GEE only receives shapefiles as input which is fine for the aggregated data because it’s actually not that big once geometries are simplified, but the trees are not so easy; they are almost 200M polygons, and saving all of them into multiple shapefiles (even after simplifying geometries to points) would create massive files that then need to be imported into GEE as separate layers. For now, I created a map using CARTO again for the aggregated data for a summer school activity with kids (see below), but my goal is to move it to GEE so I can display the spectral indices in the same place more easily. In regards to tree segmentation, I will likely stick to CARTO using partitioned parquet files, but I am tempted to create vector tilesets using tools like Tippecanoe, however, I’ve never done that before so we’ll see what the better option is.

Finally, and totally unrelated, over the last couple of weeks, I’ve come across the Rust programming language several times, either in conversations with friends or by reading online about projects written in Rust (like uv or Polars), that left me wondering if it’s worth adding it to my toolbox as a low-level language. As a non-CS person, I’ve barely played around with C/C++ and although I don’t consider myself a bad programmer, I don’t think I have the proper theoretical foundation to experiment with tools beyond the realm of R and Python (and a bit of JavaScript). However, I’m looking for resources and ways to procrastinate my PhD start small and gain momentum, so if anyone has suggestions or advice, they are more than welcome 🙃.

Past Weekly Objectives

  • FINISH THE PAPER MANUSCRIPT!!!!
    • Organise the supplementary material
  • Move the trees dataset to an CARTO Earth Engine App (TODO)
    • Publish them in Zenodo as well
    • Figure out how to split the data for massive upload to Google Cloud
  • Resume documenting the code for the 3-30-300 paper
    • Update the docstring for some functions that have changed
    • Use mkdocs to create the github pages website to link in the paper
  • Make the corrections to the manuscript (on it)
    • Change image order and reduce number of tables
  • Apply to PROPL25
  • Prepare slides for AI4ER training event

Weekly Objectives

  • Make the corrections to the manuscript
    • Update methods and results
  • Design UI for Earth Engine App of aggregated data
  • Start working with TESSERA
  • Prepare content for summer schools

Interactive Version

Back to top ]]> phd carto map dataviz https://ancazugo.github.io/posts/2025-08-03-weekly-notes.html Sun, 03 Aug 2025 00:00:00 GMT 2025-07-20 Weekly Notes Andrés C. Zúñiga-González https://ancazugo.github.io/posts/2025-07-20-weekly-notes.html Last week I had a training event with the AI4ER people on how to prepare posters and slides for academic purposes, followed by a BBQ (and the inevitable rain). I had to present my research and I got valuable feedback from Adriano Gualandi on how to properly deliver my message and present using animations, to grab people’s attention. To be honest, I had rarely used animations before in my slides because I appreciate simplicity and with special effects it can get too much easily. However, with the feedback I got, I think the power of the animations relies heavily with the storytelling aspect of the presentation and how your speech is going. This was super valuable so I will be working on that over the summer because I know that I will have to present at my department’s PhD conference in November.

After this, I was working on the paper but I realised that my code had a minimal but very important error when it was counting the trees for all the regions in England. It took me two days to find the bug. It turns out, in the final count I was including files from different years for certain tiles (see OS national grid here). This was not only causing problems with the total tree count but also with the inequality metric I designed, so I had to re-check most of the code. Unfortunately or fortunately, depending on who you ask, LLMs are still not good enough at catching this kind of errors, and the solution was very simple. In the end, the current tree count for England is 183M trees.

Finally, and a bit unrelated to my research, in the last couple of weeks while talking to friends from all over the world (the best thing about Cambridge) and after reading the news, I realised that many former European colonies in the Americas celebrate their independence over the summer months (or winter if you go down south), so in commemoration of Colombia’s own national holiday (July 20th) I tried to plot that trend over the weekend and see if that was actually true. I posted the full version on my LinkedIn page for showboating 🤣, but here you’ll see the one that actually represents what I thought originally. Turns out, the rush for Q3 (Jul-Sep) independence happened before the 20th century for the most part (17 out of 22 countries). After that, my hypothesis doesn’t really hold true, particularly for the Caribbean countries. Purely made with R, the code can be found here.

Visualization

2025-07-20 Weekly Notes
Back to top ]]> phd dataviz https://ancazugo.github.io/posts/2025-07-20-weekly-notes.html Sun, 20 Jul 2025 00:00:00 GMT 2025-07-13 Weekly Notes Andrés C. Zúñiga-González https://ancazugo.github.io/posts/2025-07-13-weekly-notes.html Last week was not particularly eventful but I had two very important meetings with my supervisors regarding the 3-30-300 paper. Now I feel that the paper is 95% done. The plan for most of last week and this week has been to make the suggested changes in the manuscript for a new revision.

In an attempt to compare my results with those from other non-academic organisations that measure “greenness” in cities, I tried to improve my plot from a couple of weeks ago using the the UK Tree Equity Score dataset. This won’t likely be included in the supplementary material because it’s way more information than one can grasp, but, IMO, it’s colorful and flashy, thus worth posting here 😂

In addition to this, I also worked on the submission of the provocation to the PROPL25 conference later in the year and in a couple of slides summarising my research for an AI4ER training event. These slides will be the foundation for my presentation in November for the PhD student symposium in the Department of Architecture.

Past Weekly Objectives

  • FINISH THE PAPER MANUSCRIPT!!!!
    • Organise the supplementary material
  • Move the trees dataset to an Earth Engine App (TODO)
    • Publish them in Zenodo as well
    • Figure out how to split the data for massive upload to Google Cloud
  • Resume documenting the code for the 3-30-300 paper (Sort of started)
    • Update the docstring for some functions that have changed
    • Use mkdocs to create the github pages website to link in the paper
  • Make the corrections to the manuscript (on it)
    • Change image order and reduce number of tables
  • Apply to PROPL25
  • Prepare slides for AI4ER training event

Weekly Objectives

  • Rehearse slides in AI4ER and sumemr school
    • Make corrections to the slides
  • Make the corrections to the manuscript
    • Organise the supplementary material

Visualization

2025-07-13 Weekly Notes
Back to top ]]> phd dataviz https://ancazugo.github.io/posts/2025-07-13-weekly-notes.html Sun, 13 Jul 2025 00:00:00 GMT 2025-07-06 Weekly Notes Andrés C. Zúñiga-González https://ancazugo.github.io/posts/2025-07-06-weekly-notes.html Last week started by attending the in-person event of Information is Beautiful’s author, David McCandless at the Royal Geographical Society, who gave a presentation on how to make data tell a story, based on his experience as a data journalist. This was the inspiration for this week’s plot down below using my data. In the paper is shown differently (you’ll have to read it to see it) but I thought it should be fun to explore treemaps, which I hadn’t done in the past. He made extensive use of this to compare the narrative around expenditure in the army by country in raw numbers, as a proportion of GDP and as proportion of the population. My goal is to show a similar thing but in terms of trees just for now. While doing this I realised that these kinds of plots are not very common in scientific papers, and I’m not really sure why as they explain proportions quite clearly, and way better than the awful pie charts you see everywhere. This also marks my return to D3 after years of not using it, although this time with a significant help from LLMs. Below you’ll find a hierarchical treemap of Regions, Local Authorities, and LSOAs according to the number of trees in each geography. This is a work in progress as you’ll see that the smallest box doesn’t have the right size, so a lot of debugging (go click on each box to see where in that area you can find more trees!!!)

Past Weekly Objectives

  • FINISH THE PAPER MANUSCRIPT!!!!
    • Add the references to all the sections
    • Organise the supplementary material
  • Move the trees dataset to an Earth Engine App (TODO)
    • Publish them in Zenodo as well
    • Decide on publishing all segmented trees or just the ones I defined as proper trees (height > 3 m & crown area > 10 m^2)
    • Figure out how to split the data for massive upload to Google Cloud
  • Start the Zettelkasten method (Setup and working)
    • Link Obsidian with my previous notes from notebook and iPad notes
  • Resume documenting the code for the 3-30-300 paper (Sort of started)
    • Update the docstring for some functions that have changed
    • Use mkdocs to create the github pages website to link in the paper

Weekly Objectives

  • Make the corrections to the manuscript
    • Change image order and reduce number of tables
  • Apply to PROPL25
  • Prepare slides for AI4ER training event

Interactive Version

Back to top ]]> phd dataviz d3 javascript https://ancazugo.github.io/posts/2025-07-06-weekly-notes.html Sun, 06 Jul 2025 00:00:00 GMT 2025-06-29 Weekly Notes Andrés C. Zúñiga-González https://ancazugo.github.io/posts/2025-06-29-weekly-notes.html Last week was unexpectedly devoted to sorting things out with my scholarship due to an unforeseen issue. However, I managed to finish all the sections in the 3-30-300 paper, except for the discussion which needs polishing. I added a couple of plots and rearranged the results with a story for each subsection. I’m really becoming a power user of Gemini for correcting writing style to fit an academic text. Linked below is a plot that summarises one of the points I make in the manuscript about how the 3-30-300 is reflected in population numbers.

I briefly tried to use ApacheSedona to do zonal statistics on the buildings dataset to create a 30-metric per building using a buffer area, but it wasn’t very easy to do, due to the size and extent of the images. This was only to test if I could add more granularity to the paper methods for some of the spectral indexes, but using census polygons should be good enough.

Also, I finally had a meeting with a couple of people interested in the project I worked on for about room occupancy for Estates and they were very impressed with my app. The main conclusion from the pilot study for this is that a University of this size should have a more centralised system to know their facilities. The nature of the insitution makes it difficult but it should be a matter of gathering all parties involved (departments, colleges, etc) to create a unified way to quantify room occupancy.

Later in the week, the Urban Analytics Lab from NUS came to visit Cambridge and gave short presentations (I also did one). Most of the PhD students work on using Street View images to quantify different aspects of cities from traffic, to energy use and building type. This came right on time as I wrote about this a couple of weeks ago. Of particular relevance was Winston’s Urbanity project which I’ll have to try, as well as the group-wide Global Streetscapes dataset. Also, interesting talks by Zicheng’s work on nightime stree imagery and Xiucheng’s OpenFACADES. Yixin Wu’s (unpublished) work on carbon sequestration by urban trees seems highly relevant for my work as it is a very understudied ecosystem service provided by urban green infrastructure.

Also, from this week on I will be implementing the Zettelkasten method to record my literature review so I don’t have to do double the work from notes to writing. This is based on the book titled How to Take Smart Notes by Sönke Ahrens, based on the method made popular by sociologist Niklas Luhmann. I decided to do this because I felt that my notes and highlights were not going anywhere and were not as effective, so I did some research a while ago and finished reading the book recently. This was also motivated by my struggle with writing, which I believe is quite common in academia (particularly for those whose first language is not English). I will update how my knowledge graph grows in Obsidian and how I implement the writing in my thesis and papers, alongside other LLM-based tools.

Finally, to hold myself accountable for stuff I need to do, I will start posting my weekly objectives here and come back to them the following week to see how I did. I will post them from top to lowest priority and with sub goals.

Weekly Goals

  • FINISH THE PAPER MANUSCRIPT!!!!
    • Add the references to all the sections
    • Organise the supplementary material
  • Move the trees dataset to an Earth Engine App
    • Decide on publishing all segmented trees or just the ones I defined as proper trees (height > 3 m & crown area > 10 m^2)
    • Figure out how to split the data for massive upload to Google Cloud
  • Start the Zettelkasten method
    • Link Obsidian with my previous notes from notebook and iPad notes
  • Resume documenting the code for the 3-30-300 paper
    • Update the docstring for some functions that have changed
    • Use mkdocs to create the github pages website to link in the paper

Visualization

2025-06-29 Weekly Notes
Back to top ]]> phd dataviz https://ancazugo.github.io/posts/2025-06-29-weekly-notes.html Sun, 29 Jun 2025 00:00:00 GMT