Safe Routes to School Mapping Toolkit

From OpenStreetMap Wiki
Jump to navigation Jump to search

Safe Routes to School Mapping Toolkit is the concept for a tool to be used by schools or communities to generate maps for applications to the United States federal program Safe Routes to School (SRTS), however many of the potential tools could be used by any community to analyze how accessible a given location is to pedestrians or cyclists. The main products will be a set of maps showing existing walking and biking infrastructure, proposed improvements, and walking/biking distance maps (distance contours) for before and after the improvements.

This toolkit could be a great benefit to SRTS participants, as well as benefit OSM by exposing it to a broader audience, and getting more communities (especially in the US) involved in contributing to OSM.

Goals

The overall goal of this project is to lower the barriers to analyzing the current walking/biking infrastructure of a school or other location, as well as the impact of infrastructure improvements. Instead of requiring the use of GIS professionals to create such an analysis, this toolkit will allow anyone with basic web skills to create advanced geographic reports.

Initial goals are to create walking distance maps manually via PostGIS, pgRouting, and QGIS. Longer term goals include automatic creation of said maps via a web interface, and even longer term is a web interface whereby proposed infrastructure (sidewalks, crossings, etc) can be drawn in and the improvements quantified (e.g. 20% more students will be within walking distance if this sidewalk is added).

Safe Routes to School

Safe Routes to School (SRTS) is a federal program to encourage and provide funding for improving pedestrian and cyclist access to schools. Municipalities that wish to apply for the program need to provide maps showing existing walking and biking facilities, as well as barriers to safe travel, possible infrastructure improvements, etc.

As an example, the Virginia SRTS reference guide suggests the following maps:

  1. "Map A: School Overview Map, show and label:
    1. location of target school(s)
    2. a two mile radius around school
    3. attendance zone boundary for each school or a note that boundary is city-wide, for example
    4. any major streets/roads
    5. location of proposed engineering strategies.
  2. Map B: Pedestrian and Bicycle Infrastructure within a half mile radius, show and label:
    1. existing sidewalks, multi-use paths and bike lanes within 1/2 mile of each school
    2. identified barriers
    3. neighborhoods or student clusters
    4. location of any traffic signals and crossing guard locations
    5. location of proposed engineering strategies (For School Travel Plans with multiple schools, it may be necessary to create several maps to show the pedestrian/bicycle infrastructure around the schools.)
  3. Map C,D,E etc: Infrastructure Improvement Map (only if infrastructure changes are planned) In these maps, you denote the location of schools and planned improvements. Show and label the following:
    1. proposed strategies and surrounding street names, for example within three or four block radius
    2. stop, yield signs and traffic signals
    3. school flashing beacons
    4. speed limit on roads/street
    5. vehicle counts on road (i.e. AADT, and peak hour)
    6. school entrances, when nearby. If your Plan seeks to outline infrastructure improvements at several locations, create a separate map for each site." [1]

Inputs

These are some of the possible inputs. Quality and availability of this data will vary from region to region.

  • OpenStreetMap data - data for roads, as well as pedestrian and cycling paths
  • Altered OSM data - OSM data modified to reflect potential infrastructure improvements, such as new sidewalks
  • Student distribution - various levels of granularity, from coarsest to finest
    • Census block data - population data, typically at the neighborhood level
    • Locality population/housing data - some localities may have data with better granularity than the Census
    • Student directory - difficult because of privacy concerns, however it may be possible to use actual addresses of students (geocoded)
  • Parcel land use - used to refine Census block data (i.e. exclude non-residential parcels)
  • School locations - possibly use precise school entrance locations via OSM
  • School attendance boundaries

Products

Walking distance (isodistance) before new sidewalk
Walking distance (isodistance) after new sidewalk

Some of these products can be used for determining what infrastructure improvements offer the most benefits, while others are useful for an SRTS application.

  • Existing infrastructure map - show walking/biking infrastructure as it exists
  • Proposed infrastructure map - show proposed infrastructure improvements
  • Isodistance map - shows what areas are within walking/biking distance
  • Isodistance improvement map - show what areas are now within walking/biking distance (difference between before and after isodistance maps)
  • Hazards map - shows areas that are unsafe for walking/biking (such as due to no sidewalks, high speed limit, etc.)
  • Statistics - several statistics can be calculated from the inputs, for both current and proposed, as well as the difference (i.e. improvement)
    • Number and percentage of students within walking/biking distance (using distribution of students)
    • Percentage increase in students that can walk or bike to school given a proposed improvement
    • Interesting statistics like vehicle miles saved, carbon emissions reduction, health improvement (additional walking/biking student-miles)

How to help

There's plenty of tasks that need to be accomplished if this toolkit is to become fully realized, and they won't all get done unless other people like you get involved. If you are interested in helping with this project contact Josh Doe at josh@joshdoe.com.

  • Create mapping guide. List best practices for mapping walking/biking infrastructure, link to relevant OSM wiki pages, and show examples.
  • Consider gaps in tagging scheme. What features are important to safety of walking/biking routes that aren't currently represented as accepted tags (e.g. shoulder width)?
  • Define what types of maps are useful (current/planned infrastructure, walkability/bikeability).
  • Design map styles. Suggest rendering styles for each map type, such as colors/patterns/icons to use.
  • Define criteria for a "safe" route. There likely should be multiple profiles, such as age-dependent bike profiles. For walking, simplest criteria are to only use highway=footway/path/cycleway/residential/service, and disallow crossing unclassified/tertiary/secondary/etc roads unless there is a marked or controlled signal. Could also consider speed limit rather than road classification. Biking profiles will likely be the most challenging.
  • Creation of PostgreSQL/PostGIS queries to implement the criteria.
  • Creation of GRASS/(other software) commands to create isoline (distance) maps from scripts (i.e. for use in web service).*
  • Creation of web site (HTML/CSS/OpenLayers/etc).
  • How to allow proposed infrastructure improvements to be added. Obviously can't add to the live OSM database, so perhaps modify a local DB that can be refreshed/updated/reset on request. Probably the simplest option is to on request copy the data in a 2-mile or so radius of a given school into a new database, which can then be edited by Potlatch2/JOSM.

Technical details

As this project is in a very early stage, most of what you'll find here are just notes.

Isodistance maps

To create these, we must take our road+path network and create a shortest path tree (SPT) via something like Dijkstra's algorithm, and then create contours or interpolate to get a gradient effect.

pgRouting has a function driving_distance() which computes the SPT using any arbitrary cost, such as distance or time, and returns the vertices and their accumulated cost. GRASS has v.net.iso which is very similar, but returns edges and their accumulated cost. Many other libraries exist which implement Dijkstra, such as Boost.

A non-trivial task is properly assigning weights to edges, taking into account OSM attributes like highway=*, maxspeed=*, and many others. It may be worth extending OpenTripPlanner to take advantage of the existing attribute handling as well as the multi-modal functionality.

Currently I'm doing the following: Download virginia.osm.bz2 from Geofabrik, extract Fairfax County, then import using osm2pgrouting: 

wget http://download.geofabrik.de/north-america/us/virginia-latest.osm.bz2
osmosis --read-xml file=virginia-latest.osm.xml --bounding-box left=-77.5755 top=39.0718 right=-77.0334 bottom=38.614 --log-progress --write-xml file=fairfax.osm.xml
osm2pgrouting --file fairfax.osm.xml --conf mapconfig.xml --dbname fairfax --username postgres --passwd postgres --clean

I then have a Python script generate filled contours, based off of the Contour plugin for QGIS:

  • Execute SQL query or load file using OGR to retrieve vertices with costs
  • Interpolate irregular data onto a regular grid using griddata from matplotlib
  • Create filled contours using contourf from matplotlib
  • Convert to GeoJSON or other file using OGR

To show this on a map, I have another Python script which takes a start point via HTTP POST (walk.py?startpoint=$lon $lat), finds the nearest vertex, computes the SPT using driving_distance(), creates the filled contours, and spits out GeoJSON for consumption and display by OpenLayers.

Miscellaneous notes

  • Install pgRouting and necessary dependencies (for Ubuntu follow this guide)
  • Download relevant OSM area (using API request or download Geofabrik extract)
  • Create database using pgRouting template (might need to change md5 to trust in pg_hba.conf)
  • Import OSM file into database
    • osm2pgrouting -file terra_centre.osm.xml -conf mapconfig.xml -dbname terra_routing -user user -passwd user -clean
    • Doesn't seem to pull in all tags, which we need later, so look into some other tool, or maybe manually create routing network
  • Split at intersections with ST_Split
  • Remove edges that share a node with a motorway/primary/etc.
    • Again, not sure how to do this, just some PostGIS query that needs to be created
  • Interpolate between vertices along edges
    • This will be done because we are only considering a 1 to 1.5 mile (1.6 to 2.4 km) walking distance, and some ways can be very straight (no nodes for quite a while), so the resulting distance map would have some odd appearances
  • Create point vector layer using the pgRouting function driving_distance()
  • Create contours
  • Create cost points with max of 2km:
SELECT *
   FROM vertices_tmp
   JOIN
   (SELECT * FROM driving_distance('
      SELECT gid AS id,
          source::int4,
          target::int4,
          length::float8 AS cost
      FROM ways',
      (SELECT id FROM vertices_tmp ORDER BY distance(the_geom, ST_GeomFromText('POINT(-77.29739 38.78572)',4326)) LIMIT 1),
      2,
      false,
      false)) AS route
   ON
   vertices_tmp.id = route.vertex_id
  • Possibly use r.walk to account for difficulties in walking associated with elevation changes (slope). Create friction cost raster

(I've had to set a password to the postgres account with psql: ALTER USER postgres WITH PASSWORD 'postgres'; 

# become user "postgres" (or run as user "postgres")
sudo su postgres

# create routing database
createdb routing
createlang plpgsql routing

# add PostGIS functions
psql -d routing -f /usr/share/postgresql/8.4/contrib/postgis-1.5/postgis.sql
psql -d routing -f /usr/share/postgresql/8.4/contrib/postgis-1.5/spatial_ref_sys.sql

# add pgRouting core functions
psql -d routing -f /usr/share/postlbs/routing_core.sql
psql -d routing -f /usr/share/postlbs/routing_core_wrappers.sql
psql -d routing -f /usr/share/postlbs/routing_topology.sql

# add pgRouting driving_distance()
psql -d routing -f /usr/share/postlbs/routing_dd.sql
psql -d routing -f /usr/share/postlbs/routing_dd_wrappers.sql

exit

# copy mapconfig.xml and modify to only import residential, footway, etc.
cp /usr/share/osm2pgrouting/mapconfig.xml .

wget -O osm_data.xml http://api.openstreetmap.org/api/0.6/map?bbox=-77.31563,38.77128,-77.27936,38.79744
osm2pgrouting -file osm_data.xml -conf mapconfig.xml -dbname routing -user postgres -passwd postgres -clean

Routing profiles

A routing profile is the set of criteria used when determining whether a specific way or node can be traveled on or over, and possibly the time or cost associated with doing so. For SRTS, there will be at least two profiles, walking and biking, but likely there will be several (safe/safer/safest, least distance/time/effort).

Safe walking, least distance

Safer walking, least distance

This could be the same as the above, except it wouldn't allow use of ways with sidewalk=*, since it can't be known if there is safe crossing infrastructure. Also, routing across highway=traffic_signals would not be allowed, as there is no guarantee of a safe crossing (dedicated/marked pedestrian crossing should have it's own highway=footway).

Safe biking for age group A, least distance

Wheelchair

References

See also

External links

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Safe_Routes_to_School_Mapping_Toolkit&oldid=1683879"