Inspiration
I've been canvassing for grassroots campaigns for the past few months-- the software tools they use aren't nearly up to speed when compared to corporate-funded political campaigns. For one thing, when volunteers are sent out to knock on doors, they must visually inspect their canvassing turf visually and plot a route abstractly. Humans aren't too great at that, and it leads to some unfortunate inefficiencies. Canvassing can take 2 hours where it should take 3. It's inefficient in terms of time, but it's also a waste of moral. Finishing a turf more quickly may mean that a volunteer can go out and make another route. It may also avoid participant frustration and increase the rate at which volunteers return.
What it does
QuickCan is a tool for static analysis tool for creating efficient multi-person traversal of door-to-door routes.
Although we have produced a platform-agnostic, front-end mobile applet to demonstrate the use of our project, our main deliverable is a restful API which allows low-budget projects to divide up and route any list of addresses. This could be useful in food drives, girl-scout-routes, and anything which involves going door-to-door in a community. In this way, QuickCan manages to be extensible and provides a useful utility for many existing services, as well as those which have yet to be built.
QuickCan is useful for making individuals experience with volunteering more efficient, and increase volunteer usefulness. In addition, this static analysis can be performed by organizations in order to choose which turfs to give to which volunteer groups-- some maps lend themselves to groups of 3, while some tight clusters are easily done by 1 volunteer.
How we built it
QuickCan's backend was built on top of python Flask. The front end is built on top of Ionic with TypeScript and Angular2.
We generated a distance matrix using minimal calls from the google maps API and used them to find points which were most distant from one another.
We then used a greedy algorithm written in python for our routing. This algorithm simply gulps down addresses one by one by choosing the closest address to the volunteer with the lowest total-route-duration-so-far.
Challenges we ran into
We decided to add a constant amount of time per stop in our routes to compensate for the average time spent building. We weren't sure what a reasonable amount of time to ad would be.
Google maps front end API only allows single character labeling of their anchor points by default. We wanted to show the list of visited houses to demonstrate our apps abilities. To adapt to this constraint, we had to label our anchor points with ad-hoc generated SVG's of double digit numbers and integrate them into the app with a little hacky-css.
As our problem is inherently NP complete (think TSP!) validating our route's optimal was impossible. Though we could compare different variations of our code to see which was "better", it was difficult to discern which was the "best".
We found quickly that the google maps API was prohibitively expensive for some of the operations we were performing. We have some ideas for significantly reducing query-cost, but it will take some experimentation.
Accomplishments that we're proud of
This project was an excellent choice of scope for a hackathon of this size. We were able to segment labor among our duo nicely to quickly build the the query adapter for grabbing distance data from google drive.
We then had time to consider different algorithms and, while we ended up choosing the one we thought we could finish within the time slot, it was interesting and fun to consider different approaches.
We feel that our app is well tested, extensible and useful for a variety of purposes. We are proud of what we were able to accomplish with a two person team.
What we learned
Gabriel - Learned a lot of TypeScript, Angular2, Flask and Ionic-- I'd never used them before! As an express/Node/electron preferring developer, it was a breath of fresh air to try out a new framework under the guidance of a patient and helpful friend.
What's next for QuickCan
We would like to try out QuickCan with different underlying algorithms on different maps and see which works the best. Starting-address-selection and map routing are both interesting and unique problems with a lot of solutions available online which deserve careful experimentation. Ant-colony-optimization algorithms look promising, as do genetic algorithms. Since we're able to quickly cache a distance matrix between addresses, and our analysis is expected to be a once-per-organization-per-list run, we should be able to run a complex algorithm to get the most optimal results.
We would like to improve our API, thoroughly test with different routing algorithms/maps, and present it to existing canvassing apps for free use!
Log in or sign up for Devpost to join the conversation.