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 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 or LineString 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 three major categories of entity models:
- Nodes
- Edges
- Points
Nodes and Edges are geometrical features (OGC Points and LineStrings, respectively) with network primitives defined such that a network (or graph) can be constructed purely from their metadata. Points are solely geometrical OGC Point features and they lack network metadata: their relationship to other members of the dataset are spatial. Examples of each entity model:
- Node: a raise curb.
- Edge: a sidewalk.
- Point: a fire hydrant.
Every entity has a set of defining attributes:
- identifying fields that must be matched to infer the entity type.
- optional fields that describe additional attributes of the entity.
- geometry type that define the OGC geospatial type of the feature.
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 verticies 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 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.
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.
Points are point features that do not contain network metadata, i.e.
they do not have _id fields. These are features relevant to the pedestrian
network that are nevertheless not (yet) represented as elements of it: they are
nearby and useful for producing descriptions, flagging potential barriers, etc.
Intended to closely mirror OpenStreetMap entities, OpenSidewalk Schema entities are identified by their set of fields. Fields that uniquely identify an entity type are called identifying fields. In most cases, if an entity has all of the identifying fields specified, 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 but also not any of the identifying fields of subtypes.
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.
The OpenSidewalks Schema includes network topological rules for the ways in which network-mappable entities can be connected.
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 marging of error), as they are intended to
represent a physically-connected space.
Similarly, no connection is implied when the linear geometries of Edges cross. Instead, this represents one of two scenarios:
-
The Edges have different
layervalues, i.e. they are at different vertical levels and so are not connected. -
There is a data error: the linear features are meant to meet where they intersect but the data maintainers have made a mistake. One way to infer this is when the intersecting linear features'
layervalues match (either because they are undefined and implicitlylayer=0or have explicitly-defined matchin values).
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.
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 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.
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.
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 may refer using their _u_id and _v_id
fields.
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.
None
Point
(must have the _id field, like all Nodes)
None
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.
None
Point
barrier=kerb, kerb=raised
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.
None
Point
barrier=kerb, kerb=rolled
A curb ramp (curb cut) mapped as a curb interface. Mapped at the location where the two Edges that it connects meet one another.
None
Point
barrier=kerb, kerb=lowered
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.
None
Point
barrier=kerb, kerb=lowered
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 may use the layer and brunnel tags, as all pedestrian paths may overlap one another at different z-levels or be part of a bridge or tunnel.
The centerline of a dedicated pedestrian path that does not fall into any other subcategories.
None
LineString
highway=footway
(and no footway=\* subtag)
The centerline of a sidewalk, a designated pedestrian path to the side of a street.
LineString
A dedicated pedestrian path (footway) along one side of the road.
highway=footway, footway=sidewalk
All optional fields of footway
description: 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".
(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.
LineString
highway=footway, footway=crossing
All optional fields of footway
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.
LineString
highway=footway, footway=traffic\_island
All optional fields of footway
The centerline of a designated cycling path. This path may or may not permit pedestrian use.
None
LineString
highway=cycleway
The centerline of a major highway.
None
LineString
highway=primary
The centerline of a secondary highway: not a major highway, but forms a major link in the national route network.
None
LineString
highway=secondary
All of the optional fields of a primary street.
A road linking small settlements, or the local centers of a large town or city.
None
LineString
highway=tertiary
All of the optional fields of a primary street.
A residential street.
None
LineString
highway=residential
All of the optional fields of a primary street.
A road intended for service use.
None
LineString
highway=service
The centerline of a driveway. Typically connects a residence or business to another road.
LineString
highway=service, service=driveway
All of the optional fields of a service road.
The centerline of an alley. An alley is usually located between properties and provides access to utilities and private entrances.
LineString
highway=service, service=alley
All of the optional fields of a service road.
The centerline of a subordinated way in a parking lot: vehicles drive on parking aisles to reach parking spaces in a parking lot.
LineString
highway=service, service=parking\_aisle
All of the optional fields of a service road.
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.
A power pole. Often made of wood or metal, they hold power lines.
None
Point
power=pole
A fire hydrant - where fire response teams connect high-pressure hoses.
None
Point
emergency=fire\_hydrant
None
OpenSidewalks Schema fields are typed key-value pairs. Keys are always strings (or symbols) and values can be any of a specific set. Value types include:
-
boolean:trueorfalse -
text: unlimited length string -
enum(a set of enumerated values designated by strings) -
integer: an integer -
numeric: an 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.
From OpenStreetMap
This may be a field inferred from other data.
A free form text field for describing an Edge. May be pre-encoded in
relevant pedestrian Edges to assist with routing instructing or
investigation of map features. For example, a description of the
sidewalk in relation to a nearby street may be a useful textual
description, such as "NE of Main St." Is a means by which to provide a short
(1-3 sentences) textual description of information that's not directly
available in the schema. Example: "this path is muddy when wet." Note that
because description data are unstructured, they can only be interpreted one
at a time by individual people and should not be considered a dumping ground
for "extra data".
From OpenStreetMap
The (semi-)official name of a path, of which an Edge is a part. Not a
description of the path. For example, this would be the street name for a
street path or a specially-designated name for a famous footpath.
name="The \[X\] trail", for example.
From OpenStreetMap
The estimated incline over a particular path, i.e. slope, i.e. grade, i.e. rise over run. If derived from OpenStreetMap data, this is the maximum incline over the path. If derived from DEM data, it is more likely to be an underestimation. Positive values indicate an uphill climb while negative are downhill. For example, a 45 degree downhill value for incline would be -1.0.
From OpenStreetMap
The surface material of the path. Derived directly from the surface tag from OpenStreetMap.
-
asphalt
-
concrete
-
gravel
-
grass
-
paved
-
paving_stones
-
unpaved
From OpenStreetMap
This is the calculated length of the way, in meters, according to the Haversine formula (Great-Circle Distance). This calculation is typically left up to consumers of geometry data, as the geometry is, itself, furnished for geometrical analysis. This is likely how AccessMap should also handle these data, but for now length is precalculated.
From OpenStreetMap
Original value of the foot key if it is set to yes or no.
-
1
-
0
From OpenStreetMap
The opening hours of the network element. This may apply to, for example, a path that is inside a building. The value is in OpenStreetMap syntax for the opening_hours tag. See OpenStreetMap specification on the formatting for this field.
Unique to OpenSidewalks
Whether an Edge uses an elevator for vertical movement, e.g. building paths.
From OpenStreetMap
The width of an Edge in meters.
From OpenStreetMap
The relative z-order of map elements. Useful for both rendering and detecting spatial intersections - paths of different layer values can intersect without sharing a node. Values are integers that can be negative (for underground), with the implied default being layer=0.
From OpenStreetMap
A field indicating that an entity is part of a bridge, tunnel, or ford.
-
bridge
-
ford
-
tunnel
From OpenStreetMap
Whether an entity is indoors or not.
From OpenStreetMap
Whether a curb ramp or Edge has a tactile (textured) surface.
From OpenStreetMap
Type of street crossing - marked or unmarked. When derived from OpenStreetMap data, the crossing key undergoes various conversions due to fragmentation. Both the uncontrolled and zebra values are converted into marked and the traffic_signals value is ignored.
-
marked: a marked crossing
-
unmarked: an unmarked crossing