Transportation Guide
Every time you ask for directions, hail a ride, or check a map, you're relying on a model of how the world's roads, rails, and waterways connect. The Overture transportation theme is such a model: a global, open dataset of traversable segments (roads, railways, ferries) and connectors (intersections) representing how people and objects travel, built from OpenStreetMap and enhanced with data from TomTom and other local and regional authoritative data sources.
The dataset is simple at its core but expressive enough to capture highway speed limits that change by time of day, one-way streets that allow buses to go the wrong way, and weight-restricted bridges with axle limits.
You might use Overture transportation data for mapping, routing, navigation, or geocoding street intersections. For the full schema details, see the reference documentation.
In this guide
This overview covers the feature types, dataset construction, and access for the transportation theme. The deeper topics are covered in the rest of the guide:
- Segments and connectors: The building blocks of the network. Segments are the paths; connectors are the junctions where they meet. This page covers how they combine to form a routable graph, along with orientation, heading, and how Overture decides where to split a road.
- Linear referencing: How properties can apply to just part of a segment — say, the first 500 meters — without chopping the geometry in two. Includes calculation methods and code examples.
- Scoping and travel modes: The rule system that makes properties conditional. A speed limit might apply only to trucks, only on weekdays, or only in the forward direction. Scoping is how all of that gets expressed.
- Roads: The details specific to road segments — access restrictions, turn restrictions, speed limits, and more.
Dataset description
Feature type descriptions
The Overture transportation schema defines two feature types:
- The segment type has a LineString geometry that represents the center-line of a path repeatedly traversed by people or objects. Segment properties describe both the physical properties (e.g. road surface and width) and non-physical properties (e.g. access restriction rules) of that path.
- The connector type has a Point geometry that represents the physical positions where two or more segments meet. While topology is defined by the connectors field within the segment type, the connector type provides a convenient, queryable list of those connection points. Connectors do not have properties beyond geometry and the common properties required for all Overture features.
A more detailed overview of these feature types can be found in segments and connectors.
Subtypes, classes, and subclasses
Transportation segments are divided into three subtypes: rail, water, and road. These subtypes are further divided into a variety of different classes based on usage captured in the table below.
Class and subclass feature counts
- classes
| subtype | class | subclass | feature count, July 2026 |
|---|---|---|---|
| rail | funicular | NULL | 1,391 |
| rail | light_rail | NULL | 16,760 |
| rail | monorail | NULL | 3,122 |
| rail | narrow_gauge | NULL | 31,162 |
| rail | standard_gauge | NULL | 1,473,855 |
| rail | subway | NULL | 56,757 |
| rail | tram | NULL | 59,567 |
| rail | unknown | NULL | 395,546 |
| road | bridleway | NULL | 103,412 |
| road | cycleway | cycle_crossing | 69,228 |
| road | cycleway | NULL | 1,362,782 |
| road | footway | crosswalk | 2,565,686 |
| road | footway | sidewalk | 4,182,074 |
| road | footway | NULL | 17,555,637 |
| road | living_street | NULL | 3,462,411 |
| road | motorway | link | 666,326 |
| road | motorway | NULL | 452,796 |
| road | path | NULL | 14,233,189 |
| road | pedestrian | NULL | 478,146 |
| road | primary | link | 511,511 |
| road | primary | NULL | 6,909,974 |
| road | residential | NULL | 127,924,491 |
| road | secondary | link | 403,804 |
| road | secondary | NULL | 10,987,290 |
| road | service | alley | 1,905,804 |
| road | service | driveway | 18,183,689 |
| road | service | parking_aisle | 6,686,059 |
| road | service | NULL | 34,716,993 |
| road | steps | NULL | 2,038,003 |
| road | tertiary | link | 308,067 |
| road | tertiary | NULL | 20,443,534 |
| road | track | NULL | 26,362,502 |
| road | trunk | link | 585,420 |
| road | trunk | NULL | 3,581,288 |
| road | unclassified | NULL | 30,162,788 |
| road | unknown | NULL | 9,762,921 |
| water | NULL | NULL | 28,916 |
Column definitions
Column definitions for the transportation theme are generated from the schema and live in the schema reference: segment and connector.
Sources and licensing
The transportation theme's primary source is OpenStreetMap, enhanced with commercial road data from TomTom and other local and regional authoritative sources. Because it includes OpenStreetMap data, the transportation theme is published under the ODbL license. See the licensing and attribution page for more information.
How we build the dataset
Filtering. Duplicate nodes are removed based on location and properties, and OSM segments are filtered to the specific highway values currently in scope. The highway values in scope are:
railway, construction, cycleway, footway, living_street, motorway, motorway_link, path, pedestrian, primary, primary_link, residential, road, secondary, secondary_link, service, steps, tertiary, tertiary_link, track, trunk, trunk_link, unclassified.
Matching. TomTom roads are matched to OSM using Orbis as part of OSM ingestion. If public OSM needs updating (e.g., a road is removed or rerouted), the road must be reassigned or removed from the TomTom road, and public OSM will be updated directly.
Merging. OSM segments are merged into Orbis as part of ingestion, with ongoing integration of the TomTom legacy network.
Coverage and data quality
Coverage. The transportation theme provides global coverage.
Quality assurance. The theme is checked and normalized against a number of quality signals, including:
- Presence of navigational islands
- Road name gap detection
- Road sharp turn detection
- Normalization of data, including dropping unrealistic outliers
- Overlap/duplicate highway detection
- Invalid intersection detection
Excluded by design
The transportation theme deliberately excludes:
- Open, navigable spaces like fields, parks, or oceans
- Aerial paths, such as flight paths or geostationary satellite orbits
- Paths traversed by continuous entities: oil pipelines, electric lines
Release artifacts and updates
The transportation theme is released on a monthly cadence. Alongside the data, the following release artifacts are provided:
- GERS registry: Transportation features are included in the GERS registry.
- GERS IDs: Assigned to segment and connector features.
- Bridge files: Provided.
- Data changelog: A changelog accompanies each release.
Data access and retrieval
Overture's transportation theme data is freely available on both Amazon S3 and Microsoft Azure Blob Storage at these locations:
- Segment
- Connector
| provider | location |
|---|---|
| Amazon S3 | |
| Azure Blob Storage | |
| provider | location |
|---|---|
| Amazon S3 | |
| Azure Blob Storage | |
We recommend downloading only the Overture data you need. If you have a particular geographic area of interest, there are several options for using a simple bounding box to extract data and output a GeoJSON file.
- Python Client
- DuckDB
First, follow the setup guide for the Python Client.
Set type to either segment or connector and simply alter the bbox value to download a particular area.
overturemaps download --bbox=12.46,41.89,12.48,41.91 -f geojson --type=segment -o rome_segments.geojson
First, follow the setup guide for DuckDB.
Set the parquet link to either the connector or segment url depending on your needs.
Replace the bbox.xmin and bbox.ymin values with a new bounding box to run the query for a different area.
LOAD spatial; -- noqa
LOAD httpfs; -- noqa
-- Access the data on AWS in this example
SET s3_region='us-west-2';
COPY (
SELECT
*
FROM read_parquet('s3://overturemaps-us-west-2/release/2026-07-22.0/theme=transportation/type=segment/*')
WHERE
bbox.xmin > 12.46 AND bbox.xmax < 12.48 AND
bbox.ymin > 41.89 AND bbox.ymax < 41.91
)
TO 'rome_segments.parquet';
Querying and analysis
Querying by properties in DuckDB
These examples use data properties to filter the data in useful ways using DuckDB.
- Query by class
- Query by routes
The class column can be used to pull out subsets of the road data. Similarly, you could use subtype to select only water, rail, or road features. This example extracts only the parking_aisle features within the bounding box.
LOAD spatial; -- noqa
LOAD httpfs; -- noqa
-- Access the data on AWS in this example
SET s3_region='us-west-2';
COPY (
SELECT
*
FROM read_parquet('s3://overturemaps-us-west-2/release/2026-07-22.0/theme=transportation/type=segment/*')
WHERE
class = 'parking_aisle' AND
bbox.xmin > 13.0897 AND bbox.xmax < 13.6976 AND
bbox.ymin > 52.3100 AND bbox.ymax < 52.7086
)
TO 'berlin_parking_aisles.parquet';
You might be interested in a network of roads, such as a US Interstate. These can be extracted using the routes column and either using the network and ref properties and/or the wikidata column to identify the route.
This example extracts all the roads that are part of US I-5. To get all US Interstates simply remove AND routes[1].ref = '5' from the query.
LOAD spatial; -- noqa
LOAD httpfs; -- noqa
-- Access the data on AWS in this example
SET s3_region='us-west-2';
COPY (
SELECT
*
FROM read_parquet('s3://overturemaps-us-west-2/release/2026-07-22.0/theme=transportation/type=segment/*')
WHERE
routes[1].network = 'US:I'
AND routes[1].ref = '5'
)
TO 'US_I_5.parquet';
Querying by properties in Athena
Athena can allow for faster querying of the transportation layer than DuckDB given the size of the data. These examples are designed for Athena, but could be reworked for DuckDB with some tweaking.
- Query by speed limit
- Select connecting segments
To properly return a linear referenced feature like a speed limit, we will need to query all the possible values of the feature as the queried value may only exist on one portion of the line. In this example, we're extracting roads with any speed limit max_speed value of 27 and unit of mph using the any_match function.
This same general query would also work for querying other similar columns such as prohibited_transitions and access_restrictions.
SELECT
id,
speed_limits,
ST_GEOMFROMBINARY(geometry) AS geometry
FROM v2026_07_22_0
WHERE type = 'segment'
AND ANY_MATCH(
speed_limits,
speed_limit->speed_limit.max_speed.value = 27
AND speed_limit.max_speed.unit = 'mph'
)
With the connectors column it is simple to query for all features that connect with a particular segment without the need for a spatial query.
This example selects all the segments that that connect to the example id.
WITH input AS (
SELECT id AS input_id,
connector_id
FROM v2026_07_22_0
CROSS JOIN UNNEST(connectors) AS t(connector)
WHERE type = 'segment'
AND id = '08628d5437ffffff0473ffc36df547db'
)
SELECT
*,
ST_GEOMFROMBINARY(geometry) AS geometry
FROM v2026_07_22_0,
input
WHERE type = 'segment'
AND id != input_id
AND ANY_MATCH(
connectors,
connector->connector.connector_id = input.connector_id
)
Tools and libraries
transportation-splitter
![]() |
|---|
| Conceptual diagram of the splitter tool output. The numbers following 1234@ represent start_lr and end_lr values. |
The transportation-spitter tool transforms Overture road data into simpler sub-segments. It will optionally divide features at each connector point and at each change of a scoped based property, depending on configuration. Depending on your needs and map stack, the resulting dataset may be easier to manipulate than the original Overture data as each segment will only have connections at either end and have one set of properties for its entire length.
Since a GERS ID will no longer be unique with this output, the resulting data will have two additional columns: start_lr and end_lr which are linear references describing which section of the original feature this new segment comes from.
Splitter example
To help visualize this process better, here is a real-world example of a residential street in OpenStreetMap, Overture, and after being run through the splitter tool.
- OpenStreetMap
- Overture
- Transportation Splitter
![]() |
|---|
| In OpenStreetMap this residential road is represented by two different features with the same tags with feature 1 having an additional restricted access tag. |
![]() |
|---|
| In Overture the two segments have been combined into one feature and the restricted access tag has been stored as this linear reference in access_restrictions: |
[{'access_type': allowed, 'when': {'during': , 'heading': , 'using': , 'recognized': [as_private], 'mode': , 'vehicle': }, 'between': [0.521962729, 1.0]}] |
![]() |
|---|
| The splitter has sliced the Overture feature at each connector point for the driveways as well as at the point where the access restriction begins. This results in six unique features in the output all still sharing the same GERS ID. |
More information and feedback
The tool requires a Spark environment to run and has been tested using Azure Databricks and AWS Glue. For setup information the transportation-spitter GitHub will contain the most up-to-date information as the tool is in active development still.
If you have feedback, questions, etc. on the tool you can create an issue on the GitHub.



