Seattle, Washington/Sidewalk Import

About

The goal of this import is to populate the Seattle, WA area with sidewalk information derived from AccessMap (accessmap.app) that derives its data from municipal sources (data.seattle.gov). The source data is released under the public domain.

This import will occur in phases and includes an evaluation period during which the local OpenStreetMap community will evaluate the import process and recommend changes. The import process itself will be vetted entirely by the local community one a line-by-line basis in small batches, and will not involve a large-scale, automated import in any way. This import has the support of the local OpenStreetMap community, with whom the hosts (principals of the OpenSidewalks group) have previously held mapathons. The overall thrust of this work was presented at the State of the Map US (Summer 2016) and received strong support from attendees.

At the time of writing (Feb 2017), the import will concern only sidewalk lines and curb ramp nodes using existing tags used in the wild. While this import has been launched by the principals of the OpenSidewalks project (Proposed_features/sidewalk_schema), most of the proposed tag usages discussed on that page will not be used, and there will be no disruption to the street network or routers that depend on it.

Import Plan Outline

This import will occur in phases via a series of mapathons hosted with OpenStreetMap Seattle, and largely follows the strategy used by the LA Building import. This import will use a locally-hosted version of the OSM Tasking Manager to coordinate mappers, but will also use on-the-ground verification efforts using Field Papers. To an individual user at a mapathon, the import will consist of:

• Visiting the locally-hosted Tasking Manager
• Selecting a (very small, ~a few blocks) region to import
• Downloading the relevant chunk of data for that region via the Tasking Manager and opening as a layer on JOSM.
• Reviewing the data for accuracy based on personal on-the-ground experience, Bing aerial imagery, Mapillary data (when available), and Field Papers data (when available). Nearly every node will be adjusted by the reviewers.
• Submitting their region to OpenStreetMap, pre-filled with a changeset tag referencing the SeattleSidewalkImport.
• Getting their submission validated by another local user.

The first phase of the import will focus on a limited geographic region (downtown and the University of Washington area) for the express purpose of evaluation by the local OSM community, to ensure that the import conforms to community best practices and does not present serious maintainability issue. Pending a successful evaluation phase, the rest of the sidewalk data will be imported through more co-hosted mapathons.

Goals

The primary goal of this import is to improve mapping of the pedestrian network within Seattle by importing open data on sidewalks and curb ramps from the City of Seattle's open data platform, data.seattle.gov. This original source data has extensive coverage (the entire city of Seattle), but consists of inaccurately-generated offset lines, so the import will actually use processed city data donated by accessmap.app. This data is available under the public domain and has no licensing restrictions.

For the most part, sidewalks are not annotated in OpenStreetMap in the Seattle region, so this import would address a fundamental lack of information about the pedestrian right of way for this region. To explore the relevance of pedestrian network data to the question of accessibility, see the related accessmap.app project. However, sidewalk data is relevant to most individuals, as it represents fundamental infrastructure supporting most other modes of transport in urbanized areas: public transit, automobile traffic, and cyclists.

For example, an individual concerned about safety may want to know whether there is a guard rail present near a particularly busy street, whether a sidewalk is wide or narrow near a busy street, or whether there is an alternative pedestrian route that connects their sidewalk to a pedestrian footpath removed from the road. For accessibility, users have a variety of needs, so while a powered wheelchair user may need to know where curb ramps are in order to navigate an intersection, a blind user may want to actively avoid certain types of curb ramps (such as those pointing to the center of an intersection). These different informational requirements present a particularly difficult situation to resolve without a specific description of sidewalk and curb ramps locations.

Schedule

• June 2016: scoping and analysis of import tool options
• July 2016: development of import tools and presentation of strategy to the OSM community
• August 2016: engagement with the community to host mapathons to collect pedestrian data in regions not covered by the import (e.g. the University of Washington) and evaluate the tagging schema.
• Feb 2017: Host an initial test mapathon with the Seattle OpenStreetMap community. Use this experience to develop a more confident timeline and evaluate tagging, look for breakages in any other services.
• March 2017 and on: Pending a successful initial import mapathon, co-host regular (at least once per month) mapathon with OpenStreetMap Seattle.

Import Data

Background

Seattle City Data:

• Sidewalks: https://data.seattle.gov/Transportation/SDOT-Sidewalks/dsed-gzpp
• Curb ramps: https://data.seattle.gov/Transportation/SDOT-Curb-Ramps/j3nx-ir4y
• Data license: public domain with attribution
• ODbL Compliance verified: yes

Derived AccessMap Data (endpoints currently unstable):

• Sidewalks: https://accessmap.app/api/v2/sidewalks.geojson?all=true . The metadata will not be used outside of source information.
• Curb ramps: identical to Seattle City curb ramps, but stripped of metadata
• Street crossings: algorithmically-generated, can be previewed at https://accessmap.app. Will be cross-referenced with SDOT data and include pre-filled marked crossing information.

OSM Data Files

Generated on-the-fly based on neighborhood + block regions.

Import Type

This is a one-time import that we hope will serve as a model for another urban areas. To this end, we actively encourage feedback not just on the proposal for the Seattle import, but also with respect to how our proposal may scale and be used by others. Maintainability is a chief concern of this import, so the principals have actively solicited stakeholders in addition to the local OSM community, including AccessMap, the Taskar Center for Accessible Technology at the University of Washington, and local and regional governmental entities.

The import will not be automated, but will provide the importing mappers with suggested starting data and changeset tags for tracking. We have developed import tools in concert with AccessMap that convert City of Seattle GeoJSON data into the OSM XML standard to simplify the tagging process.

Data Preparation

Tagging Plans

Sidewalks will be tagged as separate ways using footway=sidewalk. Describing sidewalk lines as separated paths is a chief goal of this import, and was heavily weighed against tagging streets with sidewalk=left/right/both/no. Based on extensive research and interviews with users of all abilities, the description of sidewalks as street metadata was found to be inadequate to describe whether an individual could actually get on to the sidewalk at a given location, and whether a given sidewalk actually connects to other pedestrian paths - park paths, around a block corner, street intersections. For example, there is no way to tag a sidewalk that extends 80% of the way down the block with sidewalk=left/right/both/no. The footway=sidewalk tag is increasingly found in the wild, and has been extensively used (and noted in OSM eu news) in Graz, Austria.

Curb ramps will be tagged as nodes with kerb=<descriptor>, using only existing, community-accepted values for the kerb key. This is identical to the annotation used in Graz, Austria, and essential to describe the actual, visible, on-the-ground location of pedestrian infrastructure. The use of this tag is less common than footway=sidewalk, but for the most part curbs and curb ramps are not described in OpenStreetMap at all (despite curb information being essential to disabled individuals). The kerb=<> tag is most commonly used on nodes, so this is not a major deviation from how tags are used in the wild.

Street crossings will be tagged as ways in line with existing iD editor tags, i.e. highway=footway, footway=crossing. Marked crossings will be tagged whenever possible. Due to a lack of appropriate alternative tags for USA-style marked crossings, marked crossings will likely use crossing=zebra, in line with the iD editor's preset.

A note on street crossings: we consider it to be essential to connect sidewalk lines to streets (and to each other) in order to avoid breaking existing routing services. For example, if only sidewalks are added to an area, they become isolated pedestrian islands with no connection to each other or the greater street grid. If a user selected a building near a sidewalk, the closest pedestrian path may be that sidewalk, but if it has no connection to the rest of the transportation grid, it will result in no route being found. While routing services should always handle the possibility of isolated routing graphs, adding thousands of such islands to a small area could introduce new problems. Therefore, we propose tagging street crossings as much as possible, including every street intersection for Seattle unless otherwise marked. In addition, marked street crossings away from intersections should also be included. Whenever possible, curb (kerb) information should be noted where the crossing lines itself intersects the street curb. Finally, rare edge cases, such as a single isolated sidewalk line connected to nothing else, will be systematically identified and connected to their street.

Most elements (sidewalks, curb ramps, etc) derived directly from municipal sources. We will internally maintain a mapping between OSM pedestrian features and SDOT pedestrian features to allow tracking of changes, but do not currently plan to add tags to OSM features describing SDOT database metadata (e.g. row ID), in keeping with OSM import best practices.

Data Transformation

The data has been converted to OSM XML using custom-written software and a limited set of tags. This data will then be divided into different block-groups for validation by mappers during co-hosted mapthons.

Data Merge Workflow

Team Approach

This import began as part of the Data Science for Social Good fellowship hosted by the University of Washington, a team of 8, with 4 students, 2 data science leads and 2 project leads. This team solicited support at the SOTM US 2016 and hosted a mapathon on August 7th 2016. It has since been continued by the AccessMap project and the Taskar Center for Accessible Technology by principals in the OpenSidewalks project in collaboration with the Seattle OpenStreetMap community.

Inspirations

We are taking inspiration from other recent large imports, including:

• Chicago Buildings Import
• LA Buildings Import
• NYC Buildings Import

Workflow

Our workflow is as follows:

• Convert city/AccessMap data to OSM XML.
• Split the OSM XML into small (~block) sized regions using a set of polygons.
• Create an OSM Tasking Manager project (hosted locally) using that set of polygons.
• Solicit feedback and mapping through co-hosted mapathons with the local comunity

Our changeset size policy is smaller than census tract, and can be easily reviewed without making major map changes.

We take responsibility to revert any changes that cause breakages.

Conflation

Our conflation strategy is inspired by other recent large data imports, such as the LA building import, and will boil down to a reliance on expert JOSM users in the local OpenStreetMap community. For the most part, we do not expect many conflation issues, due to the lack of existing sidewalk and curb ramp data.

Expected issues related to conflation:

• Shared nodes with other pedestrian ways.
  • The sidewalk data will need to be combined with existing pedestrian ways intended to describe non-sidewalk pedestrian paths, such as plazas and trails.
  • In all such instances, a shared node will be added between the existing footpath and the new sidewalk data.
  • This issue will be extensively covered during training of any new mappers at our co-hosted mapathons.
• Existing pedestrian ways connected to streets:
  • Many dedicated pedestrian ways, such as paths through parks, are currently connected directly to streets.
  • These will not be modified in any way, outside of adding a node (described above) where they meet sidewalks. This helps prevent our import from breaking any existing routing software.
  • This issue will be extensively covered during training of any new mappers at our co-hosted mapathons.