See the specification tables See the specification metadata See the LRS, Events and Relation Tables / Extensions

1.0 Specification Overview

This specification seeks to digitally represent bicycle, pedestrian, and accessibility infrastructure – or active transportation infrastructure – in the public right-of-way.

Active transportation infrastructure includes but is not limited to: 

The specification also includes a way to digitally represent roads, particularly because cyclists are allowed on most roads and because bicycle infrastructure exists on the road space.

This specification aims to be interoperable with OpenSidewalks and OpenStreetMap data. It allows for explicit linking to other specifications such as the General Transit Feed Specification, General Modeling Network Specification and General Bike Feed Specification, and it avoids duplicating features with these specifications. While it covers many accessibility-related attributes, its authors also encourage the creators of extended datasets like GTFS to complete all accessibility-related attributes and accessibility-oriented datasets such as GTFS Pathways.

There are several tools that can help you use this specification:

1.1 The Tier Model

Some data creators are preparing their first active transportation datasets from scratch and are seeking guidance on best leveraging their time in the field, while others may be working with existing datasets that can be translated into this specification. The tier model used in this specification aims to “meet data creators where they are” by providing a minimum set of requirements and a suggested roadmap for expanding and increasing the completeness of data over time. The model was inspired in part by the OSM US Pedestrian Working Group’s schema.

There are four tiers in the model. As the tier advances, the geometric features and attributes used expand, and data should be more complete and routable. There is no certification schema or recognition for achieving a particular tier. Use of the model is self-guided, and an organization may release different datasets at different tiers – for example, bicycle network data at Tier 2 and sidewalk network data at Tier 3. Applications that use the data may require a certain tier, so it can be useful to examine the needs of intended applications before planning out data collection.

A full description of the tier model appears in the GATIS Playbook.

2.0 Specification

2.1 Files

All files must be in GeoJSON or JSON format, with attributes as feature properties.

Core Files:

Extension Files:

2.2 Geospatial Features

The specification includes four types of core geospatial features: edges, nodes, points and zones:

Type

OGC Geospatial Format

Description

Examples

Edge

LineString

A line that connects two nodes and is used in routing

Sidewalks, bikeways, roads, multi-use paths

Node

Point

A point that connects to one or more edges and is used in routing

Curb ramps, transit stops

Point

Point

A point that marks an object of interest near bike or pedestrian infrastructure; may be made routable if desired

Signs, benches, lighting, accessible restrooms

Zone

Polygon

An area through which active transportation users may freely choose a path of travel

Plazas, park space

2.1.2 Attribute Types

Each geospatial feature has a set of attributes assigned to it. The table below describes the different types of attributes.

Type

Definition

Example

(GATIS field name: value)

Array

A collection of values, enclosed within square brackets (“[“, “]”) and separated by commas. Arrays have <Type> indicators that describe the type of data each value within an array should be.

allowed_uses: [“bike”, “ebike”, “motor_vehicle”, “scooter”, “walk”]

Boolean

One of two possible values, either “yes” or “no.” Boolean fields may be left blank. Most software will interpret blank values as “null.”

handrail: yes

Date

Where possible, a date should contain the year, month, and day, but month and year can be used if day is not available. In RFC 3339 format.

date_built: 2018-09-13

Datetime

Datetime strings contain the year, month, day, hour, minute, and second. If any of these are missing, substitute zeros. Convert to UTC time and include a “Z” at the end, or append a time zone offset in the format “+HH:MM.” In RFC 3339 format.

date_modified: 2018-09-13T13:23:14Z

date_modified: 2018-09-13T13:23:14+09:00

Enum

An option from a set of predefined (or "enumerated") values, where only one value may be chosen. Values may be Text or Integer.

directionality: forward

directionality: backward

directionality: both

ID

A field that contains identifying values for a particular item. Within GATIS, every geospatial feature has a unique ID.  An ID is labeled "unique ID" when it must be unique within a file. IDs defined in one .txt file are often referenced in another .txt file. IDs that reference an ID in another table are labeled "foreign ID".

edge_id: 12345

Float

A number that contains decimal values. Example: 4.12.

incline: 3.25

Integer

A whole number, with no decimal values. Example: 4.

thru_lanes: 3

Text

A value made up of a string of characters. GATIS and JSON use UTF-8 characters which must be human readable. Within GATIS, some text fields have recommended string values but allow for analysts to add other values as well, to increase standardization without being overly restrictive.

surface_material: dirt

URL

A fully qualified URL that includes http:// or https://. Any special characters in the URL must be correctly escaped.

license: https://creativecommons.org/publicdomain/zero/1.0/

2.3 Attribute Presence

The following terms describe the inclusion of attributes within GATIS data, which varies by tier:

3.0 Governance and Process for Changes

This specification is managed by [ORGANIZATION] through community consultation. Please visit [LINK] to review the overarching governance process for the specification. 

[ORGANIZATION] coordinates the process to suggest a change to this specification. Learn more about the process at [LINK].

4.0 Additional Materials

4.1 Guiding Principles

The guiding principles below shape the specification and its development. They were adopted in 2025 through a vote of the National Collaboration.

  1. The specification is owned and openly governed by the community.
    • This specification is created under the CC0 1.0 Universal Public Domain license.
    • Any organization or body that takes over management of the specification should:
      1. Provide open and transparent governance for a broad-based community of contributors and users across a range of geographies, areas of expertise and other domains. A variety of perspectives are needed to support innovation and access to data and tools that can benefit everyone.
      2. Be independent, and not have business interests that could be impacted by the contents of the specification.
    • The specification may or may not evolve into a standard. If it does become a standard, we encourage it to remain free and “open source.”
  2. Data produced under the specification should be shared freely and openly with the community.
    • Data producers are encouraged to license data in a way that keeps it free and available for commercial and noncommercial use.
    • All data producers and consumers, regardless of size, are encouraged to contribute data to public and open repositories and contribute to the growth of the ecosystem through data, code, tools and other means.
  3. The specification is designed to be as simple as possible, yet provide the ability to capture precise detail when available. It aims to enable technical and non-technical experts to effectively produce high quality data.
    • The specification deliberately includes a minimal set of required fields, recognizing that data collection is time consuming and often requires expertise not available to resource-constrained organizations who are motivated to improve the data.
    • Thorough, public, plain language documentation is provided for the entirety of the specification to drive data quality and support data producers and consumers with various skill levels and knowledge bases.
    • The specification allows data producers, including those who are technically sophisticated, to add more detail where they are able to.
    • The specification is specific and precise, and aims to be mutually exclusive and collectively exhaustive. For example, it specifies numerical values with explicit allowable ranges, and it enumerates categories and types rather than allowing open-ended text fields. This is intended to make it easier for applications to consume data, especially across a variety of producers, and easier for producers to create data others can consume.
    • One official validator is used to ensure consistency, and a transparent process exists for continual improvement of the validator.
  4. The specification prioritizes universal accessibility and the needs of all travelers, across a range of use cases.
    • It includes attributes that help travelers of varying abilities and needs know how to navigate in a way that matches how they move.
    • Connections between various types of transportation infrastructure are positively identified to enable routing and other use cases.
    • It is tested and optimized in rural, suburban and urban areas nationwide, and in areas with differing density and land use patterns.
  5. The specification describes objective qualities of infrastructure.
    • Rather than, for example, describing a path as “accessible” (incorporating the values of the person who is assessing that quality), the specification describes the path objectively as being six feet wide or having a slope of 1:48.
    • It relies on third-party applications to help travelers and other users interpret the data in accordance with their needs–i.e. determining what is “accessible” for them.
  6. The specification includes context that is useful for travelers and for information systems.
    • The specification includes metadata such as data origin, date of collection or last update, refresh schedules, authority or confidence, tolerance and error levels, completeness, recency and collection method. This metadata enables users to make their own decisions about how to use the data.
    • The specification is designed to allow for two-way data exchange so that users who identify errors may submit or suggest them for correction.
  7. The specification is extensible, and designed to be interoperable or interchangeable with other trusted specifications to make maintenance and creation as easy as possible.
    • Where possible, the specification uses the same or similar data structures and conventions as other specifications and standards that have clear alignment. Creating data in this specification should be as straightforward as possible, leveraging existing databases and/or data collection efforts as much as possible when and where they exist.
    • Extensions to the specification may be added over time to cover gaps identified in previous releases.
    • Data producers may add their own columns or create their own extensions to fit their local needs. These ad-hoc changes may be adopted into the formal specification if shown to be widely adopted.

4.2 Acknowledgments

The following organizations and people were essential in the creation of this draft: