Guiding Principles

Draft version; awaiting formal adoption.

What this Specification Is For

This specification is for digitally representing physical infrastructure for walking, biking and rolling in the United States. It was designed with travelers of all abilities and the transportation system and land-use patterns of the entire country in mind.

It aims to address gaps in existing standards and specifications by capturing attributes critical for preference-based routing use cases, and enabling improved asset tracking and maintenance, among other goals.

Principles

• 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:
    • 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.
    • 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.”

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

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

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

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

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

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