This is Part 2 of a 2-Part Series. In Part 1, we introduced the project and went over the steps we took to build the GIS-based Safe Routes To School route-finding methodology. Read Part 1 here.
Cooking Up a Usable Network
Prep the Data
To start, we create a new file geodatabase and add multiple datasets from a variety of sources. The datasets are used in preparing the centerline as a network dataset source. For our centerline, we use Oregon Metro‘s BikeNetwork Centerline as the source, which was derived from the City of Portland’s street centerline and includes the City’s trails.
This being a Safe Routes To School project for Portland Public Schools, the first thing we do is to clip to the City of Portland Boundary. Once that is done, we clean up the data by deleting and adding fields in the new feature class so we’ve got attribute fields without unneeded bulk. Some fields are added to capture specific criteria that are used in Portland Public Schools’ Supplemental Plan field evaluation of student walk areas. Among those fields are shoulder widths and conditions, motorist visibility, and other conditions that may exist that creates a risk (data not available in existing data sources). After this information is collected in the field, they will be added to the network dataset, and can be used in route analysis.
The next step is to edit the centerline feature class, to add routing specific attributes. There is considerable amount of manual editing to prepare the centerline for use in a network dataset. The information comes from various sources, and the data do not always align well with the centerline. The focus of this project is student walk areas 1-mile from elementary schools (K-6, K-8) and 1.5 miles from middle schools (6-8, MS), therefore the editing can be prioritized for those areas. The routing analysis will be performed within the walk area boundaries.
Following are some of the major editing steps
A street hierarchy rating, from 1 to 3, based on the street TYPE values is calculated. We use two sources of sidewalk data (one from the City and the other from Metro) to add sidewalk information. We need to use both sources of data as there is no complete sidewalk dataset for the entire City. The data from the City consists of a polygon layer offset from the street centerline. We need to split the centerline where there are sidewalk polygons, and add field values for right side, left side or both sides sidewalks. The Metro data has left side/right side attributes, is aligned with the centerline, and has a unique ID that can be used to join with the centerline data to calculated field values for sidewalks.
After the sidewalk attributes are in place, we affix the speed limit attributes.The number of lanes is an important consideration in determining safe routes. Again, we need to do a considerable amount of manual editing to prepare the data.
The next step is to convert the crosswalk line feature class to a point feature class, and then merge it with the traffic signals point layer. We then strip many of the fields, except for the ones we need, and save the two merged layer as one intersection layer in our new Pedestrian feature dataset. Sinuosity – curviness – is calculated on the centerline, and values added to a field in the centerline feature class.
The final step in preparing the data is a manual check to confirm that we have retained necessary fields and deleted extraneous ones.
Create the Network Dataset
To start, we create a new feature dataset in the file geodatabase that we created when preparing the data. The projected coordinate system that we use is the Oregon State Plane North, NAD 83 HARN. We then copy the prepared feature class to the feature dataset, and use a network dataset tool to create a new network dataset. Using the tool, we specify the attributes for shoulder, speed, road hierarchy, lanes, sinuosity, traffic signals and crosswalks. As you can imagine, we are looking for roads with wide shoulders, low speeds, low traffic and minimal lanes.
Generate walking routes
In this phase, we start to build the route maps; both the specific routes to individual students’ homes as well as more generalized, “catchment” routes that groups of students can use. Using a network analyst tool, the closest facility analysis will be used to map individual student walk routes from their homes to their school. Students will be used as the “incidents” in the analysis, and the specific school site will be the “facility.” This phase consists of a good deal of trial and error as we tweak the attributes and their impact on the route. Additionally, we add analysis of barrier layers. Barrier layers are not part of the network dataset; they are comprised of individual points, lines, or polygon feature classes that can be added to restrict or alter impedances of the network routing. We use land use, slope, crash and crime data for our barrier layers. They can easily be added or removed from the analysis, as can the network dataset attributes. Field tests will aid in refining the use of attributes and barriers, as well as highlight data gaps that exists.
Lessons Learned
Despite all of the great data available in the City of Portland, we still had a good deal of manual work to do. While the initial data cleanup and prep is time consuming, we anticipate that as data is maintained and properly curated, the process will become far more automated.
A Framework for GIS and Safe Routes to School
Last year, a group of experts convened in Austin, TX to discuss existing datasets and what is not being collected, how the general public can create and access data, existing tools and technology and what is needed to improve data connectivity and mapping, how GIS could be better utilized in Safe Routes to School and other active transportation initiatives. The result of the meeting was a paper titled, A Framework for GIS and Safe Routes to School which we used as a starting point in determining our methodology. In the paper, the authors came up with the Top Ten GIS Datasets for Safe Routes to School. Those ten datasets are listed below, followed by an explanation of how (or if) we used them.
Standard level of comfort - A fairly subjective measurement, but one that is clearly important. This dataset is not something that is immediately available, but will become available as field data-collection efforts get under way. Our initial field testing involved a good deal of discussion about the best ways to collect and quantify this type of data.
Presence of a Sidewalk - This is an important attribute. We also took into consideration, and feel that it’s an extremely important consideration; the presence and width of a shoulder.
Intersection - This is an important attribute. We weighed our routes taking into consideration attributes such as marked crosswalks and signals.
Bicycle Facilities - We did not take this into consideration as walkability was the primary focus of this Proof-of-Concept project. We look forward to working on SRTS bike maps!
School Location and Student Catchment Areas - Of course this was taken into consideration. How to determine catchment areas is a whole other discussion!
Speed - We added in an additional factor of sinuosity after going out in the field and seeing first-hand how curvy roads (without sidewalks) can be a safety issue.
Collision Data - This was a primary barrier attribute.
Health Indicators - We did not use this data.
Existing patterns - We did not use this data as there is no current existing walking pattern data.
Crime data - This was a barrier, but not ranked as high as crash or slope data.
Don’t Miss Part 1
Did you miss the first post in this series? Fear not, you can read it here.
One way we’ve met this challenge is through the use of AngularJS, an open-source Javasript MVC framework. Angular allows us to create rich and responsive internet applications for both desktop and mobile environments with the same codebase.
The Enabling Capability Assessment focuses on assessing the status of an organization’s data, technology, and geospatial infrastructure, while the Execution Ability Assessment focuses on the ability of an organization’s staff to leverage data and technical resources to serve particular goals and functions.