Osmix is a TypeScript toolkit we built to bring street network preparation workflows out of desktop GIS and into the browser. On an M2 MacBook Air, it can parse, index, and render the entire Washington state street network — roughly 200MB of OpenStreetMap (OSM) PBF — in under 45 seconds. It performs that all locally, with no backend server involved.
At Conveyal, we turn street networks, transit schedules, and geospatial layers into accessibility results. OSM PBF extracts are a core input for that work.
Planning teams routinely evaluate future conditions that are not included in OpenStreetMap.org and proposing them there is not always straightforward. A planner might need to model a proposed trail network, a highway widening and interchange reconfiguration, or a pedestrian realm redesign and those scenarios still need a complete, routable street network that includes the proposed changes.
Recently, one part of this process had felt stuck: preparing and merging multiple street data layers. Teams collaborate in modern web tools, but large PBF ingestion and patch validation often send them back to desktop software or one-off command-line scripts.
Tools like JOSM, QGIS, and Osmium are great — but the workflow often becomes a chain of manual, hard-to-reproduce steps. That gap in tooling became clear while working with one of our clients, Washington State DOT (WSDOT).
WSDOT & OpenSidewalks
The WSDOT team scoped a statewide effort to integrate OpenSidewalks data into accessibility analysis workflows and publish the resulting framework as part of Washington’s 2026 Statewide Public Transportation Plan process. The Taskar Center for Accessible Technology awarded a Specialized Community-Led Impact Opportunity grant to help support this effort. WSDOT partners with the project to map pedestrian infrastructure — sidewalks, crossings, curb cuts — and can export that data as OSM PBF. The export is a diff, not a full network. To make it usable for routing and accessibility analysis we treat it as a patch and merge it onto a base OSM extract.
In practice, that means loading a base street network and a patch, indexing both, checking for duplicates, then merging — adding new entities, deduplicating shared ones, and stitching intersections where the geometries cross. Previously, this merge step relied on desktop tooling and manual handoffs, which did not match Conveyal’s web-based collaboration model.
To streamline WSDOT workflows, we proposed developing an open-source, browser-based merge tool to join sidewalk data from OpenSidewalks with OSM layers and produce PBF outputs for Conveyal Analysis and R5. We realized quickly that such tooling could even be general enough to handle any OSM merge scenario — and that what we were building was a general toolkit, not a one-off application or script.
A browser-first OSM toolkit
Osmix is our browser-first TypeScript toolkit for OpenStreetMap workflows at country scale. It combines PBF ingestion, in-memory indexing, merge operations, and spatial query utilities. With Osmix, the browser doesn’t just visualize street network data — it is able to parse, edit, and output street networks fast enough for real work.
At a high level, using Osmix can be simple:
import { fromPbf, merge } from "osmix"const baseOsm = await fromPbf(baseOsmPbf)
const patchOsm = await fromPbf(patchOsmPbf)
const mergedOsm = await merge(baseOsm, patchOsm)
The `osmix` package is the high-level entry point. Underlying packages — `@osmix/core`, `@osmix/pbf`, `@osmix/change`, and others — are independently installable if you only need specific capabilities. All are on npm.
Osmix keeps OSM data compact: entities are stored in typed arrays, coordinates in numeric arrays, and tags as indices into a shared string table. It builds spatial indexes on load (KDBush for points, Flatbush for bounding boxes), so bbox and nearest-neighbor queries are fast out of the gate. Most work happens off the main thread, and with SharedArrayBuffer enabled, workers can operate on the same dataset without copying it back and forth — so a parser, query engine, tile renderer, and merge worker can all share one full extract.
The Merge Tool
With Osmix, we built a merge tool that can complete the WSDOT workflow in just a few minutes. The tool walks through the process step by step: load a base network and a patch network, inspect each for internal duplicates, preview the changeset before applying it, deduplicate nodes across both datasets, stitch new intersections where ways cross, and download the merged network PBF file. Each step shows a live map view and a reviewable list of changes — both a “verify each step” and a “run all steps at once” mode are available.
Beyond PBF Merge
While the merge workflow drove initial development, the toolkit covers a broader range of OSM-based work. On the input side, Osmix can load PBF, GeoJSON, Shapefiles, and the GeoParquet format produced by Overture Maps and OSM US. On the output side, on top of exporting PBF, `@osmix/geojson` handles OSM to GeoJSON conversion and `@osmix/vt` generates Mapbox Vector Tiles-compliant tiles. Osmix also runs in Node.js, Bun, and Deno — the same packages work in a build pipeline and in the browser. Each package is independently installable as an ES module.
That first use case also pointed to a larger opportunity: collaborative, browser-native OSM workflows for teams that historically depended on desktop GIS for every heavy step. For us, that means faster iteration, clearer review across technical roles, and a cleaner path from “proposed network change” to “measurable accessibility impact.”
The goal is not to replace powerful desktop GIS tools. It is to enable creating tools that remove the friction where it hurts most — the handoffs, the manual steps, the context switches that slow teams down.
Osmix is MIT-licensed, published on npm, and built to handle real datasets at real scale. If you work with OSM data in planning, accessibility analysis, or any workflow that currently sends you back to a terminal or desktop tool, it is worth a look. The documentation has live examples you can run against your own PBF files. Source and issues are on GitHub at conveyal/osmix.
Special thanks the Taskar Center for Accessible Technology and to Thomas Craig and Kurt Winner at WSDOT, who helped drive this development forward.