Mapping Roman Britain: an AI-built viewer for Digital Britannia

The Roman Roads Research Association (RRRA) has released Digital Britannia v1, a GeoPackage of every engineered Roman road, fort, camp, settlement and milestone in Britain. I wanted a web map for exploring it properly: against LiDAR, against historic Ordnance Survey maps, and against other datasets. So I handed Claude Code a brief and watched it build one.

It's an unofficial viewer. The data is © Roman Roads Research Association / Mike Haken, CC BY-NC 4.0.

I wrote the brief in a Claude session discussion about what I wanted on my phone, then on my desktop created a new GitHub repo, and pasted the brief in to Claude Code:

The full brief, as pasted Pass 1: build a web map viewer for the RRRA's Digital Britannia v1 GeoPackage (about 3 MB). Non-commercial; credit the RRRA and Mike Haken; mark it unofficial.

Pass 3: a list of candidate underlays and overlays: NLS historic maps, aerial imagery, Historic England aerial mapping, scheduled monuments, Canmore/Coflein, BGS geology, 3D terrain, DARE, AWMC, Pleiades, OS maps. "I'd make NLS 6-inch, aerial imagery and LiDAR the core three, with the rest optional." Also: these come from general knowledge; verify each endpoint and licence before wiring it in.

Mid-build, I also asked for architecture decision records (ADRs) for every decision, and an errata document I could send back to the RRRA.

That last instruction, verify before wiring it in, shaped the whole build. More on that below.

The pipeline ( scripts/process.py ) reprojects each layer from British National Grid to WGS84. It keeps every vertex and only rounds coordinates to 7 dp (about 1 cm). The road accuracies are stated as ±30 m and ±200 m, and simplifying would quietly degrade them.

The result is 4.19 MiB of GeoJSON, under the 5 MB line. So there's no PMTiles and no tippecanoe, just one index.html on GitHub Pages fetching seven files.

Cleaning the categories turned up more than the brief anticipated:

Every issue went into an errata document with counts and examples, written for the RRRA's next release. The viewer applies non-destructive fixes and records each one.

MapLibre GL JS, with no build step and no API keys. Roads follow the author's own QGIS style: solid for certain, dashed for probable, dotted for conjectured, each with a white halo so it stays readable over the underlays. Click a road and its whole Margary route lights up.

Search takes place names, Roman names and road numbers:

There's also a period slider for military sites (131 Claudio-Neronian sites, peaking at 288 Flavian), popups with every attribute, and a bottom-sheet layout on phones.

Several services looked right from a quick check and weren't. Each was only caught by looking at the actual output.

CARTO base maps returned HTTP 200 and were useless. A curl check passed. In the browser, every tile said this:

The 2 KB watermark is what CARTO now serves to keyless requests. The base maps switched to Esri's Light and Dark Gray Canvas, and the lesson went into an ADR: a status code doesn't verify a tile service; you have to look at the tile.

The NLS "6-inch first edition" covers Scotland only. Every England tile returned 404. Listing the S3 bucket and reading each tileset's metadata.json showed that 6inchfirst stops at 54.6°N. The seamless GB layer is 6inchsecond. Here it is at Housesteads, where the RRRA Wall, Vallum and Military Way line up with "Borcovicus Roman Station" on the OS sheet:

Label fonts: one public glyph endpoint returned an HTML page; two others returned 404. One worked.

England was straightforward. The Environment Agency's 1 m composite hillshade WMS supports Web Mercator, so it drops straight into MapLibre.

Scotland publishes LiDAR DTMs but no hillshade. Its layers only come with colour-ramp elevation styles, which hide subtle earthworks:

The portal runs GeoServer, though, which accepts an inline style. Passing a ShadedRelief symbolizer via SLD_BODY makes the server compute the hillshade per request, here at the Antonine Wall:

One request stacks 11 survey layers (phases 1–6, the National LiDAR Programme and four Historic Environment Scotland surveys), with newer data drawn on top. That's about 4.9 KB of URL, safely under common GET limits. Here it is at Inchtuthil legionary fortress:

Wales: not possible yet. The Welsh hillshades exist, including a multi-directional one, but they aren't in DataMapWales's public WMS. The public cloud-optimised GeoTIFFs (1–22 GB) have no CORS rule; the preflight returns 403 CORS not enabled. No web page can read them. The ADR records exactly what would unblock it.

Also added: scheduled monuments for Scotland (HES) and Wales (Cadw), and Pleiades links for sites with a Roman name.

The last addition was Itiner-e, a CC BY 4.0 dataset of roads across the whole Roman Empire, as a comparison layer. Clipped to Britain (after a box caught eight roads on the Normandy coast), it's 1,371 segments.

Then Adrian noticed something while looking around Dorchester: the Itiner-e roads look consistently offset.

A route disagreement wanders. A consistent offset points to a coordinate system problem. Claude fitted the single best shift between the two datasets, region by region, and compared it with the error you'd get by treating OSGB36 latitude/longitude as if it were WGS84:

It's a mirror image, right down to the north–south part shrinking towards the Wall, the way the datum difference does. The offset showed up in all three contributor groups.

Before blaming Itiner-e, Claude checked its own pipeline. The same signature would appear if our British National Grid conversion had skipped the datum shift. PROJ uses a 2 m-accuracy OSGB36→WGS84 transformation, and the Greenwich Airy transit circle converts to 0.0016° W, not 0.0000°. So the RRRA layer was right.

The fix is principled, not a fitted nudge: reinterpret Itiner-e's British coordinates as OSGB36 (EPSG:4277) and convert them properly.

The median gap fell from 81 m to 17 m, and the remaining best-fit shift is +1, −2 m. That beats the best constant shift (24 m) because the datum correction varies across the country the way the error does. It's written up in ADR 0013, ready to send to the Itiner-e team.

Claude tested everything in a real browser, and that's where most of the bugs surfaced:

The fix routes the LiDAR sources through a small retry:// protocol with back-off. It was verified by forcing the first attempt of every third tile to fail: 14 of 42 were forced, and all 42 loaded. The lesson: a plausible explanation isn't evidence. The status-0 requests should have been tested, not explained away.

After a day of using the live map, Adrian filed two GitHub issues and gave Claude Code a three-word prompt: check the issues. It read them, did the one it could start straight away, and asked before the one that needed a download.

Tilting with the mouse was the only control, and the right-drag gesture didn't work for me. Ticking 3D terrain now shows four sliders: Tilt, Rotation, Altitude and Relief (vertical exaggeration). They follow the camera when you move the map, and switching 3D off returns a flat, north-up view. MapLibre caps tilt at 60° by default; that's now raised to 85°.

The popups linked to a Pleiades search for each site's Roman name, and they often missed. Dorchester's is a clear case: the dataset spells names as inscribed ( DVROVARIA ), Pleiades uses the standard form ( Durnovaria ), and its search only matches exact words. My issue sketched the fix: download the Pleiades open data, find candidate places within 2 km of each site, fuzzy-match the names, and link straight to the best match.

The first run matched 515 sites, but the review step is where it got interesting:

The result: 533 sites link straight to their Pleiades place (219 by Roman name, 314 by modern name). The other 466 fall back to a search and are listed in a CSV for manual review; only 17 of them have a real Roman name. The matches are committed, so a fresh clone rebuilds identically without the download. Roman names now display in title case, and searching "Durnovaria" finds Dorchester:

Models: Claude Opus 4.8 for the initial build, then Opus 5.5 from before the first commit.

The context figure is what the conversation held at the end. It isn't a cumulative total: each turn re-reads the context, mostly from cache, so the tokens actually processed are several times higher. The tooling didn't expose that total.