Slippy Tile Math and the Overpass Bbox Comma Shuffle

The Problem

Web maps are built from square tiles addressed by zoom, x, and y, and sooner or later you need to go between a lat/lon and a tile address, or figure out how many meters a pixel covers at zoom 18, or hand a bounding box to Overpass. The formulas are short and well-documented — and there's one specific way the bbox handoff goes wrong that this tool is built to prevent.

The Approach

The standard OSM slippy scheme, both directions [1]:

x = ⌊(lon+180)/360 · 2^z⌋,   y = ⌊(1 − ln(tan φ + sec φ)/π)/2 · 2^z⌋

The inverse gives each tile's NW corner, and the (x+1, y+1) corner completes the bbox. Ground resolution is 156,543.034 · cos(lat) / 2^z meters per pixel — the cos(lat) is why a zoom level covers less ground per pixel in California than at the equator — and map scale follows at an assumed 96 dpi. There's a z10–z20 resolution table and the TMS y-flip note (y_tms = 2^z − 1 − y) for when tiles render upside down.

Tile calculator showing z/x/y for a lat/lon, ground resolution, and bounding box printed in two orderings
Figure 1: A lat/lon resolved to a tile, with the bbox printed in both W,S,E,N and Overpass's S,W,N,E order.

The comma shuffle

Here's the bug the tool exists to prevent. Most tools write a bounding box as W, S, E, N (min-lon, min-lat, max-lon, max-lat). Overpass wants S, W, N, E (min-lat, min-lon, max-lat, max-lon). Same four numbers, different order — and if you paste one where the other is expected, you don't get an error, you get a query for a box somewhere else entirely (often an empty region, so it just returns nothing and you assume the data isn't mapped). The tool prints the bbox both ways, side by side, labeled, so the comma-shuffle happens to someone else. It pairs with the OSM tag helper's Overpass builder, which takes the S,W,N,E string directly.

Verification, including my own test bug

I checked against the canonical formulas: quadrant placement, the exact zoom-0 resolution (156,543.03 = 2πR/256), and lat/lon → tile → lat/lon round-trips. The round-trip test initially “failed” until I realized my test was wrong — I'd nudged the sample point north to land it inside a tile when tile y increases southward, so I was walking out of the tile instead of into it. A tidy little demonstration of why you write the tests: the bug was in my assumption about the coordinate direction, which is exactly the assumption the tool is meant to protect its users from.

One honest note: bulk-downloading tiles from the OSM servers violates the tile usage policy. This is for scoping surveys and Overpass queries, not scraping [3]. Single file, vanilla JS, localStorage persistence [2].

The tool: Slippy Map Tile & Zoom Calculator.

References

  1. [1] OSM wiki — Slippy map tilenames (the canonical formulas). https://wiki.openstreetmap.org/wiki/Slippy_map_tilenames
  2. [2] OSM wiki — Zoom levels and resolution tables. https://wiki.openstreetmap.org/wiki/Zoom_levels
  3. [3] Overpass API language guide — bbox syntax. https://wiki.openstreetmap.org/wiki/Overpass_API