OpenSidewalks Schema

OpenSidewalks Schema⚓︎

The OpenSidewalks Schema is an open pedestrian transportation network data standard for describing and sharing pedestrian network and pedestrian network-adjacent data. The OpenSidewalks Schema promotes an explicit network (graph) model wherein its primary data entities can be deterministically transformed into graph Edges and graph Nodes.

Therefore, OpenSidewalks Schema data represents a traversable and graph-analyzable network of (conditional) pedestrian paths like sidewalks, street crossings, some streets, and other paths, as well as metadata representing potential barriers.

The OpenSidewalks Schema is explicitly a network schema: its primary features are defined and interpreted as elements of a network (or graph), i.e. Nodes and Edges. Therefore, OpenSidewalks Schema data is understood not only as a set of features describing pedestrian infrastructure, but as connected elements of a pedestrian network.

The OpenSidewalks Schema draws from and is intended to be largely compatible with OpenStreetMap data, though it is possible to create OpenSidewalks Schema data not derived from OpenStreetMap.

Transportation Data Exchange Initiative⚓︎

Validation, ingestion, and downstream use of the OpenSidewalks Schema are supported by tooling developed and maintained through the Transportation Data Exchange Initiative (TDEI).

TDEI provides both user-facing interfaces and programmatic APIs that enable schema validation, quality assurance, dataset management, and access for OpenSidewalks-compliant data. These tools support data producers, stewards, and consumers in publishing and using standardized pedestrian infrastructure datasets at scale.

Metrics⚓︎

As of January 2026, the TDEI system hosts over 5600 complete OpenSidewalks-validated and vetted datasets, representing more than 10.5 million crossings and almost 400,000 miles of sidewalks, with ongoing updates and expansion. These datasets have passed schema validation and TDEI quality control workflows prior to publication. For current metrics of OpenSidewalks data in the TDEI, please refer to the TDEI Performance Dashboard.

Validation⚓︎

An OpenSideWalks Schema validator is available as a Python library and as a Job Type in the TDEI Portal:

• Library:

  • PyPI: python-osw-validation

  • GitHub: TaskarCenterAtUW/TDEI-python-lib-osw-validation

• Service:

  • TDEI Portal: Create Job: "OSW - Validate" (Dataset-Validate)

  • GitHub: TaskarCenterAtUW/TDEI-python-osw-validation

OpenSidewalks Schema Entities⚓︎

The OpenSidewalks Schema defines network and non-network data using a set of vector geometrical entity types, each of which has an associated geometry type compatible with either the Point, LineString, or Polygon specification of Simple Feature Access, fields that uniquely define the entity type (in combination), optional topological information, and optional key-value pair metadata fields defined on a per-type basis.

Entity Categories⚓︎

There are currently two major categories of OpenSidewalks Schema entities: Core Entities and Adjacent Entities.

1. Core Entities⚓︎

Core Entities are the traversable entities which make up the OpenSidewalks pedestrian network.

There are three types of core entity models:

• Nodes
• Edges
• Zones

Nodes, Edges, and Zones are geometrical features (OGC Points, LineStrings and Polygons, respectively) with network primitives defined such that a network (or graph) can be constructed purely from their metadata. Examples of each entity model:

• Node: a raise curb.
• Edge: a sidewalk.
• Zones: a square or plaza.

Nodes⚓︎

Nodes are Point features (as defined in Simple Feature Access) that also contain metadata to identify them as network (graph) vertices. They must have a unique (within the dataset) _id field. Therefore, the set of network vertices in the dataset could be summarized as a set of these _id field values, consistent with the definition of vertices within a graph in graph theory. As a result of storing these vertex identifiers, Nodes may be placed within a traversable graph using only metadata, not spatial inference.

Edges⚓︎

Edges are linear features that also contain metadata to identify them as network (graph) Edges. They must have two Node-referencing fields: _u_id and _v_id, which mean "this linear feature begins at the Node with _id of _u_id and ends at the Node with _id of _v_id. Therefore, a network (graph) may be constructed from a set of Nodes and Edges directly from metadata. Outside of the graph representation, Edges must have a unique (within the dataset) _id field.

Note that Edges are directional features: they start at one Node and end at one Node. The data they represent is directional as well: their geospatial data must start at one location and end at another and Edges often have fields like incline that only have meaning when direction is understood: a positive incline value is uphill while a negative incline value is downhill. However, this does not mean that datasets must be curated with both "forward" (u to v) Edges and "reverse" (v to u) Edges: any "reverse" Edge can be inferred during graph creation.

Zones⚓︎

Zones are Polygon features that also contain metadata to identify them as network (graph) Edges. They must have a list of Node references: _w_id, which mean "this 2-dimensional Polygon feature consists of a complete graph with every pair of distinct Nodes in _w_id connected by a unique Edge.

Note that this would yield \(k(k-1)/2\) Edges for a Zone comprised of \(k\) Nodes.

2. Adjacent Entities⚓︎

Adjacent Entities are pedestrian network-adjacent entities that help describe the surrounding environment of the pedestrian network and can be used to augment the traversable network with important information. For example, a blind user would benefit from knowing that the footway they are using is adjacent to vegetation on their right side and a lake on their left side, or a park visitor would want to know where benches are located along their walk. Adjacent entities are not required for producing a valid OpenSidewalks dataset.

There are three types of adjacent entity models:

• Points
• Lines
• Polygons

Points, Lines, and Polygons are solely geometrical OGC features and they lack network metadata: their relationship to other members of the dataset is spatial. Adjacent entities are features relevant to the pedestrian network that are nevertheless not represented as elements of it: they are nearby and useful for producing descriptions, flagging potential barriers, etc.

Examples of each adjacent entity model:

• Point: a fire hydrant.
• Line: a wall or a fence.
• Polygon: a planter.

OpenSidewalks schema includes some Adjacent Entities which we found valuable to the pedestrian experience and are readily available through community contributions on OpenStreetMap. Other Custom Entities can also be included in an OpenSidewalks dataset and subsequently spatially merged with the Core Entities defined in the schema.

Points⚓︎

Points are features that are geometrically defined by a single latitude-longitude pair: a point on the planet. They are explicitly not elements of the pedestrian network definition (i.e. the graph structure described by Nodes and Edges), but they are still highly relevant to the physical pedestrian network. Points may be considered part of the real physical pedestrian network, but aren't appropriate as elements of the network described by the OpenSidewalks Schema. All Points must have a unique _id field.

Lines⚓︎

Lines are features that are geometrically defined by a series of coordinates forming a LineString. They are explicitly not elements of the pedestrian network definition (i.e. the graph structure described by Nodes, Edges and Zones), but they are still highly relevant to the physical pedestrian network. All Lines must have a unique _id field.

Polygons⚓︎

Polygons describe 2-dimensional areas which are adjacent to pedestrian paths. They are explicitly not elements of the pedestrian network definition (i.e. the graph structure described by Nodes, Edges and Zones), but they are still highly relevant to the physical pedestrian network. All Polygons must have a unique _id field.

3. Custom Entities⚓︎

Custom Entities are user-defined features that extend the OpenSidewalks Schema beyond the predefined Core and Adjacent categories. They enable incorporation of bespoke data layers while maintaining schema consistency. Custom Entities can take one of three geometry types:

• Points
• Lines
• Polygons

Entity Attributes⚓︎

Every entity has a set of defining attributes:

• geometry type that define the OGC geospatial type of the feature.
• identifying fields that must be matched to infer the entity type.
• optional fields that describe additional attributes of the entity.
• additional fields that describe attributes of the entity which have not been captured by the OpenSidewalks schema. Any additional fields must be prefixed with ext:.

Entity Type Inference⚓︎

Intended to closely mirror OpenStreetMap entities, OpenSidewalks Schema entities are identified by their set of attributes. Fields that uniquely identify an entity type are called identifying fields. In most cases, if an entity has all of the identifying fields specified and a matching geometry type, its type is matched. The only exception is for entities whose identifying fields are also a subset of other entities' identifying fields, in which case they are identified by (1) having all of the identifying fields listed and a matching geometry type and also (2) not any of the identifying fields of subtypes.

Metadata Fields⚓︎

The optional metadata fields that may be populated for OpenSidewalks Schema entities are largely inspired by and compatible with (reading from) OpenStreetMap data.

OpenStreetMap-derived fields represent a standardized and constrained interpretation of OpenStreetMap tags that often represent boolean values as yes/no strings, have unclear enumerated value tags, or allow the use of many different units for distances (e.g., a path's width may be described in meters, centimeters, feet, or other units in OpenStreetMap). The standardization of field types is itself inspired by the OpenMapTiles standard, which is optimized for protobuf-based serialization.

The combination of metadata standardization and network structures make OpenSidewalks data machine-readable and amenable to standardized analysis pipelines.

Additional information on field types can be found in the overview subsection of the fields section.

Network Topologies⚓︎

The OpenSidewalks Schema includes network topological rules for the ways in which network-mappable entities can be connected.

Edges only connect end-to-end⚓︎

While a graph structure may be inferred from Edges via their endpoints, the use of _u_id and _v_id are preferred. However, Edge entities should still meet end-to-end as they are intended to represent a physically-connected space.

Similarly, no connection is implied when the linear geometries of Edges cross.

A road entity and a crossing that intersects with it should share a Node⚓︎

In addition to the above rule about Edge entities connecting end-to-end, it is considered incorrect for a street crossing to intersect with (cross) associated road entities. Instead, both the road and crossing entities should be split such that endpoints are shared.

Crossings do not connect to sidewalk centerlines⚓︎

The OpenSidewalks Schema defines Crossings as existing only on the street surface and Sidewalks as describing only the sidewalk centerline. There must therefore always be space between a Sidewalk and a Crossing. A Sidewalk and Crossing should be connected by a plain Footway.

Curb interfaces and curb ramps are mapped at Edge endpoints⚓︎

Curb Nodes should be mapped directly at the endpoint(s) of one or more Edge(s): they are potential barriers or accessible infrastructure encountered along a path, so they should be available for inspection during network traversals. In other words, they are often important decision points when simulating a pedestrian moving through the network.

Serialization Formats⚓︎

OpenSidewalks data entities are vector geometries with optional topological data along with metadata that defines the entity type and optional metadata fields that are mappable to non-nested key-value pairs. As such, OpenSidewalks Schema data can be (de)serialized into a number of tabular and non-tabular GIS and graph formats. There exists both a reference JSON Schema for a GeoJSON serialization codebase for the OpenSidewalks Schema as well as a PostgreSQL schema.

Coordinate Reference System⚓︎

OpenSidewalks uses the World Geodetic System 1984 (WGS-84) coordinate system. WGS-84 is a geographic coordinate reference system (CRS) with longitude and latitude units of decimal degrees.

In compliance with the RFC 7946 GeoJSON, OpenSidewalks GeoJSON files will not include a "crs": element.

OpenSidewalks Dataset Metadata⚓︎

Each file in the OpenSidewalks dataset will contain the following metadata fields:

• $schema (string, required): this field specifies the schema version which the dataset is compliant with and should be used for validation.
• dataSource (object, optional): the data source which was used to generate the dataset. This can be OpenStreetMap, aerial imagery, or a dataset provided by an agency or a combination of sources.
• region (MultiPolygon, optional): a MultiPolygon capturing the geographical area covered by the OpenSidewalks dataset.
• dataTimestamp (date/time, optional): a date/time field stating the freshness of the data used in creating the OpenSidewalks dataset. For example, if aerial imagery was the basis for generating a dataset then the timestamp associated with these images can be used.
• pipelineVersion (object, optional): the software and version of the software that was used to generate the dataset.

The following is a sample snippet demonstrating the use of these metadata fields:

{
    "$schema": "https://sidewalks.washington.edu/opensidewalks/0.2/schema.json",
    "dataSource": {
        "name": "OpenStreetMap",
        "copyright": "https://www.openstreetmap.org/copyright",
        "license": "https://opendatacommons.org/licenses/odbl/1-0/"
    },
    "region": {
        "type": "MultiPolygon",
        "coordinates": [
            [
                [
                    [-122.1369414, 47.6365011],
                    [-122.1431969, 47.6365115],
                    [-122.1431951, 47.6469514],
                    [-122.1430782, 47.6495122],
                    [-122.1429792, 47.6495373]
                ]
            ]
        ]
    },
    "dataTimestamp": "2023-08-08T20:22:00Z",
    "pipelineVersion": {
        "name": "OSWDataPipeline",
        "version": "0.2-beta",
        "url": "https://github.com/TaskarCenterAtUW/OSWDataPipeline/tree/v0.2-beta"
    }
}

List of Core Entities⚓︎

Nodes⚓︎

Nodes are features that are geometrically defined by a single latitude-longitude pair: a point on the planet. They are also defined as a part of a pedestrian network: each Node must define an _id string field, a unique identifier to which Edges and Zones may refer using their _u_id, _v_id or _w_id fields.

Edges⚓︎

Edges are Lines (their serializable geometries are representable by LineStrings) intended to represent pedestrian network connections. Edges are often derived from topological data like that stored in OpenStreetMap. All Edges must have a unique _id field.

Zones⚓︎

Zones are features that are geometrically defined by a Polygon (a closed ring of coordinates). They are also defined as a part of a pedestrian network: each Zone must define an _id string field, a unique identifier, and a list (_w_id) of Node _ids that define the Zone's boundary.

List of Adjacent Entities⚓︎

Points⚓︎

Points are features that are geometrically defined by a single latitude-longitude pair: a point on the planet. They are explicitly not elements of the pedestrian network definition (i.e. the graph structure described by Nodes and Edges), but they are still highly relevant to the physical pedestrian network. All Points must have a unique _id field.

Lines⚓︎

Lines are features that are geometrically defined by a series of coordinates forming a LineString. They are explicitly not elements of the pedestrian network definition (i.e. the graph structure described by Nodes, Edges and Zones), but they are still highly relevant to the physical pedestrian network. All Lines must have a unique _id field.

Polygons⚓︎

Polygons describe 2-dimensional areas which are adjacent to pedestrian paths. They are explicitly not elements of the pedestrian network definition (i.e. the graph structure described by Nodes, Edges and Zones), but they are still highly relevant to the physical pedestrian network. All Polygons must have a unique _id field.

List of Custom Entities⚓︎

Custom Point⚓︎

Custom Line⚓︎

Custom Polygon⚓︎

Fields⚓︎

Fields Overview⚓︎

OpenSidewalks Schema fields are typed key-value pairs. Keys are always strings and values can be any of a specific set. Value types include:

• boolean: true or false
• text: unlimited length string
• enum: a set of enumerated values designated by strings
• integer: an integer
• numeric: a number, either integer or decimal
• opening_hours: serialized as a string, a specialized format for describing when a facility or asset is "open", as in accessible to the public.

List of fields⚓︎

Schema Versions⚓︎

Guides⚓︎

OpenSidewalks Schema Guides

For a list of all guides on the TCAT Wiki, refer to the Guides List.

Core Edges in OSW⚓︎

This guide shows how to convert existing sidewalk centerline datasets into OpenSidewalks (OSW) format for upload to the Transportation Data Exchange Initiative (TDEI).

Custom Points in OSW⚓︎

This guide shows how to add custom non-routable point features (like bus stops) to an OpenSidewalks dataset using the Custom Points entity type.

OpenSidewalks in OpenStreetMap⚓︎

This guide explains how to make edits to OpenStreetMap following and supporting the OpenSidewalks schema.