Choosing Between Geofabrik, BBBike and the Planet File

Pick the OSM source whose shape actually matches your area of interest, rather than the one whose download page you found first — because the mismatch is paid for every single day the pipeline runs.

Prerequisites

Conceptual minimum

The three source kinds differ along one axis that dominates everything else: who decides the boundary.

With an administrative extract provider, the boundary is a country, state or region cut along real administrative edges, published on a fixed schedule. You take what is offered. The great advantage is that these providers publish per-region replication directories, which means you can keep a local copy current with small daily diffs instead of re-downloading gigabytes.

With a custom cut service, you specify a bounding box or a city and receive a file matching it. The fit is excellent and the file is small. The cost is that such cuts are generally one-off products: there is no replication directory for an arbitrary rectangle you invented, so staying current means re-requesting and re-downloading.

With the planet file, you take everything and cut it yourself. The boundary decision becomes entirely yours, including the strategy at the edge, and you inherit the canonical replication stream. You also inherit the storage, the processing time, and the operational responsibility for a cutting pipeline.

Choosing an OSM source from the shape of the area you actually need A decision node about how the area of interest relates to administrative boundaries, with three outcomes. If the area matches a published administrative region, an administrative extract provider gives the best fit with per-region replication included. If the area is a single city or an arbitrary rectangle used once, a custom cut service gives a small well-fitted file at the cost of having no replication path. If the area spans several countries or the boundary strategy matters, taking the planet file and cutting it yourself is the only approach that gives full control. Where does your area of interest actually sit? How does your area map to borders? Answer before comparing providers The fit decides everything else Administrative extract Area matches a published country, state or region Custom cut service One city or one rectangle, used once, no replication needed Planet, cut yourself Several countries, or edge behaviour must be controlled Choosing the middle branch for a recurring job is the most common mistake: a perfect fit with no replication path costs more every week.
The question is about geometry, not about provider features — the feature differences follow from the geometry answer.

The Comparison That Matters

The three source kinds compared on the five properties that drive real cost A grid of five properties against the three source kinds. Coverage fit is moderate for administrative extracts, excellent for custom cuts and perfect for a self-cut planet. Replication is available per region for administrative extracts, absent for custom cuts and canonical for the planet. Storage is moderate, small and very large respectively. Setup effort is minimal, minimal and substantial. Boundary control is none, limited to a rectangle, and complete. Five properties, and no source wins three of them Administrative Custom cut Planet Coverage fit moderate excellent perfect Replication per region none canonical Storage moderate small very large Setup effort minimal minimal substantial Boundary control none a rectangle complete The second row is the one that compounds: everything else is a one-off cost, and replication is a daily one.
Read this table top to bottom for a one-off analysis and bottom to top for a pipeline that will still be running next year.

Three observations follow that are easy to miss.

Surplus data is cheap; missing data is not. Taking a country extract when you need a city means filtering out ninety percent of it, which costs one extra pass with osmium tags-filter and a few minutes. Taking a city cut and later discovering your area of interest extends past its edge means going back to the drawing board. When the fit is uncertain, take the larger region.

Replication availability outranks file size. A slightly larger file you can update with a two-megabyte daily diff is cheaper within a week than a perfectly-sized file you must re-download. This is the single most common sizing mistake.

The planet file’s cost is mostly not storage. It is the cutting pipeline you now own: the boundary files, the strategy choice, the scheduled run, and the failure modes of all three. That is a real ongoing commitment, justified when you need several regions or when edge behaviour genuinely matters, and hard to justify for one country.

Cumulative bytes transferred over one month for a single country, by source strategy Four strategies compared on total transfer over thirty days for one country-sized area. Re-downloading a custom cut every day transfers the most despite the file being the smallest, because the whole file moves each time. Re-downloading an administrative extract daily transfers more per file but the same order of magnitude. Downloading an administrative extract once and applying daily replication diffs transfers a small fraction. Downloading the planet once and cutting locally transfers the most on day one and almost nothing afterwards. Thirty days of transfer, not one download Daily custom cut 30 full copies Daily administrative extract 30 copies Extract once, then diffs 1 copy + diffs Planet once, cut locally planet + diffs Comparing single download sizes makes the second row look worst; comparing a month of operation makes it the second best available option.
The planet bar is dominated entirely by day one, which is why it flattens for any pipeline expected to run for a year.

Boundary Behaviour Is a Real Difference

Every cut has to decide what happens to a way that crosses the boundary, and the options produce visibly different data. A complete-ways strategy includes every way that touches the region in full, along with the nodes outside the boundary needed to draw it — bigger file, clean geometry at the edge. A simple strategy takes only what is strictly inside, leaving ways truncated and referencing nodes that are not in the file.

For an analysis of land use inside a city, a truncated edge is irrelevant. For a routing graph, it is the difference between roads that connect to the outside world and a network with a ragged fringe of dead ends. The strategies and their consequences are worked through in Choosing Complete Ways vs Smart in osmium extract; the point here is that a published extract has already made this choice for you, and you should know which one before building a routing graph from it.

Verification

  • The area of interest fits inside the extract with margin. Compare your boundary against the extract’s declared bounding box; touching the edge is not good enough for routing.
  • A replication directory exists for the region. Check it before committing; discovering its absence after building an update pipeline is expensive.
  • The edge behaves as expected. Take a road that crosses the boundary and confirm it has usable geometry rather than dangling references.
  • The storage estimate includes the derived outputs. The extract itself is usually the smallest artefact in the pipeline.
  • A second region is cheap to add. If adding one more country means re-thinking the whole approach, the source choice is too tight.

Common errors and fixes

Symptom Root cause One-line fix
Re-downloading gigabytes daily Source has no replication directory Switch to a provider that publishes per-region diffs
Roads dead-end at the region edge Simple cut strategy in the published extract Take the surrounding region, or cut with complete ways
Area of interest grew past the file Cut sized to today’s requirement exactly Take the next region up; surplus is cheap to filter
Planet pipeline stalls on storage Sized on the planet file, not the working set Budget for the extract plus every derived artefact
Two regions with inconsistent edges Each cut independently with different strategies Cut all regions from one planet with one strategy
Update job never becomes cheaper Replication never adopted after the first download Wire the diff stream once the extract is in place

Specification reference

Regional extract providers publish files cut from the planet along administrative boundaries, accompanied by boundary polygon files and, for many regions, replication directories carrying the same hourly or daily diff format as the main replication stream. Custom extract services produce one-off files for a user-specified area and generally do not publish replication for them. See the OSM planet and extract documentation for the sources and their update cadences.

Frequently Asked Questions

Should I take a city extract or the surrounding country?

Take the country unless storage is genuinely tight. The surplus costs one filtering pass that runs in minutes and, more importantly, the administrative extract usually comes with a replication directory while the city cut does not. The cheaper-looking option that has to be re-downloaded in full every day is more expensive within a week, and it leaves you with no upgrade path when the area of interest grows.

When is the planet file genuinely the right choice?

When you need several regions and want their edges to be consistent, when the boundary strategy matters enough that you need to control it yourself, or when your area of interest does not correspond to any administrative unit anybody publishes. It is a real commitment — storage, processing time and a cutting pipeline you now maintain — so for a single country it is rarely worth it.

Does the boundary strategy really affect my results?

It depends entirely on what you are computing. For an analysis bounded to the inside of a region, truncated edges are irrelevant. For anything that traverses the network — routing, connectivity, catchment analysis — a cut that leaves ways without their outside nodes produces a graph with a ragged fringe of artificial dead ends, and every measurement near the boundary is wrong in a way that is hard to notice.

Can I mix sources for different regions?

You can, but their edges will not agree. Two regions cut by different services with different strategies will disagree about which features belong to the overlap, and a feature present in both may have different geometry in each. If the regions are analysed independently that is harmless; if they are merged, cut them all from one source with one strategy instead.

Up one level: OSM Extract Providers & Automated Downloads.