Accessibility Map

Team Members

Hannah Smith

Zahra Wright

Noah Kastelman

John Gibson (TA)

Description

We are creating an “Accessibility Map” program available to WashU students and visitors. This map will tell you the most efficient route to take while on the WashU campus. This will allow students or visitors to get different places as quickly as they can. It will also be able to tell you the best route if you are handicap by taking out the pathways that are not handicap accessible.

Tutorials

How to Download and use Python using Git

Implementing Dijkstra’s Algorithm Into Python

Components

Map

Paths, Buildings, Distances -we will be collecting data to input into our algorithm -this will include routes both handicapped accessible and not

Algorithm

Dijkstra's Algorithm - with inputed data distances, this will compute the shortest distance between a destination and current location

Display

Website ArcGIS - we want to display the fastest route using a website display.

Challenges

As a group, we will have challenges adapting to a new coding language (python) and adjusting our algorithm, GIS, to match our goals.

We have had challenges using arcGIS as a tool and not as the whole project. Because we have been learning how to use many different new tools, we have become distracted from the goal of making an actual product.

We will also need to figure out how to take the data from ArcGIS and export it so it is available for others to use.

Creating a line on a map so users know where to go.

'Final Product Expectations

• export arcGIS nodes and lines of WashU's campus
• enter into shortest route google maps like program

We will create a wheelchair map and a able-bodied map. It will be an option for the user.

ArcGIS will be exported into an excel and the fastest route will be calculated for each possible route. Then a map showing the line from point A to B will be displayed.

Finished Design Description

We noticed a problem here on WashU’s campus, that not only is it inaccessible to those with differently abled bodies, but that it is also hard to navigate in general. The only point of help in finding a way around WashU’s campus is the WUSTL app, which only shows where a building is, and not how to get there. Our project, titled Accessibility Map, had three main goal components we set out to accomplish: Creating the networks of paths on WashU’s campus, implementing Dijkstra’s algorithm into Python using these paths, and finally, to create a interface showing this path.

The first was creating a graph containing nodes at all intersections and possible entrances/exits on campus. During this step we used ArcGIS to create these nodes, and connected the nodes to make paths, and recorded the distances into an excel spreadsheet. We then labeled all of the nodes, and labeled the path connections between the nodes, which is needed for Dijkstra’s Algorithm.

Our second goal was implementing Dijkstra’s algorithm via Python, an algorithm for finding the shortest paths between nodes in a graph. The graph we created in ArcGIS was then needed to be manually transferred into excel sheets, one for each level of accessibility (in this project there were only two levels). Each value gets put in twice because each cell has an origin and destination and the paths go two ways. For the cells (aka nodes) with the same origin and destination we put 0 and for the cells where the locations do not directly connect we put 100000 so the paths would not be chosen, as their path value would be too high, and Dijkstra’s calculates the shortest path based on the least cost of each path. Then, for the excel spreadsheet for accessible paths, all paths with stairs were given the value of 100000, in order to mimic the path being blocked. The Python then implements Dijkstra’s algorithm with the updated excel sheet values of paths and distances: In our version of Dijkstra’s algorithm, we made a set that kept track of nodes whose minimum distance from the starting point was calculated, and this set is empty at first. The nodes are then assigned a distance value initially as the value 999999, and the starting point has a value of 0, so it is chosen first. While the set doesn’t have all of the node values, the nodes that are not in the set are given the minimum distance from the starting point, and then are added to the set. Then the cost of going to adjacent nodes from each node is calculated based on the edge’s distance with or without weight (based on accessibility). The cheapest of the paths is deemed the shortest path to that node, and the paths’ for the new node is updated. The cheapest paths are chosen until the ending node is reached.

Our final goal was to create a GUI, or graphical user interface, to make this project useable. In the GUI we included an image of a map of WashU’s campus, with numbers denoting the different possible starting and ending locations. We also included a helpful list of names associated with some buildings that are commonly used in case the user was not familiar enough to know where they wanted to go from the image itself. The GUI itself was created with Python, using Tkinter to create some of the user aspects. The previously described characteristics were all stationary and the user could not directly interact with it. However underneath those set images were two drop down options containing the users chosen starting and ending points. Underneath were two buttons, one that would generate an accessible fast route, the other creating a route for those that are able-bodied. Once clicked, the program would then display an image of the map with the most efficient route drawn directly on it. The code written to accomplish this was one where we found the coordinates of each node, connected those values with whatever route Dijkstra’s algorithm described to take, and would then draw lines on the image. We have included Figure’s 1 and 2 of what the interface and the path drawn as images look like.

Putting these components together was a challenge for us, as our group had only previously taken the beginner computer science class, CSE 131, but wasn’t impossible to do in Python.

Improvement for the Future

If we had another semester to work on this project there are multiple aspects we could improve. First we could make more layers of accessibility, and this requires more excel spreadsheets with differently weighted distances to incorporate more types of paths that vary. These distances may vary based on elevation, whether the surface is made out of grass or is concrete, or if the path is wide enough for a wheelchair, just to name some options of accessibility. This directly affects anyone using the interface, not just people who are deemed ‘disabled’ as these capabilities of accessibility can apply to the injured, or even elderly people. Also, some people are able to use stairs, some people may not be able to go uphill, or some may struggle with a large number of stairs but can do a few, for example. Another improvement that could be made is incorporating new data of paths and distances of the whole campus into the code. As of now, we only have from Olin Library to Brookings. If we mapped out distances for the entire school it could be more useful, and could even be mapped out for other campuses/areas of St. Louis. Lastly, the accessibility map could be made into a mobile app. That way anyone would be able to use it remotely, without needing a computer (or, even wifi).

Visuals of Project

Gantt Chart

Poster

poster
Link to weekly log