Source: https://mayphus.org/four-province-expressway-atlas/
Title: Making a four-province expressway atlas lighter
Metadata: {"category":"artifact","date":"2026-10-05","id":"four-province-expressway-atlas","kind":"article","language":"en","locale":"en","route":"/four-province-expressway-atlas/","slug":"four-province-expressway-atlas","tags":["maps","openstreetmap","performance"],"type":"article"}

# Making a four-province expressway atlas lighter

On October 3, I worked on an expressway atlas covering Hubei, Anhui, Jiangxi, and Zhejiang. The useful progress was in how the map loads and reuses data. This note records that engineering progress.

The source edition is dated `2026-10-02T20:21:34Z` and contains 107,401 OpenStreetMap objects. That is an object count, not a count of distinct roads, a completeness guarantee, or live traffic information. The underlying map data comes from [OpenStreetMap contributors](https://www.openstreetmap.org/copyright).

## A snapshot instead of a live dependency

Public Overpass requests were an unreliable dependency for this atlas. I moved the map data into static, partitioned JSON so ordinary interaction would not depend on a fresh response from a public query service.

This makes the edition explicit. It also means the data can become stale: a dated snapshot is easier to inspect and serve, but it still needs a deliberate refresh. It should not be presented as a live road-status feed.

The next problem was loading too much of that snapshot. A viewport needs the nearby features from the layers it actually displays, not the entire four-province dataset. I partitioned the data into quarter-degree geographic cells and made loading depend on the viewport and enabled layers.

## Smaller requests and less repeated work

Caching alone does not solve map interaction. A response can arrive after the user has moved elsewhere, and a pan can cause existing features to be loaded or recreated unnecessarily.

The revised loading path caches data, handles stale requests, and reuses features while panning. The goal is to keep work tied to the current view and preserve what is already available.

Two benchmark views showed these reductions in raw data loaded compared with the earlier bulk-loading approach:

| Benchmark view | Raw-data reduction |
| --- | ---: |
| Wuxue | 83% |
| Hangzhou | 72% |

These are data-volume comparisons. They are not measured improvements in real-user download speed, rendering time, frame rate, or battery use. Compression, network conditions, device performance, and the chosen layers still affect the experience.

## Keeping the controls out of the map's way

The initial sidebar was bulky. I changed the controls to a collapsed layout and a bottom sheet on mobile, and explored a Swiss-inspired map treatment. Those changes accompany the loading work; they do not establish that the mobile interface now looks or behaves correctly on every device.

Dataset checks and simulated interaction tests passed. Visual preview was blocked, so visual QA remains unfinished. I have not validated the finished appearance across desktop and mobile screens or measured real-user network performance.

The next useful evidence is a visual pass on actual viewports and device-level interaction measurements. For now, the concrete result is narrower: the atlas has an explicit data edition, smaller viewport loads in the two benchmark cases, and a loading path that accounts for caching, stale requests, and feature reuse.