6 Python Libraries for Working With OpenStreetMap Data That Aren’t Just OSMnx

Discover powerful Python libraries for downloading, parsing, analyzing, and visualizing OpenStreetMap data beyond the familiar OSMnx workflow.

If you’ve done any geospatial work in Python over the last few years, chances are OSMnx was your first — maybe your only — door into OpenStreetMap. It’s a fantastic library. It made street network analysis accessible to people who’d otherwise have had to hand-roll graph extraction from raw PBF files, and for a huge chunk of urban analytics work, it’s still the right tool.

But OSMnx is built around one job: pulling street networks and simple feature queries into NetworkX graphs and GeoDataFrames. The moment your work moves outside that lane — parsing a full country extract, streaming through a multi-gigabyte PBF without blowing up your RAM, hitting the Overpass API for something that isn’t roads, or converting raw OSM tags into clean GeoJSON for a web map — OSMnx starts to strain, and you end up bolting on other tools anyway.

I’ve hit this wall repeatedly doing land-use and infrastructure mapping across East Africa, where OSM coverage is patchy in places and dense in others, and where a single country PBF (Kenya, Uganda, Tanzania) is often the fastest way to get real road, building, and land-use data without waiting on satellite-derived alternatives. Pulling that data efficiently, and getting it into a shape you can actually work with, takes a different toolkit than what OSMnx offers out of the box.

Here are six libraries that fill those gaps — each one solving a problem OSMnx either handles poorly or doesn’t touch at all.

1. Pyrosm — for fast, full-extract parsing

Pyrosm is what you reach for when OSMnx starts timing out or eating memory. It’s built on top of a C++ PBF reader and is designed specifically to parse large .osm.pbf extracts — think entire countries — into GeoDataFrames quickly. Where OSMnx queries the Overpass API or works region-by-region, Pyrosm reads local PBF files directly, which means no rate limits, no network dependency, and dramatically faster processing on large areas.

For a typical workflow, you’d download a country extract from Geofabrik (Kenya’s is a manageable size), then pull buildings, roads, or points of interest with a couple of method calls. It’s the tool I reach for first when a client wants building footprints for an entire county rather than a single town.

2. Pyosmium — for streaming through anything, at any scale

Pyosmium is the Python binding for libosmium, the C++ library that most serious OSM tooling is built on. It’s lower-level than Pyrosm — you write handler classes that process nodes, ways, and relations as the library streams through a file — but that low-level control is exactly the point. You can process planet-scale extracts without ever loading the whole thing into memory, filter on tags as you go, and write custom logic for edge cases that higher-level libraries don’t anticipate.

This is the tool for when you need something OSMnx and Pyrosm both can’t offer: full control over how relations (like multipolygon boundaries or bus routes) get assembled, and the ability to process files far larger than what fits in RAM. It has a steeper learning curve, but if you’re doing production data pipelines rather than one-off analysis, it earns that curve back quickly.

3. OSMPythonTools — for Overpass queries beyond roads

OSMnx’s Overpass integration is narrow by design — it’s built to fetch network and simple feature data, not to give you the full expressiveness of the Overpass QL. OSMPythonTools wraps Overpass, Nominatim, and the OSM API in a more general-purpose interface, letting you write arbitrary Overpass queries and get structured Python objects back.

This matters when you’re after something specific: every school within a ward boundary, every borehole tagged in a rural area, or administrative boundaries with particular tag combinations. I’ve used it for pulling health facility points in Nairobi’s informal settlements, where the tagging is inconsistent enough that you need a flexible query rather than OSMnx’s fixed feature-tag interface.

4. osm2geojson — for turning raw OSM JSON into usable geometry

If you’re querying Overpass directly (with OSMPythonTools, requests, or overpy), you get back OSM’s native JSON structure — nodes, ways, and relations referencing each other by ID. It’s not directly usable as geometry. osm2geojson does the unglamorous but essential work of converting that structure into proper GeoJSON, handling the node-to-way-to-polygon assembly for you, including multipolygon relations.

It’s a small library and it does one thing, but that one thing is the connective tissue between “I have an Overpass response” and “I have a GeoDataFrame.” Any pipeline that queries Overpass directly rather than through OSMnx will eventually need something like this.

5. QuackOSM — for SQL-speed extraction with DuckDB

QuackOSM is newer and less well known, but it’s become one of my go-to tools for quick exploratory work. It uses DuckDB’s spatial extension to read PBF files and lets you query OSM data with SQL — filtering by tags, bounding boxes, or geometry type — and get results back as GeoParquet or GeoDataFrames.

The appeal is speed combined with familiarity: if you already think in SQL, filtering a country extract down to “all buildings tagged residential within this polygon” is a one-liner, and DuckDB’s columnar engine makes it fast even on large files. For quick data exploration before committing to a full Pyrosm or Pyosmium pipeline, it’s hard to beat.

6. pyogrio (with GDAL’s OSM driver) — for a no-frills GDAL-native path

This one surprises people because it’s not an “OSM library” at all — it’s a fast GeoPandas I/O backend. But GDAL has a native OSM driver, and pyogrio (which GeoPandas now uses under the hood for I/O) can read .osm.pbf files directly through it. For simple cases — you just want points, lines, or multipolygons out of a PBF without extra tooling — this is the path of least resistance, especially if GDAL is already central to your stack (as it usually is if you’re working with Rasterio and PostGIS).

It won’t give you the tag-handling sophistication of Pyrosm or the control of Pyosmium, but for quick one-off reads, not needing to install another dependency is worth something.

None of these replace OSMnx — for street network graphs and walkability or connectivity analysis, it’s still the right default. But treating OSMnx as the only OSM library in Python means either forcing every problem into its shape or quietly falling back to raw Overpass requests and manual JSON parsing, which is its own kind of technical debt.

The right choice depends on what you’re actually doing: Pyrosm or QuackOSM for fast extraction from local extracts, Pyosmium when scale or custom relation logic demands it, OSMPythonTools when you need Overpass’s full query power, osm2geojson as the glue when you’re working with raw API responses, and pyogrio when you just want geometry out of a file with minimal ceremony. Knowing which one to reach for — rather than defaulting to OSMnx and working around its limits — is what separates a working script from a pipeline you can actually run on a country’s worth of data.

If you’re doing OSM-heavy work in a region like East Africa, where extract sizes are manageable but data quality varies block by block, this is doubly true. The library you pick often matters less than knowing you have six of them to choose from.