Efficient Events

Optimizing Traffic For Your Next Event - calculating the best possible start time to minimize traffic congestion for everyone

Comment 1

Inspiration

People don't like waiting in traffic. People don't like being late for their favorite artist or a meaningful sports game. However, traffic is inevitable when tens of thousands of people are commuting to the same event. What if there was a way that we could could analyze traffic data and traffic patterns to suggest start times to venues and departure times to users?

Our goal in making Efficient Events is to maximize the time-efficiency of both large-scale venues and individual consumers. By creating Efficient Events, we believe that we can reduce traffic congestion, prevent traffic fatalities, save time for the user, and earn money for venues.

Each minute of time that we save our users is a minute of time that they can spend doing something instead of sitting in traffic and is an invaluable success to our team.

Efficient Events is applicable for any event, whether it be sports games, concerts, hackathons, conferences, or even schools and their start times.

What it does

Here's how Efficient Events can be used for the next Warriors Game or baseball game at Oracle Park. Event organizers add in the addresses of everyone attending, the destination address (the stadium/event location), and add a time range on the day at which the event could possibly start. For example, the possible start time range could be 1/5/2024 from 7 to 10pm. By taking all the addresses of people attending the event, the destination, and the time range, the website will calculate travel times for multiple times inside of that range. Whatever arrival time takes the least amount of travel time for everyone will be the suggested time of the event!

This way, attendees spend less time in traffic and the overall congestion in traffic of the whole city will be reduced.

How we built it

We decided to build a website using HTML, CSS, and Javascript.

Here is a quick overview of the technologies used:

  • Inrix API
  • Free Geocoding API
  • OpenLayers
  • Chart.js
  • Node.js

The Inrix API was used in order to get travel times for all locations at all possible times. The Free Geocoding API was used in order to convert text addresses to latitude and longitude coordinates. OpenLayers was used to show the interactive map, as well as mark the locations of the attendee addresses and destination. Chart.js was used to make an interactive line graph that compares arrival time to average travel time for attendees. Node.js was used to run a server and make API calls to automatically update the Bearer tokens used for the Inrix API.

Challenges we ran into

Rosalie - A challenge I ran into was working with Node.js and getting the server to run. I had never before worked with Node.js, but I had been wanting to. So, this hackathon gave me a good opportunity to try that out. I was able to successfully install node.js and get the server running. After navigating some core issues I was also able to make API calls onto that server. This made it so that I did not have to update the Bearer token for the Inrix API every couple of hours (instead it updated itself)!

Another challenge I faced was a "Too Many Requests" error message from the Inrix API. Since the website is making a lot of calls, the rate limit on the API started complaining. I solved this problem by adding delays (which is not a nice solution but it works). With a non-demo API key, this issue would most likely vanish.

Kevin - A challenge for me was my severe lack of experience. However, through my hard work and hours of studying HTML, CSS, and other debugging websites, I am proud of what I contributed and what I have learned.

Accomplishments that we're proud of

Rosalie - I am proud of both the presentation and the implementation of this project. I believe the project looks very good and polished, and I feel like I was able to seamlessly integrate multiple different APIs. I am also proud of how done this project is. During previous hackathons I sometimes felt like I had to round some corners in order to finish. However, this project is finished and scalable. It supports as many addresses as needed (in whatever locations as well), as well as a time range of however long the user wants.

Kevin - I am incredibly proud of the amount of knowledge and experience I have gained through this hack-a-thon. I believe that I have gained more valuable and practical experience during this hack-a-thon than I have this entire semester in my Computer Science class.

What we learned

Rosalie - I learned to use a bit of Node.js and host servers on my computer.

Kevin - In order to meaningfully contribute to my team, I needed to give myself a crash course in HTML and CSS to make our project's home page. I now feel that I have a solid knowledge of the basics of HTML and CSS and can't wait to use these new skills in personal projects of my own.

What's next for Efficient Events

No project is ever truly complete. We are proud of what we have done with Efficient Events, yet there are many more features that we will soon look to implement.

The most impactful design feature that we plan on implementing is taking parking data into account in our calculations. By considering parking data (parking meters, free parking spots, parking garages, etc), we will be able to give our users and venues much more optimized and accurate data. Not only can we provide them with an optimized time to leave for their event, we can also provide them with where to park.

Right now, the website is splitting the time range into 30 minute segments and calculating travel times using those 30 minute segments. If the rate limit problem is solved, these segments could be reduced to 5 or 10 minute segments to greatly improve accuracy.

Share this project:

Updates