OpenSidewalks Schema

The OpenSidewalks Schema is a proposed 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 represent 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 are 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.

The JSON schema can be found here

OpenSidewalks Schema Entities

The OpenSidewalks Schema defines network and non-network data using a set of vector geometrical entity types, each of which having 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.

There are currently two major categories of OpenSidewalks 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 that also contain metadata to identify them as network (graph) vertices. Currently, this means that 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 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. Currently, this means that 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: the 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. Currently, this means that 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 𝑘(𝑘−1)/2 edges for a zone comprised of 𝑘 nodes.

2. Extensions

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

There are three types of extension 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 are spatial. Extensions 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 extension entity model:

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

OpenSidewalks schema includes some extensions (i.e. internal extensions) which we found valuable to the pedestrian experience and are readily available through community contributions on OpenStreetMap. Other extensions (i.e. external extensions) can similarly be included in an OpenSidewalks dataset and subsequently spatially merged with the core entities (i.e. the pedestrian network entities).

Entity Attributes

Every entity has a set of defining attributes:

  • 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:.
  • 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.
Entity Type Interface

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 but 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.

Edge entities 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 (within some small margin of error), 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 location/node

In addition to the above rule about 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 interface Points 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 the World Geodetic System 1984 (WGS-84) coordinate system. WGS-84 is a geographic coordinate reference system with longitude and latitude units of decimal degrees. In compliance with the RFC 7946 GeoJSON, a crs member will not be included in the OpenSidewalks datasets.

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 or satellite imagery or a dataset provided by an agency or a combination of sources.
  • region (MultiPolygon, optional): a MultiPolygon capturing the geographical 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 satellite 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 generated 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.

Bare Node

A special case of an abstract Node: this is a network (graph) node description that does not have any special metadata beyond location and the _id field. A “bare node” exists when two Edges meet at a location that is not one of the other Node types. For example, a single sidewalk may be represented by two Sidewalk Edges with different width values, split where the width changes. There is no physical feature within the OpenSidewalks Schema at that split point: it is just a “bare node” that connects the two Edges together.

Another way to interpret a “bare node” is in terms of the Edge definition rules: the Nodes referenced by _u_id and _v_id must exist within the dataset, so we must define Nodes wherever Edges meet regardless of whether that point in space has additional metadata.

  • Subtype of: None
  • Geometry: Point
  • Identifying fields: (must have the _id field, like all Nodes)
  • Optional fields: None
Generic Curb

A curb for which a type has not been determined yet or a type could not be determined despite some effort.

  • Subtype of: None
  • Geometry: Point
  • Identifying fields: barrier=kerb
  • Optional fields: tactile_paving
Raised Curb

A single, designed vertical displacement that separates two Edges. A common example is the curb that separates a street crossing from a sidewalk. This is mapped at the Node where the two Edges meet – on top of the curb is physically located.

Rolled Curb

A curb interface with a quarter-circle profile: traversing this curb is like going over half of a bump. Located where two Edges meet, physically at the location of the curb itself.

Flush Curb

An indicator that there is no raised curb interface where two Edges meet – i.e. where someone might expect a curb interface, such as where a crossing and footway meet.

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.

Footway (plain)

The centerline of a dedicated pedestrian path that does not fall into any other subcategories.

Sidewalk

The centerline of a sidewalk, a designated pedestrian path to the side of a street.

  • Subtype of: Footway
  • Geometry: LineString
  • Identifying fields: highway=footway, footway=sidewalk
  • Optional fields: All optional fields of footway
    Sidewalk-specific usage note: OpenSidewalks data will often infer a ‘description’ property that states where the sidewalk is in relation to its associated street. Example: “NW side of 5th Ave”.
Crossing

(Part of) the centerline of a pedestrian street crossing. A crossing exists only on the road surface itself, i.e. “from curb to curb”.

Because crossings should be connected to the street network, they should be represented by at least two Edges: one from the first curb interface to the street centerline and one from the street centerline to the second curb interface, e.g..

Crossings should not be connected directly to sidewalk centerlines, as the sidewalk centerline is never the curb interface. Instead, a short footway should connect the two together.

Traffic Island

The centerline of a footway traversing a traffic island. Some complex, long, or busy pedestrian crossings have a built-up “island” to protect pedestrians, splitting up the crossing of the street into two or more crossings. As a pedestrian uses this crossing, they will transition across these Edge elements: sidewalk → footway → crossing → traffic island → crossing → footway → sidewalk.

Pedestrian Road

The centerline of a road or an area mainly or exclusively for pedestrians in which some vehicle traffic may be authorized.

Steps

The centerline of a flights of steps on footways and paths.

Living Street

A street designed with the interests of pedestrians and cyclists in mind by providing enriching and experiential spaces.

Motor Vehicle Roads

While OpenSidewalks schema is centered around the pedestrian experience and accessibility within the pedestrian network, the inclusion of roads as core entities in the schema is justified because:

  1. In some areas due to the lack of sidewalks, a pedestrian has to use a road to reach their destination.
  2. Sidewalks and crossings are typically referenced by pedestrians in relation to roads, i.e. “Use the Sidewalk East of Main St.”, “Turn left and cross Broadway”.
  3. A pedestrian’s safety and environemnt is greatly impacted by her adjacency to a particular road. For example, a wheelchair user may choose to avoid crossing busy roads for her safety unless she has to.

In order to simplify the job of OpenSidewalks consuming applications when attempting to route pedestrians, we have included a foot field in all edges and zones to indicate whether an entity is safe to traverse by a pedestrian. We recommend applications clearly communicate the risk to pedestrians if they route users on entities with missing foot field or with foot=no.

Primary Street

The centerline of a major highway.

Secondary Street

The centerline of a secondary highway: not a major highway, but forms a major link in the national route network.

  • Subtype of: None
  • Geometry: LineString
  • Identifying fields: highway=secondary
  • Optional fields: All optional fields of a primary street.
Tertiary Street

A road linking small settlements, or the local centers of a large town or city.

  • Subtype of: None
  • Geometry: LineString
  • Identifying fields: highway=tertiary
  • Optional fields: All optional fields of a primary street.
Residential Street

A residential street.

  • Subtype of: None
  • Geometry: LineString
  • Identifying fields: highway=residential
  • Optional fields: All optional fields of a primary street.
Service Road

A road intended for service use.

  • Subtype of: None
  • Geometry: LineString
  • Identifying fields: highway=service
  • Optional fields: All optional fields of a primary street.
Driveway

The centerline of a driveway. Typically connects a residence or business to another road.

  • Subtype of: Service Road
  • Geometry: LineString
  • Identifying fields: highway=service, service=driveway
  • Optional fields: All optional fields of a primary street.
Alley

The centerline of an alley. An alley is usually located between properties and provides access to utilities and private entrances.

  • Subtype of: Service Road
  • Geometry: LineString
  • Identifying fields: highway=service, service=alley
  • Optional fields: All optional fields of a primary street.
Parking Aisle

The centerline of a subordinated way in a parking lot: vehicles drive on parking aisles to reach parking spaces in a parking lot.

  • Subtype of: Service Road
  • Geometry: LineString
  • Identifying fields: highway=service, service=parking_aisle
  • Optional fields: All optional fields of a primary street.
Unclassified Road

A minor public roads, typically at the lowest level of whatever administrative hierarchy is used in that jurisdiction.

  • Subtype of: None
  • Geometry: LineString
  • Identifying fields: highway=unclassified
  • Optional fields: All optional fields of a primary street.
Trunk Road

A high-performance or high-importance roads that don’t meet the requirements for motorway, but are not classified as highway=primary either.

  • Subtype of: None
  • Geometry: LineString
  • Identifying fields: highway=trunk
  • Optional fields: All optional fields of a primary street.
Zones

Zones are polygons (their serializable geometries are representable by Polygons) intended to represent areas where pedestrians can travel freely in all directions. They are part of the pedestrian network: each zone contains a list (_w_id) of node _id’s. All zones must have a unique _id field.

Pedestrian Zone

An area where pedestrians can travel freely in all directions.

List of Extensions
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.

Power Pole

A power pole. Often made of wood or metal, they hold power lines.

  • Subtype of: None
  • Geometry: Point
  • Identifying fields: power=pole
  • Optional fields: None
Fire Hydrant

A fire hydrant – where fire response teams connect high-pressure hoses.

  • Subtype of: None
  • Geometry: Point
  • Identifying fields: emergency=fire_hydrant
  • Optional fields: None
Bench

A bench – a place for people to sit; allows room for several people.

  • Subtype of: None
  • Geometry: Point
  • Identifying fields: amenity=bench
  • Optional fields: None
Bollard

A Bollard – a solid pillar or pillars made of concrete, metal, plastic, etc., and used to control traffic.

  • Subtype of: None
  • Geometry: Point
  • Identifying fields: barrier=bollard
  • Optional fields: None
Manhole

A manhole – a hole with a cover that allows access to an underground service location, just large enough for a human to climb through.

  • Subtype of: None
  • Geometry: Point
  • Identifying fields: man_made=manhole
  • Optional fields: None
Street Lamp

A street lamp – a street light, lamppost, street lamp, light standard, or lamp standard: a raised source of light above a road, which is turned on or lit at night.

  • Subtype of: None
  • Geometry: Point
  • Identifying fields: highway=street_lamp
  • Optional fields: None
Waste Basket

A waste basket – a single small container for depositing garbage that is easily accessible for pedestrians.

  • Subtype of: None
  • Geometry: Point
  • Identifying fields: amenity=waste_basket
  • Optional fields: None
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.

Fence

A fence is a freestanding structure designed to restrict or prevent movement across a boundary. It is generally distinguished from a wall by the lightness of its construction.

  • Subtype of: None
  • Geometry: LineString
  • Identifying fields: barrier=fence
  • Optional fields: length
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.

Building

A building is a man-made structure with a roof, standing more or less permanently in one place.

  • Subtype of: None
  • Geometry: Polygon
  • Identifying fields: building=*
  • Optional fields: name, opening_hours
Fields

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.
Schema Versions
VersionRelease DateLinkNotes
0.108/11/2023GitHub Minimal initial beta release of schema to unblock development of schema consuming applications
0.201/30/2024GitHubAdd required _id field to edges
– Update the documentation with regards to the coordinate reference system
– Introduce the concept of core entities and extensions
– Add zones to core entities
– Add lines and polygons to extensions
– Add schema versions and OpenSidewalks dataset metadata
– Add pedestrian zone to zones
– Add fence to lines
– Add building to polygons
– Add additional fields to entity attributes
– Add motor vehicle roads to edges with justification
– Add climb field to steps edge in addition to the existing incline field to prevent HUMAN READABLE DOCUMENTATION for 0.2. Main mod: mixed data types
– Add opening_hours field and include it in building entity fields
– Add generic curb entity to nodes
– Add foot field to all edges and zones
– Change entity type inference to include the geometry type in addition to the identifying fields
– Fix lossiness of tactile_paving field
– Remove crossing field in favor of crossing:markings field
– Add living street to edges
– Add unclassified road to motor vehicle roads
– Add trunk road to motor vehicle roads
– Require that the _id field for all entities has at least one character to ensure it is not left as an empty string
, , ,