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 paths people and vehicles 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 — just two feature types, segment and connector — 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. Three subtypes within segment cover road, rail, and water transportation.

The rest of this page covers the feature types and subtypes, describes the dataset and how to access it, and points to tools and libraries for working with the data. 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.

You might use Overture transportation data for mapping, routing, navigation, or geocoding street intersections. For the full schema details, see the reference documentation.

Feature types

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, March 2026
rail	funicular	NULL	1,354
rail	light_rail	NULL	16,766
rail	monorail	NULL	3,066
rail	narrow_gauge	NULL	30,345
rail	standard_gauge	NULL	1,461,792
rail	subway	NULL	54,987
rail	tram	NULL	59,385
rail	unknown	NULL	390,616
road	bridleway	NULL	102,186
road	cycleway	cycle_crossing	64,492
road	cycleway	NULL	1,325,142
road	footway	crosswalk	2,426,146
road	footway	sidewalk	3,945,829
road	footway	NULL	16,944,293
road	living_street	NULL	3,404,804
road	motorway	link	648,337
road	motorway	NULL	439,095
road	path	NULL	13,963,796
road	pedestrian	NULL	473,165
road	primary	link	503,321
road	primary	NULL	6,820,001
road	residential	NULL	126,985,903
road	secondary	link	397,889
road	secondary	NULL	10,876,018
road	service	alley	1843,302
road	service	driveway	17,643,423
road	service	parking_aisle	6,556,473
road	service	NULL	34,096,464
road	steps	NULL	1,971,731
road	tertiary	link	304,286
road	tertiary	NULL	20,253,458
road	track	NULL	25,956,126
road	trunk	link	569,758
road	trunk	NULL	3,516,259
road	unclassified	NULL	29,951,857
road	unknown	NULL	8,959,680
water	NULL	NULL	28,710

Data dictionary

All Overture data, including transportation data, is distributed as GeoParquet, a column-based data structure. Below you'll find tables with column-by-column descriptions of the properties for the segment and connector feature types.

Column definitions in the transportation theme

segment

column	type	description
id	string	A feature ID. This may be an ID associated with the Global Entity Reference System (GERS) if—and-only-if the feature represents an entity that is part of GERS.
geometry	binary	The line representation of the segment's location. Segment's geometry which MUST be a LineSting as defined by GeoJSON schema.
bbox	struct	Area defined by two longitudes and two latitudes: latitude is a decimal number between -90.0 and 90.0; longitude is a decimal number between -180.0 and 180.0.
version	integer	Version number of the feature, incremented in each Overture release where the geometry or attributes of this feature changed.
sources	struct	The array of source information for the properties of a given feature, with each entry being a source object which lists the property in JSON Pointer notation and the dataset that specific value came from. All features must have a root level source which is the default source if a specific property's source is not specified.
subtype	string	The broad category of transportation segment.
class	string	Captures the kind of road and its position in the road network hierarchy.
names	struct	Properties defining the names of a feature.
connectors	struct	Array of connector IDs identifying the connectors this segment is physically connected to linearly referenced with their location. Each connector is a possible routing decision point, meaning it defines a place along the segment in which there is possibility to transition to other segments which share the same connector.
routes	struct	Routes this segment belongs to.
subclass_rules	struct	Defines the portion of a road that the subclass applies to.
access_restrictions	struct	Rules governing access to this road segment or lane.
level_rules	struct	Defines the Z-order, i.e. stacking order, of the road segment.
destinations	struct	Describes objects that can be reached by following a transportation segment in the same way those objects are described on signposts or ground writing that a traveller following the segment would observe in the real world. This allows navigation systems to refer to signs and observable writing that a traveller actually sees.
prohibited_transitions	struct	Defines where traveling from the segment to another is disallowed for navigation. This covers things situations prohibited turns or a transition from road to bike lane disallowing cars.
road_surface	struct	Defines the surface material on a road such as paved, asphalt, or unpaved.
road_flags	struct	Additional properties relevant to roads such as is_bridge or is_under_construction.
speed_limits	struct	Defines the speed limit of the road segment.
width_rules	struct	Defines the width of the road segment for rendering.
subclass	string	Specifies the usage of a length of road.
rail_flags	struct	Additional properties relevant to rail such as is_tunnel or is_freight.
filename	string	Name of the file being queried.
theme	string	Name of the Overture theme being queried.
type	string	Name of the Overture feature type being queried.

connector

column	type	description
id	string	A feature ID. This may be an ID associated with the Global Entity Reference System (GERS) if—and-only-if the feature represents an entity that is part of GERS.
geometry	binary	The line representation of the segment's location. Segment's geometry which MUST be a LineSting as defined by GeoJSON schema.
bbox	struct	Area defined by two longitudes and two latitudes: latitude is a decimal number between -90.0 and 90.0; longitude is a decimal number between -180.0 and 180.0.
version	integer	Version number of the feature, incremented in each Overture release where the geometry or attributes of this feature changed.
sources	struct	The array of source information for the properties of a given feature, with each entry being a source object which lists the property in JSON Pointer notation and the dataset that specific value came from. All features must have a root level source which is the default source if a specific property's source is not specified.
filename	string	Name of the file being queried.
theme	string	Name of the Overture theme being queried.
type	string	Name of the Overture feature type being queried.

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

provider	location
Amazon S3	s3://overturemaps-us-west-2/release/2026-03-18.0/theme=transportation/type=segment/*
Azure Blob Storage	https://overturemapswestus2.blob.core.windows.net/release/2026-03-18.0/theme=transportation/type=segment/*

Connector

provider	location
Amazon S3	s3://overturemaps-us-west-2/release/2026-03-18.0/theme=transportation/type=connector/*
Azure Blob Storage	https://overturemapswestus2.blob.core.windows.net/release/2026-03-18.0/theme=transportation/type=connector/*

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

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

DuckDB

First, follow the [setup guide for DuckDB (/getting-data/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-03-18.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 transportation data

Querying by properties in DuckDB

These examples use data properties to filter the data in useful ways using DuckDB.

Query by class

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-03-18.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';

Query by routes

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-03-18.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

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_03_18_0
WHERE type = 'segment'
    AND ANY_MATCH(
        speed_limits,
        speed_limit->speed_limit.max_speed.value = 27
        AND speed_limit.max_speed.unit = 'mph'
	)

Select connecting segments

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_03_18_0
		CROSS JOIN UNNEST(connectors) AS t(connector)
	WHERE type = 'segment'
		AND id = '08628d5437ffffff0473ffc36df547db'
)
SELECT
    *,
	ST_GEOMFROMBINARY(geometry) AS geometry
FROM v2026_03_18_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

In OpenStreetMap this residential road is represented by two different features with the same tags with feature 1 having an additional restricted access tag.

Overture

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]}]

Transportation Splitter

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.

Get support

Overture is an open project and we welcome feedback, questions, and bug reports through our public GitHub repositories.

Where to go. Use GitHub Discussions for general questions, workflow help, feature suggestions, or broader conversations about Overture. Use GitHub Issues in the data repository or the schema repository for specific bug reports: missing entities, geometry problems, duplicate records, or country-specific data concerns.

What to expect. We review incoming issues regularly and try to respond within a few business days, but we can't guarantee a resolution timeline. Issues that affect data integrity or block common workflows get higher priority.

Filing a good issue. The more detail you include, the faster we can help. When reporting a data problem, please include: the Overture release version you're using, a query or code snippet that reproduces the issue, specific entity IDs or bounding boxes where you see the problem, and any relevant screenshots or map views. If you can share a minimal reproducible example, that goes a long way.