Risks

Problem Statement:

Organizations with large scale network operations often struggle to find a real time simulation engine that could allow them to test their system under realistic, dynamic conditions. Weather and traffic, among other factors, play vital roles in accuratly simulating the real world. Existing tools often lack the realism organizations require, and other open source projects make it extremely difficult to represent geographic data accurately. This makes it harder to test dispatching strategies and to visualize how the network is operating. VeloSim addresses these problems by providing a real time simulation engine that that leverages Open Street Map Data (OSM) to accurately represent real life. However this comes with risk and challenges!

Risks (R1):

The most significant risk the team will be facing is highly losing performance due to working with a considerable amount of data. The team will be working with large datasets to make the simulation realistic, such as a subset of BIXI's internal data and OpenStreetMap (OSM) data which includes all streets and intersections within the network of Montreal. As we will be heavily manipulating the OSM data to create graphs and routes within them, numerous analyses and iterations will need to be executed through it. This could lead to long computation times which could overload the CPU and buffer the application. In addition, since most of the data is stored in remote servers, performance will also depend on the network bandwidth. By requesting a huge load of data, the network could get congested as the data would need to be split and sent through multiple packets which could overload the buffer. This could then lead to loss of data and slow data retrieval. When performance becomes too slow, the application could seem unresponsive and could ruin the user experience. Users do not wish to use an application that continuously lags or has excessively long loading times. As a result, the loss of performance caused by the usage of a large amount of data could potentially kill our project if not mitigated.

To start attacking this risk, we decided to reduce the amount of network dependencies to manipulate the OSM data. As a result, the OSM data will be fetched once at initialization of the application and stored as a dump file to allow quick parsing of its values using the pyrosm library as discussed in issue #31. Although this improved the performance and reduced the risks of network congestion, it still took quite some time to create the graph and get a route which would be frequently requested. Hence, this was resolved by implementing a Contraction Hierarchy for quicker shortest path calculations and by introducing a KDTree algorithm for finding the nearest neighbor implemented in PR #273 within the OSMConnection.py file.

More details on how we improved and will improve in the future the performance of our application can be found in the Performance wiki page.

---

Risks (R2)

While all current risks still hold from R1, there is a new risk that has been identified:

• Due to how routing engines are built around representing a single world, there is a risk that our domain constraint of needing to run multiple worlds may not be compatible with such engines, resulting in an incomplete feature.

The mitigation was to research different solutions and approaches. The conclusion was to separate our domain constraints in our simulator, and have an adapter interface with any routing engine. More research discussed in the wiki.