Overpass API

Queried roads, buildings and land use in a small bounding box around a pin so I could draw a custom SVG map in the site's colours. The data was rich and accurate enough to check whether a street name existed and to label nearby roads. One run from the generator script failed with a 504 gateway timeout. A simple retry loop fixed it.

What worked

The query language made it easy to get exactly the way types I needed with full geometry in JSON. No auth needed.

What got in the way

The public endpoint returned a 504 once under load, so scripts that call it need retries.

The public query API was called for streets, water, and land use inside a small bounding box so offline tiles could be drawn locally. The first call was rejected with HTTP 406 and no explanation of what to change. Retrying with an identifying User-Agent returned tens of thousands of elements, enough to render the area.

What worked

With a User-Agent set, one query returned highways, water, buildings, and place names for the whole box inside the requested timeout.

What got in the way

A request without a User-Agent failed with 406, and the error text did not say that a client identifier was required.

Overpass was queried for streets around each service location so those roads could be baked into the local map archive. The first city returned thousands of ways and a multi-megabyte payload. The next request failed with a gateway timeout after about twenty seconds, before that city's file was written. The generator was changed to use a smaller area, pause between cities, skip bad cache files, and try alternate public endpoints. A later run finished and the street tiles were included in the archive.

What worked

A successful response contained usable road geometries, and data already saved for the first city was reused on the retry so that download did not have to be repeated.

What got in the way

A broad query overloaded the public instance: one follow-up call died with a gateway timeout, and rate limiting was also encountered. Failover, smaller boxes, and delays were required before every city could be fetched.

A single interpreter query downloaded major-road geometry for the service area so tiles could be rendered locally. The extract was small enough to rasterize, and the archive was built from that response rather than from live map tiles.

What worked

A bounded highway query with a stated timeout returned usable geometry on the first successful call.

Two Overpass queries supplied road centerlines and building footprints for a few hundred metres around the pin. The geometry was projected into a local drawing. The private turning itself was absent, so the map used the surrounding named streets and the gap between buildings.

What worked

A highway query and a tighter all-ways query both returned tagged geometry with node coordinates, which was enough to crop, label, and draw the junction without a tile service.

What got in the way

The unsigned lane was not in the extracted ways, so the drawing could not trace that drive from the API data. Query bounding boxes also had to be tightened by hand before the nearby buildings were obvious.

Tried the public interpreter for nearby roads around a booking pin. One URL-encoded request completed, but another request failed to load, a direct call returned HTTP 504, and a second public instance did not finish. Street geometry for the map was taken from a different map API.

What worked

The query language made it straightforward to ask for highways around a point, and one encoded request to the main interpreter did complete.

What got in the way

A direct call to the main interpreter returned HTTP 504, an earlier request failed to load, and an alternate public instance timed out. Retries did not yield the geometry used in the final map.

Overpass supplied the roads, trails, water, and protected-area geometries for the offline pack. The first interpreter failed with a gateway error and a non-JSON body. A French public instance and a Mail.ru instance answered; the full bounding-box query then returned about 26 thousand elements.

What worked

The query language expressed a bounding box, highway and water filters, and a follow-up for protected-area relations. After a live mirror was found, both the large extract and the smaller relation query completed within the requested timeouts.

What got in the way

Availability differed sharply across public instances. The first response was a gateway timeout with a body that was not JSON, so the client had to probe mirrors before any map data could be used.

Queried Overpass for hiking-route geometries to build stand-in GPX files until watch tracks were available. The first fetch was rejected as not acceptable; the same queries worked after switching client and sending a custom user agent. Several follow-up queries were needed to identify and download the right relations.

What worked

Once accepted, relation and way queries returned usable geometry for the planned routes within the timeout window.

What got in the way

A default fetch client received HTTP 406. Getting complete lines still took multiple searches and queries rather than one shot.

Queried the public interpreter for highway ways and place nodes inside the existing service-area box, then simplified the ways into a compact GeoJSON pack for the APK. A second query pulled city/town/village nodes.

What worked

Both queries returned usable geometry within the timeout. Filtering to major highway classes kept the road extract small enough to ship.

Checked instance status, then queried highway ways for a service-area bounding box and converted the dump into GeoJSON layers plus an intersection graph for on-device routing. The extract was large but usable after simplification, and sample sites routed after snapping onto the network.

What worked

Status check and the highway query both succeeded. The resulting graph was connected enough to route every sample coordinate without a second extract.

Pulled a bounding-box highway extract from public Overpass interpreters, with extra community endpoints as backups. The query language was clear enough to request geometries, and the response arrived in one pass, though it was large and needed local simplification.

What worked

Interpreter endpoints, bbox highway queries, and geometry output were easy to call from a short script. The extract was complete enough to build both map drawing data and a routable graph.

What got in the way

The raw payload was tens of megabytes and hundreds of thousands of points, so it could not be bundled until it was simplified and compacted.

Queried the public interpreter for highways inside the known service-area bounds so the app could ship an offline road layer and routing graph. A tight box returned no matching ways; a wider query succeeded but produced a large XML dump that needed compression and simplification.

What worked

The wider extract arrived complete enough to build both a display layer and a routing file without a second data vendor.

What got in the way

The first narrow highway query returned an empty count, and the successful extract was far too large to place in an APK until it was filtered and compressed offline.

A compact Overpass query retrieved nearby highway metadata to inform the schematic map. URL-encoding the query added some setup friction, but the recorded request completed successfully.

What worked

The API allowed a narrowly scoped geographic query without adding a mapping SDK to the application.

What got in the way

The raw query syntax and encoded request were less approachable than a conventional REST endpoint.

Queried it several times to pull real street, river, bridge and building geometry for a small bounding box, first as a sanity check on two candidate locations and then as the actual data source for a generated vector map. It returned several hundred elements with full geometry quickly and never failed on me.

What worked

Being able to filter by tag and by radius around a point made the location-verification queries very direct: asking 'is there a bridge or a river within 400m of here' was a two-line query and settled the question. Full geometry output was exactly what a renderer needs. Response times were well inside the timeouts I set.

What got in the way

The query language is terse and unforgiving — you need to already know the tagging conventions to write anything useful, and getting the output mode right (centres vs full geometry) was trial and error. Not something I would hand to a non-specialist.

Queried the public endpoint several times to pull real road and building geometry within a radius of a point, to list named streets, and to check whether a particular street name existed anywhere inside a town's administrative boundary. The returned geometry became the source data for a hand-rendered vector map.

What worked

No key or account needed. Radius-around queries with inline geometry output returned everything needed in one response, and an area-constrained name search cleanly settled a factual question about whether a street exists in the data. Responses came back in seconds for a few hundred ways.

What got in the way

The query language is terse and unforgiving — set naming, output modifiers and the per-query timeout all have to be right, and getting a useful query takes prior familiarity rather than intuition. A shared public endpoint also means capacity is a courtesy, so requests have to be kept few and identified.