IS480 Team wiki: 2016T1 NAWTY Final
Project Progress Summary
- LOOP booth at Car Free Sunday on 30 October 2016
- GIS Day sharing and demonstration at Digital Planning Lab on 16 November 2016
- Requirement changes due to privacy issues raised
- - Removal of Social Media Module
- - Removal of Full Name
- - Replaced Email with Security Questions
- - Replaced Profile Picture with Avatar
- - Removal of Social Media Module
Project Scope and Status
Our project scope has changed since midterm to accommodate the issues raised on privacy during our Midterm Presentation, and to bring more value to end-users. The main changes include:
- - Removal of Connect and Sign Up with Facebook
- - Addition of Security Questions
- - Expansion of Admin Module
- - Addition of Select Alternative Routes Functionality
- - Removal of Connect and Sign Up with Facebook
Planned Project Scope
Actual Project Scope
Our project schedule has also changed since midterm. Issues about privacy were raised during our Midterm Presentation. We have since included PDPA Compliance (Removing Email and Full Name fields & replacing profile picture to avatar) and User Profile II (Security Questions to replace Email) into our timeline. There has not been additional delays in our schedule.
Planned Project Schedule
Actual Project Schedule
|Total Bug Score per Iteration:|
(1 x No. of Low Impact Bugs) + (5 x No. of High Impact Bugs) + (20 x No. of Critical Impact Bugs)
|Task Metric Score per Iteration:|
Number of Tasks Completed in Iteration / Number of Tasks Planned for Each Iteration
|Team Bonding Metric Score per Iteration:|
Total Number of Team Dinners During Iteration (Official & Unofficial Meetings)
We used the following extensions on the PostgreSQL database to manipulate and store geospatial data.
- 1. pgRouting: Provides geospatial routing functionality
- 2. PostGIS: Allows for manipulation of geospatial data
The data used for building the routing network stored in the database comes from OpenStreetMap.
We made use of Dijkrsta’s Algorithm for computing the shortest/safest path from 1 node to another. More information on how the Dijkrsta’s Algorithm actually works can be found here: https://www.youtube.com/watch?v=_lHSawdgXpI
By default, the routing function provided by pgRouting requires the start and end points to be nodes inside the routing network. These nodes are usually the intersections of roads. However, this is impractical as users may not be starting and ending on an intersection. Therefore we coded a custom procedural language structured query language (PL/SQL) that carries out pre-processing and post-processing to calculate the shortest/safest path from any starting and ending point.
Firstly, the closest lines from the user specified starting and ending locations are obtained.
Secondly, the point on the line with the shortest distance to the user specified starting and ending locations are obtained.
Thirdly, the start of the line, which corresponds to a node is obtained.
Depending on whether the user selects safest or shortest route, the Dijkrsta’s Algorithm provided by the PgRouting extension is invoked with the derived starting and ending nodes and the associated costs (depending on safest/shortest).
Since the routing algorithm returns multiple sets of routes, the code loops through each of the route and finds the initial line starting from the starting node.
Then, using the point on the line with the shortest distance to the user specified starting location, the segment before and after the point is obtained.
After which, the initial line is replaced by the segment that connects from the closest point on the closest line to the user’s specified location to the subsequent lines in the route.
This is repeated to find the segment on the last line in the route that connects to the point on the line closest to the user’s specified ending location.
The distance for each route is stored.
To provide a more accurate estimate of the time taken for the user to complete the route, the average speed for all the routes that the user has previously taken is determined and used in the calculation. If there is no historical average speed, a default value of 10km per hour is used instead.
Real-Time Updating of Routing Algorithm to Account for Traffic Situations
We want the routing algorithm to be updated real-time to account for any traffic situations such as road blocks, road works, traffic diversions, vehicle breakdowns. We made use of the traffic incident API provided by Datamall@MyTransport.sg to receive all the latest updates to the traffic situations.
Firstly, we set up the node-schedule package to schedule the sending of the HTTP request to the Datamall API at the 30th minute of every hour.
Secondly, we filtered out messages that are related to traffic situations on highways since highways are out of bounds to cyclists.
This is done through creating a custom function that screens through the message of each traffic report.
Thirdly, we check the database to see if the reports have already been incorporated into the routing algorithm.
We then insert the new traffic reports into the database and associate it with the nearest line in the routing network.
Following which, we find the rows where traffic situations have been resolved. We also delete rows where there is no line that is within 500m of the traffic incident coordinates. We also retrieved the records where the amendments to the routing algorithm has not been done.
Using the records retrieved that have not been incorporated into the routing algorithm, we multiply the length of the associated line by 1.1 for each record. For traffic reports that deal with road blocks, we set the cost to a negative number so that the routing algorithm will not route across that line.
For existing records in the database that are no longer relevant, we reverse the amendments made to the costs of the line.
Finally, we delete the outdated records in the database.
Quality of Product
|Project Management||Project Schedule|
We made use of Json Web Tokens (JWT) to maintain the ‘logged-in’ status of the users.
When a user logs in with the valid credentials, we return a unique JWT token that users append to their subsequent requests. In this case, every request is screened for a valid JWT token.
We also verified the type of user depending on whether the user is a cyclist or admin to make the access to the data more secure. We excluded API endpoints that do not require verification of the user’s identity such as login, signup etc.
Since the verification of the source of the request is done through JWTs, we scaled our server to have 2 instances of it so that it is better able to hand concurrency and load. We also implemented a HAProxy (TCP/HTTP Proxy) for load balancing to reduce the response time of each request because of having to queue the request.
We configured the server to have a minimum of 2 instances up and running to be able to deal with unexpected surges in requests.
Apple App Store - https://itunes.apple.com/us/app/loop-singapores-own-cycling/id1155622552?ls=1&mt=8
Google Play Store - https://play.google.com/store/apps/details?id=com.teamnawty.loop
For more information about our user testing, click below to read more:
Essential to every project - Communication. Communication between front end and back end developers, between project manager and developers, supervisor and client was extremely crucial to the success and progress of our project. Without communication, developers would not have been able to work together and the project manager would not know whether they were coping with the project requirements. During the few times when some team members were busy and didn't talk much, the project was unable to move forward. Especially in this project, we realised that communication was very important.
All in all, our team had a wonderful and enriching IS480 experience. We went through the whole product development cycle - from the research to the development of the application to the handover. It was a tiring 7 months, but we definitely learnt a lot.
Annabelle Victoria Ong
|"I think through this project I really learnt how to manage our time better and how to present myself better to various stakeholders. I would say that our biggest learning point is that the project is only as strong as the weakest link. Everyone has to work together and everyone is as important. If anyone, or anything, falls short, it would either slow the whole project down or it would take a lot for the group to cover up. |
IS480 may be a really heavy module, but I think we all managed to take away something from it."
Leong Wei Kong
|"Throughout this project, I have tried, tested and integrated various mapping framework and libraries such as Leaflet and OpenLayers as currently there are no front-end mapping frameworks that compiles all the strengths of existing frameworks.|
One of the main challenges in integrating these frameworks is the conflicting coordinate standards such as GeoJSON, SYV21 and WGS84. In order to overcome this challenge, we had to agree on a common coordinate standard and all coordinates will be parsed as that standard.
Finally, it has been a long but enriching journey and my biggest takeaway from IS480 is that in an IT development project, teamwork is extremely important."
|"I feel that IS480 is a very important module for information systems students as it allows me to work with real-life clients and experience the entire process even before embarking on my career. |
I got to go through the entire project lifecycle from gathering requirements from my clients, developing the solutions, up to the very last step which is the handover.
Through the project, I learn that whatever can go wrong, will go wrong. The only way is to plan for it and know how to mitigate it when it happens. And I think personally, this project tremendously sparked my interest in mobile application development. This end of this project marks the start of my exploration on even more mobile development technologies."
Teo Teck Jin
|"I have learnt that it is important to assess the gap between business requirements and user interest in order to build a product that truly provides value to its users. Moreover, I have become more comfortable with changes and to better manage different stakeholders and their expectations. I believe this FYP experience definitely be useful for me in the future endeavors to come."|
Yeam Wee Kian
|"As the lead backend developer for this project, I had to overcome various challenges such as the complexity of the algorithm which would have implications on the scalability and load of the server, working with the Nicholas, the frontend developer, to ensure that integration of the frontend and backend goes smoothly and server issues such as the load balancing etc. |
At the end of this project, I have learnt how to properly verbalize the logic of the algorithms to those that are not IT-savvy. At the same time, I also learnt how to evaluate, leverage and integrate 3rd party open-source packages to increase the efficiency of the code development."