4 Mapping Raster Data – A course in Geographic Data Science

Concepts

Everything we have mapped so far has been vector data — points, lines and polygons, each one an object with a geometry and a row in a table. This section is about the other half of the spatial world: raster data, where space is carved into a regular grid and every cell just holds a number.

That difference sounds technical, but it changes what the data can tell you — and what you have to do to make it useful.

Slides can be downloaded “here”

Raster Data

Think of a digital photograph. Zoom in far enough and it stops being a picture and becomes what it always was: a grid of pixels, each one a single value. A raster is exactly that, except the grid is pinned to the Earth and the values mean something — metres above sea level, degrees Celsius, probability of cloud.

Square grid of pixels
Divides 2-D space into regular cells
Each cell has a single value — that’s the whole data model
Values can be continuous (temperature) or categorical (land cover class)
The value is assigned by some rule — the mean across the cell, the value at its centre point, and so on

Raster vs vector: what actually differs

	Vector	Raster
Space is…	objects with boundaries	a continuous grid
Each unit is…	a point, line or polygon	a cell
Attributes	a whole table per feature	one value per cell, per layer
Good at	discrete things — buildings, roads, boundaries	continuous surfaces — elevation, temperature, light
Units come from	how we chose to divide the world	how the sensor happened to be built

The trade-off worth remembering

Vector boundaries are ours — wards, districts, LSOAs. Someone drew them, usually for administrative rather than analytical reasons. Raster grids are the sensor’s: arbitrary too, but arbitrary in a consistent, regular way that doesn’t follow politics or history.

Which means rasters sidestep some of the MAUP problem — right up until the moment you aggregate them into administrative units, which is exactly what you’ll do in the lab.

Data Types

Not all rasters are the same. The differences come down to how many layers (“bands”) there are and what the values mean.

Grayscale Rasters

Continuous data, a single band.

One layer, one value per cell, usually rendered as shades of grey from dark (low) to light (high). Pixel values often run 0 (black) to 255 (white), though in scientific rasters they’re just as likely to be real measurements — radiance, metres, degrees.

Example: nightlights data. Darker areas mean less artificial light at night, lighter areas more. Used for monitoring urban development, assessing light pollution, and — as you’ll see below — as a proxy for economic activity where reliable statistics don’t exist.

Multispectral Rasters

Multiple bands, stacked.

Satellites don’t take photographs in the everyday sense. They are flying sensors that record several slices of the electromagnetic spectrum at once — red, green, blue, plus bands invisible to us like near-infrared and thermal infrared. Each band is a separate layer over the same grid.

This is what makes satellite imagery analytically powerful rather than just pretty. Different materials reflect differently across the spectrum: vegetation reflects strongly in near-infrared while water absorbs it, so a band the human eye can’t see turns out to be the best way to map plant health or find a flooded field.

Example: Landsat. Used for tracking land cover change, assessing vegetation health, monitoring water quality, detecting fires.

Colour Rasters

Three bands: red, green, blue.

The everyday case — a digital photograph. Each pixel carries an R, a G and a B value, and their combination gives the colour you see. Technically a multispectral raster restricted to the three bands our eyes happen to have receptors for.

Example: digital photographs and optical satellite imagery, including before/after imagery used in damage assessment.

Elevation Rasters

One band, where the value is height.

Each cell holds elevation above (or below) a reference point, usually sea level. These are Digital Elevation Models (DEMs) — the basis for topographic mapping, slope and terrain analysis, hydrological and flood modelling, and route planning.

You’ll work with a DEM of Lebanon in the lab. Watch out for the negative values: that file includes bathymetry — depth below sea level — so the Mediterranean isn’t blank.

Resolution

Two kinds of resolution decide what a raster can and can’t show you, and both involve a trade-off.

Spatial resolution

How much ground does one pixel cover? Measured in metres per pixel.

1 km/pixel — very coarse. A whole town is one cell. Fine for global vegetation or sea-surface temperature.
30 m/pixel — medium. Roughly a city block per cell. This is Landsat.
1 m/pixel or finer — individual buildings and trees. Usually commercial, usually expensive.

Higher resolution means more detail — but also much bigger files, more compute, and often less frequent revisits.

Temporal resolution

How often does the satellite come back? Also called the revisit time or repeat cycle.

Short revisit cycles let you track fast-moving things — floods, fires, crop cycles. Longer cycles usually trade frequency for higher spatial resolution. You rarely get both.

Data volume is a real constraint, not a footnote

A single Sentinel-2 scene is several gigabytes. Multiply by revisit frequency, by years, by area, and raster analysis becomes as much a data-management problem as an analytical one. This is why cloud-based processing (Google Earth Engine, Microsoft Planetary Computer) has largely replaced downloading files to your laptop for serious work.

Where the data comes from

Higher spatial resolution data tends to be costly commercial product. Lower resolution data is free, mostly from public space agencies:

USGS Earth Explorer — Landsat and much else
NASA Earthdata Search
Copernicus Data Space — Sentinel imagery (replaced the retired SciHub)
AppEEARS — extract by area rather than downloading whole scenes
Landsat on AWS

Most need a free account, and all involve large files.

Satellite data for Social Science

Why should a social scientist care about pixels? Because satellites see places that statistical systems don’t — consistently, repeatedly, and for decades. Where census data is missing, outdated, or politically shaped, imagery offers an independent measurement.

Two papers worth reading, both of which you’ll see referenced in the lecture:

Henderson, J. Vernon, Adam Storeygard, and David N. Weil. 2012. Measuring Economic Growth from Outer Space, American Economic Review, 102 (2): 994-1028. Replication data — uses nighttime lights as a proxy for GDP growth, particularly where national accounts are unreliable.
Jean, Neal, et al. 2016. “Combining satellite imagery and machine learning to predict poverty”, Science — trains a model on daytime imagery to predict household consumption across African countries.

Read these critically

Both papers are landmarks, and both rest on a proxy. Brighter is not automatically richer — light reflects infrastructure, electrification policy and industrial activity as much as it reflects income. When you map nighttime lights in the lab, ask yourself what a bright cell actually tells you, and what it doesn’t.

From pixels to policy

There is a gap between “satellite data exists” and “I can use satellite data in my analysis”, and it is wider than it looks:

A single scene is gigabytes
Much of your imagery is hidden under cloud
Cleaning, mosaicking and modelling need real compute and remote-sensing knowledge
And pixels don’t line up with the units social science uses — LSOAs, wards, local authorities

Getting from one to the other takes four steps:

Raw — spectral values arrive noisy, partly cloud-covered
Clean — many passes through time are combined into a cloud-free composite
Model — cleaned spectral values become a meaningful indicator: surface temperature, vegetation, cloud probability, light
Aggregate — pixels are pooled into administrative units, so the data can join to censuses, surveys and policy frameworks

Step 4 is where a raster becomes a choropleth — and where the skills from the previous section pick back up.

Want to go further with satellite data?

Running that pipeline is the whole business of Imago, the imagery data service for sustainability, prosperity and wellbeing, part of Smart Data Research UK and based partly here at Liverpool. They publish the output as ready-to-use LSOA/MSOA-level statistics — no gigabyte downloads, no remote-sensing algorithms, small-area detail preserved rather than flattened into regional averages.

From grids to areas — the full walkthrough of the four steps above, with the spectral bands, resolution and revisit-cycle background behind them. Start here.
Imago training — free, openly licensed trainings in both R and Python, covering air temperature, precipitation and SPF. Several run directly in your browser, no installation needed.

Worth knowing: the SPF data you mapped in the choropleths lab was satellite-derived cloud probability that had already been through this entire pipeline. You were doing raster analysis without ever touching a raster — which is rather the point of a service like this.

In the lab

You’ll work through the pipeline yourself, on two datasets:

Terrain (Lebanon) — load a DEM, check and fix its CRS, crop then mask it to the country boundary, style it with a proper elevation palette, and extract raster values at survey point locations.

Night lights (Kenya & Tanzania) — stack multi-year rasters, compute zonal statistics (mean light per administrative region), and map 1992 against 2013.

Two things that trip everyone up

CRS mismatches are the single most common reason raster code silently returns NA. Check before you extract, not after.

Crop before you mask. Both narrow a raster to your area of interest, but cropping is a cheap rectangular cut while masking tests every cell against a polygon. Shrink the problem first.

R and Python side by side

The labs for this session cover the same ground in both languages. Here is how the key functions line up, so you can follow either lab (or switch between them) without losing the thread:

Task	R (`terra`)	Python (`rasterio`)
Load a raster	`rast()`	`rasterio.open()`
Inspect it	print the object	`.profile`
Check the CRS	`crs()`	`.crs`
Reproject	`project()`	`calculate_default_transform()` + `reproject()`
Crop to a bounding box	`crop()`	`mask(..., crop=True, filled=False)`
Mask to a shape	`mask()`	`mask(..., crop=True)`
Extract at points	`terra::extract()`	`.sample()`
Zonal statistics	`exact_extract()`	`rasterstats.zonal_stats()`
Bin values into classes	`cut()`	`pd.cut()`
Map it	`geom_spatraster()` (`tidyterra`)	`rasterio.plot.show()`

Note

The biggest practical difference is reprojection. terra::project() is a single call; rasterio makes you calculate the new grid and write the output yourself. That’s not rasterio being awkward — it’s exposing the step that terra hides, namely that reprojecting a raster means building a whole new grid and estimating values for it. Worth remembering whichever language you use.