1. Developing a “Starting Archive”, and Preparing a Processing Algorithm
What is our goal? If we seek to comparing walkability between areas, we will require at the outset some archive of areas for which walkability has already been mapped and appropriate summary statistics have already been collected - we will call this the “starting archive.” We will also want an efficient way to process user data when the service is released. Hopefully, we can accomplish these in tandem
How will we accomplish this goal? Prior to opening the service to users, we can script a automated process that, given some pre-specified data inputs for an area of interest, will output an “estimated walkability” raster for that area. From the data in this raster, we can collect summary statistics about walkability in the area for reporting and comparing, such as (for example) “average walkability” or “area of highly walkable places”. We can then run this process over an array of areas for which the necessary data is already openly available, and save this data to our starting archive. The automated process can then be saved as the method for processing future user data.
What does this achieve? After iterating over a number of cities, this will give us an archive of fully mapped and analyzed cities with which the service can be released, giving users a starting set of cities to which they can compare their own. It also gives us a process by which we can quickly and conveniently process user input data once the service opens - if we request that users provide the same data we used to build our archieve, we can use this same script to map and collect summary statistics on walkability in user areas of interest.
Process
Basic idea: Sample a certain amount of points for a city, calculate walkability for those points, interpolate walkability for the rest of the city, use the interpolated surface to gather summary statistics.
Step-by-step:
- Collect input data
- Find a list of cities for which the following data is available
- point layer of grocery stores
- point layer of restaurants
- point layer of schools
We will call the 3 points layers “point of interest” layers.
- line layer of sidewalks
- line layer of streets
- polygon layer of city outline
- polygon layer of neighborhood outlines (if applicable)
Questions: Are there other inputs that would be useful indicators of walkability? Should some of these not be considered?
- Sample a set of points/coordinates from along the street lines
- Sampling along street lines guarantees that the point is “reasonable” - i.e. it is not in the middle of a building, urban forest, etc.
- Sample points proportional to size of area - for example, we would probably need to sample more points in Los Angeles, CA than in Corvallis, OR to achieve an appropriate level of precision
- If neighborhood outlines are given, we could apply a stratified sample based on the population in each neighborhood
Questions: Would we want to apply the stratified sampling methodology to cities for which we have neighborhoods when we know all cities probably will not come with neighborhoods? (i.e. is it just to stratify for some but not all?) If we do stratify, should we do it by population or area? How many points should we sample?
- Determine a function by which to measure walkability
- Across-category weighting: weight the categories of “points of interest” based on perceived importance to walkability - for example, maybe we deem it more important to have grocery stores close to home than schools for walkability, so we’ll give more weight in our calculation to having walkable grocery stores
- A default would be to weight all categories equally
- Within-category weighting: within a category, weight the individual points of interest based on distance. This will be done based on some function that models an “attitude toward walkability” - for example, maybe 0.1 miles is significantly better for walkability than 0.4 miles, but 1.7 miles isn’t significantly better than 2 miles
- A default would be a linear decay: for example, 0.1 miles is 2 times better than 0.2 miles, and 10 times better than 1 mile.
- Formula for calculating walkability would then be additive based on these weights
Questions: What is the optimal way to weight across and within categories? How significant or relevant even is weighting?
- Compute a “walkability score” for each sample point.
- On a point-by-point basis:
- For each points of interest layer:
- Calculate and record the distance of the sample point to each individual point of interest in a layer
- For all points of interest that are within a “walkable distance” to the sampled point, record/save the distance to that point of interest (we will pre-determine what a “walkable distance” is)
- Output would be in a table form like this:
| given points layer |
unique IDs we assign |
distance away in miles (or whatever measure) |
|
|
|
- Hopefully, this could be done by applying a distance network analysis in ArcGIS with the sidewalks layer. Otherwise, we could apply a distance network analysis with the streets layer, and use the sidewalks layer as a “walkability attribute” (for example, add a weighted category for “number of miles of sidewalks within a walkable distance”). We could also use an “as the crow flies distance” and use sidewalks as a walkability attribute, but this stands to be significantly less precise than using streets as a backup
- Applying the pre-determined across-category/within-category weight scheme and resulting formula, calculate the walkability for the sampled point
Questions: What is a “walkable distance”, and how do we decide this? Should it vary between cities? Should it vary between points of interest (for example, does a grocery store need to be closer than a restaurant to be “walkable?”
- Create a walkability map
- Using the walkability score calculated at each sample point, interpolate a surface of walkability scores, bounded by the extent of the city outline polygon.
- The cell size for the output raster would be selected by us prior to analysis, and would remain a consistent size for all cities for the sake of comparison. We should factor in processing time, as well as number of sampled points selected, in determining cell size.
- Apply an appropriate color scheme to display the gradient of walkabilities throughout the city
- If interested/applicable, clip this output using the neighborhoods defined by the neighborhood outline polygon to obtain neighborhood-level walkabilities
- Save this output to our “starting archive”
Questions: Is interpolation a valid methodology for this analysis, considering that it will only provide an estimated walkability? What method should be used for interpolation? Does it matter? Should we make the outputs produced available to the user outside of the application?
- Obtain summary statistics about walkability
- For each output walkability map produced in the steps above (just 1 if no neighborhoods were provided, 1 + # neighborhoods if they were), obtain relevant summary statistics for reporting in the service. Potential statistics include:
- Average walkability (probably as a median or trimmed mean, to be safe)
- Percent of city area that is “highly walkable” – cells with walkability scores >
x / total number of cells, where x is a pre-specified thresshold
- Percent of city area that is “not walkable” – cells with walkability scores <
y / total number of cells, where y is a pre-specified thresshold
- Save these statistics to our “starting archive”
Questions: What other statistics should we consider for summary information? How should we save these statistics - in individual tables by location, or in one table with a variable for location? (I’d lean toward the latter). Like with above, should we make statistics produced available to the user outside of the application?
By repeating this process over a number of cities for which we have open access to the entire set of requisite inputs, we can build up our “starting archive” of city walkabilities. We can also save the process structure for analysis of future user data.
2. Producing an Informative User Experience, and Maintaining an Application
What is our goal? Now with a starting archive on which to base the service, we want to empower users to provide their own data and compare their area to other documented areas (already in the archive). We also want to be able to continuously update our archive to reflect the inclusion of more and more areas for comparison
How will we accomplish this goal? Produce an app or webpage that allows users to interact with their own data, as well as the range of maps and statistics already stored in our archive. This app or webpage would allow users to input their data, observe a produced walkability map and summary statistics of their area, learn which cities or neighborhoods their area is most similar (as compared to the archived data), and visually compare their area to cities and neighborhoods in the area with both maps and plots of summary statistics. When the service is published, we can stipulate a “service improvement clause” which states that use of the service adds the created outputs to the application archive.
What does this achieve? This will provide a user with a convenient, easily understandable interface by which to observe the comparative walkability of their area. Given that most users of this sort of application (i.e. have the necessary data at hand) would likely be administrative bodies of cities, this could help inform policy via an understanding of how their city compares to others, and what parts of their city should be focus areas for improving walkability. By requesting that our users submit their inputs to the application archive, users will be able to return to the application multiple times and track how their area compares as more and more cities are added, or as the temporal setting changes in their own city. This establishes a collaborative spirit for the application, as other cities data can be used in the future to track progress (by way of increasing the number of potential comparisons)
The reference to a temporal element above gets at a potential extension of this application: though this outline has been written in terms of comparing cities/neighborhoods to other cities/neighborhoods, this same process and way of thinking could be applied in the temporal sense, given the appropriate data. This would simply require storing an associated city name AND time with data in the archive, instead of just a city name. Then, users could compare their city across both space and time, and similarity could also be judge on this two-dimensional level.
Process
Basic idea: Make it easy for users to upload their data and have their data processed, with maps and summary statistics produced. Provide a intuitive, interactive user interface for visual comparisons.
Potential Interface
- The “I Want to Process my Own Data, and Visualize it Now” Section
- Interactive asking “Do you want to input your own data?” - button, checkbox, etc. if selected, then:
- Text input for city name
- Upload links for necessary files, labeled by which files should be given to each upload link
- Button/checkbox/etc to trigger data processing, map and statistic production. ideally, this would automatically add the map/statistics to the output
Questions: Is an interactive like this useful? Do we want to automatically produce the maps/statistics for the data to the output, or simply add it to the archive and indicate to the user that it is now available for selection?
- The “Here’s What You Can Compare To” Section
- Menu of available archived locations to show for comparison - dropdown?
- Probably should have 2 or 3 pre-selected, so that the application is not blank upon opening
- Could make this interactive as well: first, select city. then, option to select neighborhood (or whole city). then, option to select year (if available). Each dropdown menu would be filtered by the data available for that specification
Questions: Again, is an interactive like this useful? How many cities are too many to compare? (I would lean toward no more than 3 or 4 at a time)
The selections in the sections described above would control the application output.
- Desirable Properties for Application Output:
- For comparison, maps should always be kept at the same scale - i.e. if one zooms, all zoom. However, panning should be independent for each map, so users can look at the general areas they want to compare in their chosen cities
- Each displayed map should be labeled with its associated the city-[neighborhood]-year combination
- For communicating the summary statistics, can:
- Write the statistics into a prescribed report format, to be output below each map
- Create plots for each statistic of interest
(Using both would be redundant)
- For communicating similarity, can:
- Report a “best match” for all displayed areas
- Only report a “best-match” if a user inputs data, and do not report “best matches” for any comparison cities (for example, if a user comes on to this site and does not input data, no best matches will be reported)
Questions: Should we use reports or plots for communicating summary statistics? Regardless, do we want to display all or just some summaries? How will we define similarity - as a function of our summary statistics presumably, but how? Do we always want to display “best matches”, or only when users input data?
Walkability Analyis: Going Forward
After starting with a pre-set “starting archive” of comparison cities, the comparative power of the application will increase with its use, as users add data from more and more cities, neighborhoods, and potentially years to the archive. The result is a walkability comparison application that consistently grows in the strength of its information, and can be revisited over time to track improvement in this area of urban planning relative to other cities, or even a user’s own city over time.