Difference between revisions of "Accessibility Assessment"

Latest revision as of 12:56, 5 September 2014

return to PlanYourPlace

The WalkYourPlace Tool

WalkYourPlace Tool - link: http://webmapping.ucalgary.ca/WPSClient/

We have developed a web-based tool called WalkYourPlace for assessment of accessibility to urban facilities using “quality of life” indicators, such as the number of grocery stores, shopping and recreation facilities, and local crime. The system evaluates in real time an area that is accessible using pedestrian, transit, and cycling infrastructure. The WalkYourPlace system has been designed and developed based on principles of Spatial Data Infrastructure (SDI) and Service Oriented Architecture (SOA) frameworks to provide data and service interoperability. In the following sections we describe the tool requirements, system architecture, and particular problem solutions for the WalkYourPlace tool.

Tool requirements

For the design of the tool and its underlying architecture we need to consider:

1. the user group;
2. the activities that the user should be able to perform (i.e. the tool’s functionality); and
3. the context of use, such as the environment within which it will be used (Rubin and Chisnell 2008).

From the perspective of the PlanYourPlace project, the user group has been defined as citizens or community members that are interested in community planning. However, as noted earlier, users could also include prospective real estate purchasers, municipal planners and officials. Regarding users, we have to consider a wide range of demographic groups spread over different ages, different computer skill levels, and groups with different degrees of knowledge in planning. Based on these conditions initial requirements of the tool are: (1) it must be easy to use; and (2) results need to be understandable to the layperson.

Most likely, and with respect to the context of use, users will inform themselves about accessibility of a particular area from their home computer, or perhaps their mobile device (e.g. a smartphone). The tool should therefore be available at any time. Data required by the tool, such as pedestrian, cycling, and transit network data, as well as location information about available services, needs to be considered. Some data may also be sensitive in its raw form, for example crime data, and may demand that access be restricted. Operationally, it can be beneficial for data to be maintained and updated centrally. Given these considerations we extended our requirements to include (3): the tool is best provided via the Internet; and (4) the tool should be accessed via a web browser (i.e. not for download). A further requirement is that (5) data are best processed, evaluated, and maintained within a web-service-based architecture (see also Steiniger et al. 2012).

The requirements that can be derived from a user’s likely activities are similar to the points mentioned above when outlining problems of existing applications. In general the WalkYourPlace tool should: (6) calculate the accessible area or neighbourhood for a specific location (and time) provided by the user; and (7) calculate an accessibility score based on services (attractors), detractors (crime), and / or amenities within the neighbourhood.

Considering the possible improvements to existing tools, we derived the following additional requirements: (8) the accessibility area and score should be able to be calculated for a range of travel modes, such as walking, transit, and cycling; (9) the extent of an accessibility area should depend on the time that a user would like to walk, bike, or use transit; the accessibility area calculation should respect (10) topological constraints; and (11) (road) network distances rather than crow-flight distances. This means that (12) calculated accessibility areas and scores are estimated at the street level, and not at a generalized neighbourhood block level. To achieve this level of detail (13) the calculations should be performed in real-time whenever possible. Furthermore, (14) the user should be able to set the walk speed parameter with respect to their vitality, or age, and (15) the actual walk speed used should also consider topographic gradients. Finally, (16) dependence on data provider update cycles should be avoided to ensure a high level of reliability. Requirement (13), i.e., real-time calculation, will help here; as such a system will always calculate the most current score.

System Architecture

The WalkYourPlace system allows citizens to evaluate accessibility for a certain location, e.g., their home, or a road intersection in the city. The system has been designed and developed using a service oriented architecture. The several logical and physical components of the system communicate over the Internet with each other via standardized communication protocols. The various components provide: (i) data resources, e.g., transportation network data, point of interest data such as parks, shops and banks, etc.; and (ii) services that work on / process this data, e.g., a network routing service, a transit schedule analyser, an aggregation service, etc. The use of a service-based architecture allows modifications to the system, e.g., to the accessibility evaluation models, without adversely affecting the system in general. It enables the calculation of accessibility areas and scores in real-time, as processing demands can be spread over several servers. Furthermore, it enables access to distributed data sources via data access interfaces such as WFS, WCS, or REST (see below). This allows the diverse data used for accessibility evaluation, and for map display, to be maintained by different data custodians.

In Figure 1 we present a generalized view of the physical architecture for the WalkYourPlace tool. The user interface in this architecture is the user’s web browser. The entry component, i.e. the WalkYourPlace web page and map client, is loaded into the browser from the WalkYourPlace Web Server. The user triggers the accessibility evaluation tool by identifying a start location on the map component. Then the “Workflow Management Module” within the web processing service (WPS) will trigger one of the different accessibility evaluation models located on the Accessibility Model Server, for instance the WalkYourPlace Pedestrian Model. This model, then, performs the evaluation by obtaining data from the Data Server, and by interacting with the different services on the — perhaps different — Back-end Processing Server(s). Additionally we have included in Figure 1 a separate Base Map Server, which provides (street) maps that can be displayed directly to the user via the map client module on the web server. The term “directly” means that the maps are displayed without changes or additional processing.

Figure 1: A physical perspective of the WalkYourPlace system

Communication and data delivery between the components is accomplished using standards published by the World Wide Web Consortium (W3C) and the Open Geospatial Consortium (OGC). This implementation has adopted the following standards: (i) W3C’s REST architecture style (Fielding 2000), (ii) the (Geo-) JSON standard that specifies a data interchange format (geojson.org), OGC’s Web Processing Service (WPS, Schut 2007) to calculate the accessibility score for an accessibility area, and (iv) OGC’s Web Map Tile Service Implementation standard (WMTS, Maso et al. 2010) to display zoom-able maps of the urban area in the map client. Other OGC standards are also represented in Figure 1 as these services could equally be adopted for the retrieval and presentation of geographic data.

From a technical perspective, Figure 1 illustrates a service architecture, which reduces the complexity of creating and reusing geospatial-processing services. From a service design perspective, a bottom-up approach was used to design the geospatial-processing service framework. The bottom-up approach allows services to be assembled until an appropriate granularity is achieved and service candidates are determined (Kralidis 2007). The composition process is continuous and iterative, and stops when application requirements are met.

The geospatial-processing service framework includes several accessibility models. Each performs the accessibility analysis through chaining of geospatial-processing services in a multi-step pattern, i.e. a workflow. To achieve desired application flexibility, service reusability, and improve performance, the workflow-managed chaining method was used (Alameh 2003).

Solutions for a selection of requirements

In this section we outline how we fulfilled some of the requirements listed in subsection 3.1. We address in particular: (i) how we create accessibility areas; (ii) how, and what types of accessibility scores we calculate; (iii) how we address the data provider dependency problem; and (iv) how we refined accessibility area generation with respect to the effects of (a) topographic gradients, and (b) user vitality. All descriptions are kept fairly brief as the detailed solutions, in most cases, can be explored by studying the source code that is accessible to the public at http://www.opentripplanner.org and this page.

Creation of an accessibility area

• Pedestrian accessibility area generation — A graph is generated from a transportation network that includes both, roads and pedestrian paths. Given a user location, a maximum time the user is willing to walk, and average walk-speed, a least cost path (graph) is generated using the A* search algorithm (Delling 2009), and a Shortest Path Tree (SPT) is produced. Roads that cannot be traversed by pedestrians, such as freeways or streets without sidewalks, are excluded in the shortest path search heuristic. The resulting SPT contains nodes and edges from the transportation network. The nodes of the SPT are equivalent to the road/path intersections, and are augmented with the travel time from the start location to that node along the SPT. To obtain the accessibility area a concave hull geometry is generated from the set of edges and sub-edges within the maximum walk time. The concave hull algorithm used is described in Duckham et al. (2008) as implemented by Grosso (2012). The generated concave hull is assumed to be the final accessibility area.
• Transit accessibility area generation — In principle we have two options for the calculation of transit-accessibility areas. Both are a combination of walk and transit modes. In option (a) the “Integrated Transit-shed,” we define a general maximum travel time and combine routing on a transit graph and a road network graph. Shortest path routing uses a Multi-Objective A* algorithm (Mandow and Perez De La Cruz 2010). In option (b) the “Explicit Transit-shed,” we parse transit schedule data and use road network routing only for the walk part. In this option we distinguish between
  1. the maximum travel time,
  2. maximum time to find a transit stop / route,
  3. the maximum transit waiting time, and
  4. the maximum transit travel time.

Only the integrated method will be evaluated later in this work. The explicit transit shed method generates two accessibility areas #by using the maximum time to find a transit stop and the maximum travel time. The accessibility area derived using the maximum time to find a transit stop is searched for transit stops. For the set of transit stops identified, the transit schedule data is parsed with respect to user defined transit wait times and travel times. Application of the initial restrictions, i.e. starting time, waiting time, etc., determines which transit routes are actually accessible to the user. Once the set of routes are identified the transit network is searched to identify the closest transit stop on each route to the user’s start location. The third restriction, transit travel time, is then used to identify all transit stops within this time from the closest transit stop. For each transit stop that can be reached within the maximum transit travel time, a new accessibility area is generated using the maximum walking time minus the time taken to walk to the closest stop, minus the actual transit travel time to a stop along the route. If the remaining walk time is less than 3 minutes it was increased to 3 minutes to ensure that nearby services to a transit stop can be reached. The union of the original user location’s walk-area (calculated using the maximum travel time) with the accessibility areas for each transit stop forms the final transit accessibility area. The union may well result in a multi-area geometry.

• Cycling accessibility area — Estimation of this area follows the approach presented for pedestrian accessibility area generation. However, the road network graph traversal speed is higher (18 km/h), and access restrictions for pedestrian only zones and one-way roads are observed when the SPT is generated.

Calculation of four different accessibility scores

To calculate an accessibility score, the “content” of an accessibility area, i.e., (a) the circular; (b) pedestrian; (c) cycling; and (d) transit areas are analysed. In the content analysis we look for certain types of services, such as parks, stores, libraries, etc. If they exist, then they receive a weight, which may decay the further away the service is from the start location. We believe that application of a distance decay function makes logical sense, in so far as we think a user is more likely to walk to a service that is nearby, as opposed to the same service further away. In a sense this is an adaptation of Tobler’s (1970) First Law of Geography, all services are accessible, but those nearby are more so. The user is able to decide whether or not the distance decay function is to be used.

Adopting WalkScore’s (2011) approach, for certain types of services it is beneficial if more than one service is found within the accessibility area, e.g. for shops and restaurants. If this is the case, then the second and third services receive weighted values as well, but their contribution to the score will be less than the initial service. For example, up to five shops can contribute to the score using the following weights, 0.5 for the first shop, 0.45 for the second, reducing to 0.4, 0.35, and 0.3 for the fifth shop. However, for other types of services, such as banks, parks and schools, additional services do not contribute to the accessibility score. The final score is an aggregation of the (distance-weighted) scores for each relevant service identified within the accessibility area. The score is then normalized such that the minimum possible score is 0, and the maximum possible score is 100. When distance weighting of the scores is applied, all services within 400 m, or a 5-minute walk of the start location retain their full weight. A linear function is then used to reduce the weight of a service from 1 to 0 for all services that are between 5 and 15 minutes from the start location. For the circular “as-the-crow-flies” model the maximum distance used for weighting was 1,609 m (i.e. one mile) to allow replication of the WalkScore “Street Smart” approach. For our circular model, however, we set a maximum distance of 1,250 m to reflect a 15 minute walk at 5 km/hour.

We have attempted to replicate the WalkScore (2011) methodology for comparison purposes. In this model, and with respect to our point of interest dataset, we account for the following service types:

• grocery stores,
• restaurants,
• shopping (shopping & business),
• cafés and bars/pubs,
• banks (ATMs),
• parks,
• schools,
• books (libraries & book stores), and
• entertainment (cinemas, sport venues, museums).

We have also extended the model, which we call the WalkYourPlace (WYP) Score, to include (10) hospitals, and (11) pharmacies, as recommended by Doi et al. (2008). Additionally, we added an option to display a (generalized) crime-rate as suggested by Carr et al. (2011).

In Figure 2, we show an UML sequence diagram that outlines how the WYP accessibility score is calculated for pedestrian access. The client sends a WPS Execute command to the WYP management service, which then initiates an execute call to the WalkShed WPS. The WalkShed WPS returns a GeoJSON polygon of the network-based accessibility area. The Management WPS then sends an execute request to the Point of Interest (POI) WPS to find all attractors (services) within the accessibility area. The POI WPS returns a point set of services encoded as GeoJSON points, along with attributes describing the types of features found. The Management WPS then repeats the same request to the Crime WPS to obtain incident locations. Finally, the Management WPS sends an execute request to the Aggregation WPS along with the accessibility polygon and the responses from the POI and Crime WPS’s. The response from the aggregation WPS is the accessibility score (i.e. the WYP score), the crime score, and the accessibility area. The Management WPS then returns the coloured accessibility area and the accessibility score to the client for presentation.

Figure 2: Sequence diagram for the calculation of the WalkYourPlace pedestrian accessibility area score.

In addition to the accessibility score called “WalkYourPlace Pedestrian Model” in Figure 1, we applied the WalkScore score calculation to the circular neighbourhood, the “WalkScore Model.” That model allows us to compare our implementation against WalkScore’s as there may be a bias due to the use of different data sources. We also applied our WYP scoring method to the circular neighbourhood, calling it “WalkYourPlace Crow-Flight Model,” to determine the effect of changes introduced by the WYP score, and to identify the effect of a smaller accessibility area that is comparable to a 15-minute walk. Application of the WYP scoring method to the transit and cycling accessibility areas, the “WalkYourPlace Transit Model” and “WalkYourPlace Bike Model”, enable comparison of accessibility scores based on differing modes of travel.

Addressing data provider dependency through the use of OpenStreetMap (OSM) data

For the generation of transportation network graphs, and for the points of interest, such as shops, banks, restaurants, etc., data can be obtained from specialized data providers. However, the typical update cycle is between 3 months and 1 year (Navteq 2013, TomTom 2013). Changes to a transportation network due to road construction, new, or closed sections, will influence calculation of the accessibility score. Consequently, score values may be updated somewhat infrequently, which will affect system reliability. For this reason, the PlanYourPlace project has decided to build its database upon the free OpenStreetMap database. The advantage of OpenStreetMap in comparison to commercial data providers is that OpenStreetMap offers online tools, such as Potlatch, that allow updates to the database when the user encounters changes in their neighbourhood. Today, these updates find their way into the official OpenStreetMap database within minutes (Coast 2012), and the user can access the updated database immediately. However, a disadvantage may be that an OSM contributor, willingly or unknowingly, can also lower data quality at the same time, due to the false placement of tags, or incorrect database edits (Haklay and Weber 2008).

Point of Interest (POI) data can also be extracted from OpenStreetMap using the OSM API, with the limitation that geographic queries are restricted to the use of a bounding box. However, data can be extracted for a region, stored locally, and updated on an hourly basis (or more frequently) if need be. Alternative POI sources include the CityGrid Places API (developer.citygridmedia.com), Factual (factual.com), and FourSquare’s Venue database (developer.foursquare.com), among many others. It must be recognized though, that most of these sources restrict the use of their data to certain activities and or jurisdictions, and limit the number of times that the API or data may be used within a certain period.

Accounting for user vitality and slope effects during generation of accessibility areas

We believe that it is also important to consider the vigour of a user, and offer the user the opportunity to set walking speed according to their physical capability or mood. While there is some evidence that walking speed can be correlated with age (Schimpl et al. 2011), we also consider that other factors may affect someone’s walking speed, such as their general health, their desire to walk with others, or the need to carrying goods. As such, we have chosen to not add an age parameter directly to the model, rather, we allow a walk speed parameter to be set by the user, according to how fast they would like to walk.

The traversal speed of a road segment, or network graph edge, also depends on its slope. This becomes evident when walking up and down roads in San Francisco, in Calgary’s Hillhurst neighbourhood, and many parts of cities such as La Paz (Bolivia), and Medellin (Colombia). To account for street slope when walking, we implemented Rees’ (2004) quadratic slope function that adjusts walk speed according to slope. The function was derived by W.G. Rees based on measurement of his own hiking speed and assumes, for a flat route, a walk speed of 4.8 km/hour (1.333 m/sec). Cycling accessibility area calculation also accounts for slope effects. Data used to relate road slope to cycling speed have been derived from the Analytic Cycling webpage (Compton 1997) and are approximated using a quadratic B-spline function.

Limitations and Future Work

The results demonstrate that the current version of WalkYourPlace improves existing access evaluation tools, such as Walkscore.com, through the application of a model that more closely reflects how people actually access services in an urban environment, that accounts for physical constraints commonly encountered by people when walking, cycling or using transit, and because the system offers some flexibility to the user. However, it also has several limitations, which, during implementation, has resulted in the emergence of additional research questions. One questions is “How should the system account for crime as a detractor in the estimation of an accessibility score?” At this time we have chosen to displayed crime as a separate indicator. In addition to accounting for crime, the routing process and the accessibility evaluation should consider other detractors, such as traffic speed, traffic volume, number of pedestrians, and bike and /or pedestrian accidents.

Related to these measures is the evaluation of micro-environmental features, such as sidewalk quality (width and surface smoothness), frequency of street crossings, shade, etc., which are also not accounted for at the moment. Mouzon (2012) has highlighted how important environment-dependent appeal is on the likelihood of a person to walk. He notes that the walking experience from one shop to another that requires the walker to cross a suburban (strip) mall parking lot is quite different, i.e. less appealing, than a walk between two shops in an inner city. Similarly, Porta and Renne (2005) investigated walk appeal related measures such as road width, setbacks, existing street furniture, façade continuity, existence of trees, etc. Such measures should be included in the calculation of accessibility indices for both pedestrian and cycling modes. Even the use of transit is likely to be affected by its appeal, i.e., attractiveness of the bus/train/tram itself (for instance in the discussion after the keynote by D. A. Hensher at CASPT’12, Santiago de Chile, it was mentioned that a bus as attractive as an iPhone is needed to make more people use (rapid) bus transit systems in western cities), or the amenity/appeal that a transit stop provides (Jiang et al., 2012). An option to account for appeal, may actually be to offer and evaluate 1-5 star ratings at a neighbourhood or street level, possibly derived from online shopping portals.

Currently, the WYP client is a webpage that works with desktop web browsers and tablets. Development of a smartphone application would be the next step. Additionally, usability of the current client application should also be evaluated. An interesting question that usability testing could evaluate is: “What is the effect of an attractor/detractor just one minute further away on a users desire to access a particular service? Is it important to show them or not?” Another topic that usability testing could address are measurements of the tools performance with respect to response time, i.e., how long it takes for the system to respond to a request.

Finally we note that the use of the existing WYP website may be cumbersome when a new family home location is sought. In this case, each family member might want to calculate accessibility scores that meet their needs – probably using different travel times, travel speeds, travel modes, and varying transit schedules (weekdays vs. weekends, and peak hours vs. non-peak hours). How scores for a family or user group could be aggregated then, is another open question.

References

• Alameh N (2003): Chaining Geographic Information Web Services. IEEE Internet Computing 7: 22 – 29
• Carr L J, Dunsiger S I, and Marcus B H (2011): Validation of walk score for estimating access to walkable amenities. British Journal of Sports Medicine 45: 1144–1148
• Coast S (2012): Breakfast with Microsoft’s Steve Coast. presented at the Tecterra Breakfast Meeting, November 21, University of Calgary, Calgary
• Compton T (1997): Analytic Cycling - Speed. WWW document, http://www.analyticcycling.com/ForcesSpeed_Page.html.
• Delling D (2009): Engineering and Augmenting Route Planning Algorithms. PhD thesis, Universität Karlsruhe (TH), Fakultät für Informatik. http://d-nb.info/1013721748/34
• Doi K, Kii M, and Nakanishi H (2008): An integrated evaluation method of accessibility, quality of life, and social interaction. Environment and Planning B 35: 1098–1116
• Duckham M, Kulik L, Worboys M, and Galton A (2008): Efficient generation of simple polygons for characterizing the shape of a set of points in the plane. Pattern Recognition 41: 3224–3236
• Fielding R T (2000): Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, Irvine: University of California
• Grosso E (2012): Concave Hull Based on JTS. WWW document, http://www.rotefabrik.free.fr/concave_hull/
• Haklay M and Weber P (2008): OpenStreetMap: User-generated street maps. IEEE Pervasive Computing 7: 12 –18
• Kralidis A T (2007): Geospatial web services: The evolution of geospatial data infrastructure. In A Scharl, K Tochtermann, L C Jain, and X Wu (ed.) The Geospatial Web: Advanced Information and Knowledge Processing. London, Springer: 223–228
• Mandow L and Perez De La Cruz J L (2010): Multiobjective A* search with consistent heuristics. Journal of the ACM 57: 27
• Maso J, Pomakis K, and Julia N (2010): OpenGIS Web Map Tile Service Implementation Standard. Open Geospatial Consortium Inc. http://www.opengeospatial.org/standards/wmts
• Navteq (2013): Shop & Update. WWW document, http://allthingsnav.navigation.com/page/shop-update
• Rees W G (2004): Least-cost paths in mountainous terrain. Computers & Geosciences 30: 203–209
• Rubin J and Chisnell D (2008): Handbook of Usability Testing: How to Plan, Design and Conduct Effective Tests. 2nd ed. Indianapolis, Wiley
• Schimpl M, Moore C, Lederer C, Neuhaus A, Sambrook J, Danesh J, Ouwehand W, and Daumer M (2011): Association between walking speed and age in healthy, free-living individuals using mobile accelerometry - a cross-sectional study. PLoS ONE 6: e23299
• Schut P (2007): OpenGIS Web Processing Service. Open Geospatial Consortium Inc. portal.opengeospatial.org/files/?artifact_id=28772&version=2
• Steiniger S, Poorazizi M E, Bliss-Taylor C A M, Mohammadi E, and Hunter A J S (2012): PlanYourPlace: Merging social networks and participatory GIS for participatory planning. In FIG Working Week 2012. Rome, Italy
• Tobler W (1970): A computer movie simulating urban growth in the Detroit region. Economic Geography 46: 234–240
• TomTom (2013): Update Your Map. WWW document, https://www.tomtom.com/en_gb/shop/mapupdateservice/
• WalkScore (2011): Walk Score Methodology. WWW document, http://www2.walkscore.com/pdf/WalkScoreMethodology.pdf

Appendices

Appendix - A : POI Weights

see AggregationService.py (on 8. April 2014)

• "ATM": [1],
• "Business": [.5, .45, .4, .35, .3],
• "Grocery": [3],
• "Restaurant": [.75, .45, .25, .25, .225, .225, .225, .225, .2, .2],
• "Bar": [.75, .45, .25, .25, .225, .225, .225, .225, .2, .2],
• "Shopping": [.5, .45, .4, .35, .3],
• "Cinema": [1],
• "Park": [1],
• "Sport": [1],
• "Hospital": [1],
• "School": [1],
• "Library": [1],
• "Museum": [1],
• "Pharmacy": [.5, .45, .4, .35, .3],
• "Bookstore": [1]}

Appendix - B : Crime Weights

see AggregationService.py (on 8. April 2014)

• "Arson": [1, 1, 1, 1],
• "Assault": [10],
• "Attempted Murder": [4.5, 4.5],
• "Commercial Break-In": [.5, .5, .5, .5, .5, .5, .5, .5, .5, .5],
• "Homicide": [9],
• "Residential Break-In": [.5, .5, .5, .5, .5, .5, .5, .5, .5, .5],
• "Robbery": [2, 1.5, 1.5],
• "Sex Offence": [10],
• "Theft": [.4, .4, .4, .4, .4, .4, .4, .4, .4, .4],
• "Theft From Vehicle": [.3, .3, .3, .3, .3, .3, .3, .3, .3, .3],
• "Vandalism": [.2, .2, .2, .2, .2, .2, .2, .2, .2, .2],
• "Vehicle Theft": [.1, .1, .1, .1, .1, .1, .1, .1, .1, .1]}