diff --git a/Writerside/topics/conclusion-and-outlook.md b/Writerside/topics/conclusion-and-outlook.md index e472950..96705e3 100644 --- a/Writerside/topics/conclusion-and-outlook.md +++ b/Writerside/topics/conclusion-and-outlook.md @@ -18,10 +18,10 @@ team member also expanded their expertise in key areas such as data structures, software architecture, making this project a valuable learning experience. However, there were areas for improvement. One notable challenge was the minimal overlap between the C++ and Java -components, which led to reduced synergy during the development process. Additionally, the inconsistent implementation -of GTFS by national transit agencies posed challenges, such as invalid ID references, mostly missing accessibility -information, and incomplete transfer data between stops. The intense project schedule, with long hours spent coding -during evenings and weekends, also placed considerable strain on the personal lives of the team members, highlighting a +components, which led to reduced synergy during the development process. Additionally, the lack of optional GTFS +components provided by national transit agencies, such as accessibility or bike information, along with incomplete +transfer data between stops, posed further obstacles. The intense project schedule, with long hours spent coding during +evenings and weekends, also placed considerable strain on the personal lives of the team members, highlighting a work-life balance issue. Looking to the future, several areas of potential development could further enhance the product. Introducing fare-based diff --git a/Writerside/topics/implementation/raptor-xx.md b/Writerside/topics/implementation/raptor-xx.md index 519dc04..d23ff48 100644 --- a/Writerside/topics/implementation/raptor-xx.md +++ b/Writerside/topics/implementation/raptor-xx.md @@ -359,16 +359,16 @@ The Visual Studio Diagnostic Tools were utilized to analyze and optimize the per ## Foreign Function and Memory (FFM) API Initially, we explored the possibility of calling the C++ RAPTOR implementation from Java using the Foreign Function and -Memory (FFM) API. However, we faced significant challenges due to the complexity of mapping intricate data structures -between C++ and Java. Ultimately, we decided against this approach. - -The FFM API (Foreign Function & Memory) was not well suited for our application. To send routing requests from Java to -C++, C++ had to interact with a memory structure created in Java, which would have been very complex to implement. Since -Java was the primary application, the alternative would have been to recreate the schedule for each request from files -in C++, which would have been extremely inefficient. -A more effective approach would have been to implement a special C++ service that Java could call to forward tasks. -While the FFM API is useful for certain types of function substitutions, it was not designed to manage the larger, -integrated workflows we needed and was therefore unsuitable for our use case. +Memory (FFM) API [7]. However, we faced significant challenges due to the complexity of mapping intricate data +structures between C++ and Java. Ultimately, we decided against this approach. + +The FFM API (Foreign Function & Memory) was not well suited for our application. Sending routing requests from Java to +C++ required C++ to interact with a memory structure created in Java, which would have been highly complex to implement. +Since Java was the primary application, the alternative would have been to recreate the schedule for each request from +files in C++, which would have been extremely inefficient. A more effective approach would have been to implement a +special C++ service that Java could call to forward tasks. While the FFM API is useful for certain types of function +substitutions, it was not designed to manage the larger, integrated workflows we needed and was therefore unsuitable for +our use case. ### Example implementation for using the FFM API and C / C++ diff --git a/Writerside/topics/references.md b/Writerside/topics/references.md index 09ff6c1..391d98b 100644 --- a/Writerside/topics/references.md +++ b/Writerside/topics/references.md @@ -38,4 +38,3 @@ from [https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf](htt [12] Spring Framework. (n.d.). Spring Boot Reference Documentation. Retrieved May 31, 2024, from [https://spring.io/projects/spring-boot](https://spring.io/projects/spring-boot) - diff --git a/Writerside/topics/results-and-discussion/limitations.md b/Writerside/topics/results-and-discussion/limitations.md index b4d3b7f..f1daf4a 100644 --- a/Writerside/topics/results-and-discussion/limitations.md +++ b/Writerside/topics/results-and-discussion/limitations.md @@ -1,6 +1,33 @@ # Limitations -- GTFS specification not complete for Switzerland -- International Routing: Combining multiple GTFS -- Trade-Off: Memory vs. Performance (Caching) -- RAPTOR++: FFM API complexity, Multi-OS, logging +While this thesis demonstrates the potential and applicability of RAPTOR for public transit routing using GTFS data, +there are several limitations to the approach and implementation that need to be acknowledged. + +One significant limitation is the absence of useful optional components in the GTFS publications by various national +transit agencies. While the mandatory fields are generally present, many agencies do not provide certain optional fields +that could enhance the service's capabilities. For example, the Swiss GTFS data lacks some footpaths between stops, even +though these transfers are possible. Additionally, there is no information regarding accessibility features +or bike transportation, which limits the service's adaptability for users with specific needs. + +International routing presents another significant challenge, as it requires working with multiple GTFS feeds. Merging +datasets from regions within the same timezone is technically feasible but introduces its own complexity, such as +resolving duplicate routes and stops that may have different identifiers. When dealing with multiple timezones, +all stop times and calendar dates must be converted to UTC before merging schedules. + +The trade-off between memory usage and performance is another limitation of the system. Our RAPTOR router requires a +significant amount of memory, particularly for building and caching various stop time arrays, as a new array is +generated for each combination of service days, transport modes, accessibility options, and bike transport settings. +However, as the size of the GTFS dataset increases, so does the cache, potentially leading to memory exhaustion. In +resource-constrained environments, the cache size must be reduced, negatively impacting performance, especially when +users request a wide range of query combinations. + +Additionally, the implementation of RAPTOR++ in C++ brought several technical obstacles. The complexity of working with +the Foreign Function and Memory (FFM) API, multi-operating system builds, and dependency management through CMake and +vcpkg presented significant hurdles. Moreover, setting up a logging framework without introducing dependencies +throughout the project required extensive effort, with the bridge pattern ultimately being adopted to isolate logging +logic. + +Lastly, the initial goal of using the FFM API to pass routing requests from the benchmarking setup to the C++ RAPTOR was +abandoned. The need to reduce the complex RAPTOR data structures in Java to primitive types for the API, and then +rebuild them on the C++ side, would have significantly impacted performance. Consequently, the C++ benchmarking was +conducted independently of the Java implementation.