# Build a routing .glx file with the geolith builder (in development)

> How the geolith builder writes the routing part of a .glx file from an OpenStreetMap extract with geolith --output-format routing, and adds historical speeds with --routing-predicted-speeds. Routing is in development and not deployed.

---
title: Build a routing .glx file with the geolith builder (in development)
description: 'How the geolith builder writes the routing part of a .glx file from an OpenStreetMap extract with geolith --output-format routing, and adds historical speeds with --routing-predicted-speeds. Routing is in development and not deployed.'
date: '2026-11-08'
tags: [routing, builder, glx, valhalla]
minutes: 8
product: routing
faqs:
  - q: Can I download the builder and run this myself?
    a: Not yet. The builder is not distributed; this guide shows the commands geolith runs to build its own routing files, so you can plan for them.
  - q: Does my Valhalla traffic data work?
    a: Yes, that is the design. --routing-predicted-speeds reads the CSV format of Valhalla's valhalla_add_predicted_traffic tool, one file per graph tile.
---

**Status: routing is in development and not deployed.** There is no routing endpoint on geolith.app or api.geolith.app, and no routing plan, price or key. The builder is not distributed yet: this guide shows how geolith builds its own routing files.

The geolith builder turns an OpenStreetMap extract into a road graph and writes it as the **routing part** of a `.glx` file. A router reads that one file, with no database. On Berlin, the router answers from geolith-built files with JSON byte-identical to Valhalla 3.9.1 (see [routing accuracy](/routing/accuracy)).

## Build the routing part

```bash
geolith --output-format routing \
  --osm-pbf berlin.osm.pbf \
  --routing-output berlin-routing.glx
```

- `--output-format routing` builds the routing graph instead of map tiles.
- `--osm-pbf` is the OpenStreetMap extract (`.osm.pbf`).
- `--routing-output` is the `.glx` file to write. It holds one routing part: a routing header, a tile index, a zstd dictionary and the graph tiles, each cut into 64 KiB blocks that a router reads one range at a time.

## Add historical speeds

Pass a directory of speed files and the router uses them for requests with a `date_time`:

```bash
geolith --output-format routing \
  --osm-pbf berlin.osm.pbf \
  --routing-output berlin-routing.glx \
  --routing-predicted-speeds speeds/
```

The directory holds one CSV file per graph tile, named by its tile path (for example `speeds/2/000/753/554.csv`), one row per directed edge:

```csv
edge_graph_id,free_flow_kph,constrained_kph,encoded_dct
2/753554/120,52,38,AbC...==
```

The format is the one Valhalla's `valhalla_add_predicted_traffic` tool reads, so data that already targets Valhalla works unchanged. Edge ids change with every graph build, so map your speeds to edges for each build. The full field list is in the [traffic docs](https://docs.geolith.app/routing/traffic).

## What the file is for

The routing `.glx` file is what a self-hosted router serves: see [self-host the geolith router from a .glx file](/guides/self-host-geolith-routing). A file can also hold a search part; each reader reads only its own part.


Routing is in development and not deployed; there is no endpoint to call yet, and no routing plan, price or key. Read the routing docs: https://docs.geolith.app/routing