An Interactive Singapore Map, Built in One Conversation

The result is a live demo: an interactive map of Singapore ↗. Search a place, plan a train journey between two stations, colour the island by population density or HDB resale price, drop a 1953 survey map over the modern streets, or walk one of five heritage routes. Everything except the basemap tiles, rain radar and historical maps is embedded in one file you could email to someone.

A second push added the showcase pieces: a 3D flythrough of every building in Singapore ↗ (WebGL extrusion of OpenStreetMap footprints, streamed as vector tiles), a then-and-now slider that swipes between a 1914 survey map and today, and 15-minute isochrones showing how far the MRT network reaches from any station. All of it works on a phone.

I did not write it by hand. I built it by talking to an AI coding agent (Qwen, running in the opencode harness) across a single session — first a base map, then a second phase of features I picked from a menu the agent proposed. This piece is about what that process produced, how it worked, and where the honest limits are.

Google Maps is better at being Google Maps: routing, live traffic, Street View, reviews, business hours. I was not trying to replace it. I wanted something it does not give you — a map you can own, inspect and extend, built on Singapore’s open government data rather than a proprietary platform.

Three properties drove the design. It is self-contained: the boundaries, stations and points of interest live inside the file, so it works offline apart from imagery. It is key-free: no API key, no billing account, no quota — just open data and free tile servers. And it is private and hackable: search runs in the browser, nothing is tracked, and the whole thing is plain HTML and JavaScript with a reproducible data pipeline beside it.

The loop was conversational but disciplined. For each feature the agent researched a data source, downloaded it, wrote a small Python script to clean and compact it, embedded the result, and then tested the page in a headless browser before moving on. The testing mattered: it drove real Chrome over the DevTools protocol, clicked the controls, and asserted on the DOM, so bugs surfaced as failures rather than as guesses.

Several fixes came straight from that loop. The first default basemap rendered with an “API key required” watermark; we switched to Esri’s key-free tiles. OpenStreetMap’s own tiles then returned 403 Access blocked when the file was opened locally, because their volunteer servers require a web referer that a file:// page does not send — so Esri became the default and OSM an option. A geocoder matched “St Andrew’s Cathedral” to a namesake childcare centre in Jurong, inflating a walking tour to 33 km; the coordinate was corrected and the tour dropped back to 1.4 km.

The journey planner is a good example of doing more with data already in hand. Rather than call a routing API, the agent built a graph from the station codes — 184 stations, 212 edges, with the branch connections (the Changi extension, the Circle Line closing loop, Punggol Coast) wired in by hand — and ran a shortest-path search over it with a transfer penalty. It runs entirely offline.

The map layers come from official and open sources, each fetched and simplified by a script so the single file stays around 1.4 MB:

On top sit the quality-of-life features: marker clustering, a dark mode, PNG export, favourites saved in the browser, and shareable deep links to a specific place.

The cost shape is the interesting part, and it echoes what I found in the Devin Fusion cutover: the expense is overwhelmingly input, not output. By the end of this build the session had produced roughly 170,000 tokens of output and reasoning across about 150 tool calls, but had processed tens of millions of input tokens — most of it the same growing context re-read on every turn, served largely from cache. The “new work” was a rounding error next to the context. On the invite model the dollar cost was zero.

A practical lesson: for long agent sessions, caching and context discipline matter far more than the length of the model’s replies. The output is cheap; carrying the whole conversation forward each turn is not.

It is a reference and exploration tool, not a navigation product. There is no turn-by-turn routing, live traffic, Street View or business data. Journey times and fares are estimates. The boundaries are indicative. A handful of geocoded coordinates are approximate, and the data is a snapshot that needs a rebuild to refresh.

The one feature I could not make work from a local file is live LTA data (carpark availability, traffic incidents). LTA’s API needs a free key and sends no CORS headers, so a browser blocks direct calls from a static page. The map has a slot for the key and reports the block honestly; making it live would need a small proxy. The rain radar, which does send CORS headers, works fully key-free.

None of this diminishes the point. In one conversation, an agent turned a pile of open data into a polished, owned, extensible artifact — and tested its own work along the way. The file is small enough to keep, the pipeline is small enough to re-run, and the whole thing is independent of any one platform. That is the kind of system I like building.

• The live Singapore map — the self-contained demo this piece describes.
• How Devin Fusion Ran a Five-Day Company-Brain Cutover — the same input-heavy token economics, at much larger scale.
• Two Brains, One Operator — Qwen-tagged work on personal and corporate agent memory.
• Work catalogue — other repositories and tools.