Inspiration

A desire to use technology for social good. We knew we wanted to use the MTA's subway API, and we were inspired by the challenge theme of building tools to promote accessibility. We quickly discovered that there are many issues with the existing tools that are available to disabled people in NYC, including:

  • Many stations are not ADA accessible at all

  • Even if the station is accessible, not all subway lines in all directions are necessarily accessible

  • Delayed information about elevator and escalator outages

  • Google Maps often suggesting routes that involve buses AND the subway, where users would not get a free transfer. Google Maps has a "wheelchair accessible" option, but it is very new and is only available in a few cities.

  • No tools specific to individuals with visual handicaps (e.g. no reports of poor lighting in dangerous areas, inconsistencies between route changes that are posted on paper fliers in stations and changes listed on MTA's app and website).

What it does

RideAble optimizes realtime subway routes for mobility-limited and visually-impaired New Yorkers, improving upon the MTA and Google Maps' existing tools by incorporating crowdsourcing. Users can report issues and outages affecting disabled people within RideAble or via Twitter, and the route algorithm avoids those stations for people who have difficulty walking, seeing, or both.

How we built it

We pulled in realtime subway data and elevator/escalator outage data using APIs (MTA's GTFS Subway Schedule API, and NYC Accessible's elevator outage API at http://www.nycaccessible.com/api/v1/stations/), piped it into a Google Cloud-hosted MySQL database using Python and created logic that combines MTA data with user-reported outages and flags whether the station is inaccessible to mobility-limited riders, visually-impaired riders, or both. Then we wrote an algorithm and created a user interface that maps the most efficient route from the user's start point to end point, avoiding entrances, exits, and transfers at stations that are flagged as inaccessible, based on the user's disability. We also incorporated text-to-speech announcements of when the next train is coming, and an RFID payment system model (see "accomplishments" section).

GCP technologies

  • Cloud Buckets
  • Cloud Datastore
  • Cloud MySQL
  • Text-to-Speech
  • Maps API (Directions, Geocode)

Web technologies

  • NodeJs + Express
  • Vue.js
  • Google Maps JS
  • TypeScript

How it works

The web interface that does routing is based on the Google Maps Directions API. Currently that API does not support accessibility in their options, while the Google Maps App has a beta feature for wheel chair routing. Our original plan was to use the Waypoints feature, which allows use to supply an array of locations that must be included in the routing search, however, according to the Google Maps Directions API documentation (https://developers.google.com/maps/documentation/directions/intro#optional-parameters), using way-points with the transit mode is not supported. Since we want to use the transit mode for subway routing, we had to find another way.

To work around the limitations stated above, we came up with the following process:

  1. Find the GPS locations of your origin and destination google.geocoder.geocode
  2. Find the nearest subway stations to each the origin and destination that meets your accessibility needs (according to MTA API's) using the Haversine methods (getNearestStation.py)
  3. Call the directions API 3 times: From Origin to Subway Station 1, Subway Station 1 to Subway Station 2, Subway Station 2 to Destination

This particular approach is not universal and relies on the assumption that once in NYC's subway system, you either need to only take one subway line, or you can accessibly transfer across subway lines.

Challenges we ran into

We had some issues parsing the output from the MTA's elevator and escalator outages feed, so we ended up using an existing, external API (NYC Accessible API) that uses data scraped from MTA's website. Given more time, we would want to get the direct feed so that we can get the unique identifier for the elevator or escalator that is out of service. This would allow us to better flag any accessibility issues within subway stations, such as stairs-only transfers or certain entrances and exits that should be avoided.

Accomplishments that we're proud of

We built a miniature model of a subway turnstile that you can swipe into using an RFID bracelet. When you swipe in, it deducts from your balance, and even allows other users to pay for someone's subway fare. We know that the MTA is planning to upgrade to RFID cards, and we thought this might be a good model to promote greater physical and financial accessibility for disabled subway riders. We added a feature into the code so that when someone swipes their disabled friend or family member into the subway, the disability fare is deducted.

What we learned

We learned that there are still many barriers to access and gaps in service for disabled people who use the NYC subway system, and we hope that RideAble can drive some improvements.

What's next for RideAble

Whether it's ours or someone else's we would like to see an all-in-one mapping tool that holistically considers disabled subway riders' needs. We didn't have time to link the user-input values reporting an outage to a front-end form, but that is the most immediate next step.

Share this project:
×

Updates