Front end web development for an experimental Traffic forecast algorithm
During the first few months, after the STEM event had run its course, I had the chance to pair up and work with a PhD student on his dissertation about an AI based traffic forecast and analysis tool. His project was to create a tool that analyses past traffic levels in certain areas of a city, based on available traffic information, and correlate them with events and environmental changes that happened in the same time span. This in theory allows the tool to more accurately predict future traffic saturation based on planned events or the weather forecast, as well as to look for any anomalies that would be caused by abnormal events like an accident.
In the part of the project I worked on, we were making a web-based notification hub where his tool would flag any said anomalies and provide a way for traffic management to give feedback on whether the AI was right or wrong.
Challenges and things I learned:
We used a web-socket based server to handle connections to the website. It was hosted on Amazon’s AWS. The content consisted of a table of current and past notifications with several fields on each entry asking for feedback on whether the algorithm was correct, and if so, what kind of anomaly did it detect. The website would’ve been used by team of traffic management personnel who normally deal with abnormal traffic situations. As there were multiple potential users, we tried to make sure their work wouldn’t clash. The feedback fields could be edited by anyone currently on the website, which meant we had to find a way of handling special cases where 2 or more users go to edit the same fields and their work gets overwritten, or in some cases deleted entirely. I implemented a colour-based feedback system to let everyone on the website know immediately if something was being edited, as well as whether an entry is finalised. In doing so, I gained a lot of experience in dealing with the generic nature of web development, where the html content can be vastly different one minute to the next, and any modifications one makes to such content has to keep track of a number of different things. There was also the fact that there could be multiple clients at any one time, so the web server had to keep track of each user when ditching out personalised formatting, like ‘you’re now editing this field’ so your entry is coloured blue, for example.
In the end it turned out that no more than one person ended up using it due to the nature of the users’ schedules. It was a very interesting project regardless, and I learned a lot about working in collaboration with someone and effectively communicating my point of view or propose a solution to a problem.