Feature/nav 173 results and discussion limitations

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

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++
 

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)
-

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.