We have all been waiting at the airport gate with a small amount of time to make our connecting flights. The stress added to an already stressful event for some people leads to lower customer satisfaction. The goal was to alleviate that stress for the customers and give them and easy way to make their connections.
What it does
QuadA allows for the user to find their flight from the flight-engine and get the relevant information about their upcoming/current flight. The current heat map for both the origin and destination airports is shown to allow the user to avoid the most dense parts of the airport. In addition if the destination airport is the user's final destination or the flight has been delayed through the use of google places api an assortment of food/lodging is offered to the user.
How we built it
We started with making a few changes to the flight-engine api. First, we added some new fields: terminal, delay, delay duration. Second, we add the ability to query all the available airports through ip:3030/airport. Last, we added a few more airports for a more realistic data-set. From there we started with the google geocoding api to plot all the available airports onto a world map to make finding the user's flight a two click process. Once the origin and destination airports were selected we query the flight-engine api in order to find all available flights that match the user's parameters. Once a time is chosen we shift to the airport view which is taking advantage of google's geocoding map / heat map layers. By polling the flight-engine api to see which flights were arriving or departing within 30 mins of the user's flight arrival and creating a weight algorithm to determine if the terminal would be deemed "busy", "normal", or "light". From this data we created a real time heat map to allow the user to avoid the dense areas of the airport. In order to host all of this we decided to use AWS' EC2 server. We have the proper security rules to allow traffic from the flight-engine api running on port 3030 and to allow our html/css/js files to be properly served on port 3000.
Challenges we ran into
We ran into a couple of challenges. At the start, our plan was to use the yelp, uber, and lyft apis in order to give the user a simple way to find something to eat or do through yelp and get a ride through the ridesharing services. This fell through because unfortunately all three required some sort of business api key which we did not gain access to in time. Our next best option was to use google-places in lieu of yelp. However, we did not find a replacement for the rideshares.
Accomplishments that we're proud of
We are proud that we were able to incorporate three different apis all of which are "sharing" data between each other,which elevates the functionality of each one. Also, we think our UI is simple and easy to pick up with little to no instructions.
What we learned
We definitely got a lot more practice with pulling from an api and using it with other apis. Since none of us have ever really done front-end we learned a lot about how to keep things simple yet effective to get the job done.
What's next for QuadA
We would really like to get access to those ridesharing apis in order to implement that functionality to the user. Furthermore, we think we could clean up some of the redundancy in our code that comes from the time constraint and multiple developers. We also had plans to add staff alerts when a high number of delays were found at an airport to be ready for the customers looking to change their flight plans due to the delays.