From aa4812ad9463bc1229ce39c86dc916191a3fd55f Mon Sep 17 00:00:00 2001 From: Merlin Unterfinger Date: Mon, 2 Sep 2024 08:09:58 +0200 Subject: [PATCH 1/7] DOC: NAV-167 - Move guidelines and best practices to project management - Setup new structure in implementation section. - Add results and discussion section. - Add conclusion and outlook section. --- Writerside/d.tree | 16 ++++++++++++---- Writerside/redirection-rules.xml | 8 ++++++++ Writerside/topics/benchmarking.md | 3 +++ Writerside/topics/conclusion-and-outlook.md | 3 +++ Writerside/topics/extended-raptor.md | 15 +++++++++++++++ Writerside/topics/implementation.md | 6 +++--- Writerside/topics/limitations.md | 3 +++ Writerside/topics/outline.md | 10 +++++----- Writerside/topics/project-management.md | 5 ++++- Writerside/topics/raptor-xx.md | 3 +++ Writerside/topics/results-and-discussion.md | 4 ++++ Writerside/topics/simple-raptor.md | 5 +++++ ...dology.md => software-development-process.md} | 6 ++---- 13 files changed, 70 insertions(+), 17 deletions(-) create mode 100644 Writerside/topics/benchmarking.md create mode 100644 Writerside/topics/conclusion-and-outlook.md create mode 100644 Writerside/topics/extended-raptor.md create mode 100644 Writerside/topics/limitations.md create mode 100644 Writerside/topics/raptor-xx.md create mode 100644 Writerside/topics/results-and-discussion.md create mode 100644 Writerside/topics/simple-raptor.md rename Writerside/topics/{methodology.md => software-development-process.md} (96%) diff --git a/Writerside/d.tree b/Writerside/d.tree index 7271ba8..53e2b70 100644 --- a/Writerside/d.tree +++ b/Writerside/d.tree @@ -9,8 +9,11 @@ - + + + + @@ -29,8 +32,13 @@ - - - + + + + + + + + \ No newline at end of file diff --git a/Writerside/redirection-rules.xml b/Writerside/redirection-rules.xml index b216fcf..0376037 100644 --- a/Writerside/redirection-rules.xml +++ b/Writerside/redirection-rules.xml @@ -78,4 +78,12 @@ Created after removal of "Terminology" from Naviqore terminology.html + + Created after removal of "Raptor Implementation" from Naviqore + raptor-implementation.html + + + Created after removal of "Trip Mask Provider" from Naviqore + trip-mask-provider.html + \ No newline at end of file diff --git a/Writerside/topics/benchmarking.md b/Writerside/topics/benchmarking.md new file mode 100644 index 0000000..6f4eb64 --- /dev/null +++ b/Writerside/topics/benchmarking.md @@ -0,0 +1,3 @@ +# Benchmarking + +Start typing here... \ No newline at end of file diff --git a/Writerside/topics/conclusion-and-outlook.md b/Writerside/topics/conclusion-and-outlook.md new file mode 100644 index 0000000..76f42f4 --- /dev/null +++ b/Writerside/topics/conclusion-and-outlook.md @@ -0,0 +1,3 @@ +# Conclusion and Outlook + +Start typing here... diff --git a/Writerside/topics/extended-raptor.md b/Writerside/topics/extended-raptor.md new file mode 100644 index 0000000..8612c1f --- /dev/null +++ b/Writerside/topics/extended-raptor.md @@ -0,0 +1,15 @@ +# Extended Raptor + +## Latest Departure + +Routing in negative timeline direction. + +## Multiday + +Adjustments to trip mask provider. + +## Range Raptor + +## Accessibility and Bike Information + +## Caching diff --git a/Writerside/topics/implementation.md b/Writerside/topics/implementation.md index 6087f80..5619f2d 100644 --- a/Writerside/topics/implementation.md +++ b/Writerside/topics/implementation.md @@ -1,5 +1,5 @@ # Implementation -- [Git Best Practices](git-best-practices.md) -- [Code Style Guide](code-style-guide.md) -- [Release](release.md) +- [Simple Raptor](simple-raptor.md) +- [Extended Raptor](extended-raptor.md) +- [RaptorXX](raptor-xx.md) diff --git a/Writerside/topics/limitations.md b/Writerside/topics/limitations.md new file mode 100644 index 0000000..623d0bf --- /dev/null +++ b/Writerside/topics/limitations.md @@ -0,0 +1,3 @@ +# Limitations + +Start typing here... \ No newline at end of file diff --git a/Writerside/topics/outline.md b/Writerside/topics/outline.md index 6b82064..aed5d21 100644 --- a/Writerside/topics/outline.md +++ b/Writerside/topics/outline.md @@ -1,6 +1,6 @@ # Outline -## Project milestones +## Project Milestones ```mermaid gantt @@ -35,7 +35,7 @@ gantt Design: 2024-08-15, 2024-09-01 Implementation: 2024-08-15, 2024-09-15 Testing: 2024-08-15, 2024-09-15 - Supervisor-Sync (tbd.): milestone, 2024-09-15, 0d + Supervisor-Sync (on Site): milestone, 2024-09-13, 0d section v1.0.0 Continuous Documentation: 2024-04-15, 2024-09-27 Thesis: 2024-08-15, 2024-09-27 @@ -45,7 +45,9 @@ gantt ``` -## Team resource schedule +## Team Resource Schedule + +TODO: Replace with actual logged times from JIRA. [Link to time schedule](https://docs.google.com/spreadsheets/d/1NVJV-sXO0yzrbKqA5deLzzR0VaGW3y-0jaoxKCRQ4sk/edit?usp=sharing) @@ -64,5 +66,3 @@ gantt | KW | Calendar Week | | VšŸŒ“ | Vacation | | Total | Sum of time estimates for all weeks | - -Start typing here... \ No newline at end of file diff --git a/Writerside/topics/project-management.md b/Writerside/topics/project-management.md index c1b9cda..771d663 100644 --- a/Writerside/topics/project-management.md +++ b/Writerside/topics/project-management.md @@ -1,4 +1,7 @@ # Project Management -- [Methodology](methodology.md) +- [Software Development Process](software-development-process.md) - [Outline](outline.md) +- [Git Best Practices](git-best-practices.md) +- [Code Style Guide](code-style-guide.md) +- [Release](release.md) diff --git a/Writerside/topics/raptor-xx.md b/Writerside/topics/raptor-xx.md new file mode 100644 index 0000000..d6c0660 --- /dev/null +++ b/Writerside/topics/raptor-xx.md @@ -0,0 +1,3 @@ +# RaptorXX + +Implementation of the simple Raptor in C++ for performance comparison in benchmarking. diff --git a/Writerside/topics/results-and-discussion.md b/Writerside/topics/results-and-discussion.md new file mode 100644 index 0000000..1ec92b5 --- /dev/null +++ b/Writerside/topics/results-and-discussion.md @@ -0,0 +1,4 @@ +# Results and Discussion + +- [Benchmarking](benchmarking.md) +- [Limitations](limitations.md) diff --git a/Writerside/topics/simple-raptor.md b/Writerside/topics/simple-raptor.md new file mode 100644 index 0000000..0e62457 --- /dev/null +++ b/Writerside/topics/simple-raptor.md @@ -0,0 +1,5 @@ +# Simple Raptor + +## Stop Times Array + +## Trip Mask Provider diff --git a/Writerside/topics/methodology.md b/Writerside/topics/software-development-process.md similarity index 96% rename from Writerside/topics/methodology.md rename to Writerside/topics/software-development-process.md index 13af7fa..6cc0028 100644 --- a/Writerside/topics/methodology.md +++ b/Writerside/topics/software-development-process.md @@ -1,6 +1,4 @@ -# Methodology - -## Software Development Process +# Software Development Process The development process follows an iterative Scrum-like setup with 4-week sprints between supervisor meetings. Task management and monitoring are facilitated using the agile project tracking software, Jira. This structured way of @@ -48,7 +46,7 @@ The fail-fast concept is preferred in development. Given the complexity of the p identification and resolution of issues, ensuring a more efficient development process. Clean code principles are followed, and all code is reviewed by team members. For more details, refer to -the [Code Style Section](requirements.md). +the [Code Style Section](code-style-guide.md). ## Documentation From 280567ad783dcc52eb36888ed79b733c9a15c5fa Mon Sep 17 00:00:00 2001 From: Merlin Unterfinger Date: Mon, 2 Sep 2024 08:15:20 +0200 Subject: [PATCH 2/7] DOC: NAV-167 - Add deployment sub-section --- Writerside/d.tree | 1 + Writerside/topics/deployment.md | 19 +++++++++++++++++++ Writerside/topics/results-and-discussion.md | 1 + 3 files changed, 21 insertions(+) create mode 100644 Writerside/topics/deployment.md diff --git a/Writerside/d.tree b/Writerside/d.tree index 53e2b70..e0d8458 100644 --- a/Writerside/d.tree +++ b/Writerside/d.tree @@ -37,6 +37,7 @@ + diff --git a/Writerside/topics/deployment.md b/Writerside/topics/deployment.md new file mode 100644 index 0000000..912309f --- /dev/null +++ b/Writerside/topics/deployment.md @@ -0,0 +1,19 @@ +# Deployment + +Deployment of the public transit service, based on GTFS and the extended raptor, and viewer. + +## Configuration + +TODO: Describe application.properties + +## Helm Chart + +TODO: Describe helm chart + +## Docker compose + +TODO: Describe docker compose setup + +## References + +TODO: Add link to Github repository. diff --git a/Writerside/topics/results-and-discussion.md b/Writerside/topics/results-and-discussion.md index 1ec92b5..3e5a782 100644 --- a/Writerside/topics/results-and-discussion.md +++ b/Writerside/topics/results-and-discussion.md @@ -1,4 +1,5 @@ # Results and Discussion +- [Deployment](deployment.md) - [Benchmarking](benchmarking.md) - [Limitations](limitations.md) From 6e279497b9af4bc56f751339f84bb3b434296d5b Mon Sep 17 00:00:00 2001 From: Merlin Unterfinger Date: Mon, 2 Sep 2024 13:24:53 +0200 Subject: [PATCH 3/7] DOC: NAV-166 - Review interim review action items --- Writerside/topics/interim-review.md | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/Writerside/topics/interim-review.md b/Writerside/topics/interim-review.md index f38cb54..541f09a 100644 --- a/Writerside/topics/interim-review.md +++ b/Writerside/topics/interim-review.md @@ -105,16 +105,15 @@ The interim review checks whether each team is on track with their software proj ## Consolidated Action Items -- Clarify the purpose of the project and add a context diagram. -- Improve the numbering and sequence of the documentation. -- Apply the C4 model to the architecture section. -- Ensure OpenAPI compliance and review paths for domain model accuracy. -- Consider separating the C++ part into a microservice and look into Neo4J for graph database needs. -- Optimize data structures and use existing cache solutions with proper synchronization mechanisms. -- Invest in comprehensive testing, including integration tests, and provide a detailed comparison of Java and C++. -- Clearly prioritize requirements and adopt a risk-based approach if not using Scrum. Ensure all sprints and goals are - documented in Jira. -- Review and refine the video presentation, focusing on length and clarity. -- Export documentation as a cohesive document and improve terminology clarity. -- Refactor long methods in the code and define risk mitigation measures. - +- āœ”ļø Clarify the purpose of the project and add a context diagram. +- āœ”ļø Improve the numbering and sequence of the documentation. +- āœ”ļø Apply the C4 model to the architecture section. +- āœ”ļø Ensure OpenAPI compliance and review paths for domain model accuracy. +- āŒ Consider separating the C++ part into a microservice and look into Neo4J for graph database needs. +- āœ”ļø Optimize data structures and use cache solutions with proper synchronization mechanisms. +- āœ”ļø Invest in comprehensive testing, including integration tests, and provide a detailed comparison of Java and C++. +- āœ”ļø Clearly prioritize requirements and adopt a risk-based approach if not using Scrum. Ensure all sprints and goals + are documented in Jira. +- āœ”ļø Review the video presentation regarding length and clarity. Adapt for final presentation. +- āœ”ļø Export documentation as a cohesive document and improve terminology clarity. +- āœ”ļø Refactor long methods in the code and define risk mitigation measures. From 57627cf4f784b29bd87d1fa457762a8d51f9c826 Mon Sep 17 00:00:00 2001 From: Merlin Unterfinger Date: Mon, 2 Sep 2024 14:07:26 +0200 Subject: [PATCH 4/7] DOC: NAV-166 - Review requirements - Assign status column "Done". - Add further requirements, which we have done, but didn't know in the beginning. --- Writerside/topics/requirements.md | 101 +++++++++++++++--------------- 1 file changed, 52 insertions(+), 49 deletions(-) diff --git a/Writerside/topics/requirements.md b/Writerside/topics/requirements.md index af03b9b..94206c5 100644 --- a/Writerside/topics/requirements.md +++ b/Writerside/topics/requirements.md @@ -27,58 +27,61 @@ Requirement ID = `{TYPE}-{COMPONENT}-{PRIORITY}{NUMBER}` ## Must-have -| ID | Description | -|--------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| **UC-SE-M1** | Efficiently (<250ms) find the nearest stops (beeline distance) with a limit (max 5km) with stop information (coordinates, name, routes). | -| **UC-SE-M2** | Find the next departures from a given stop with information (name, direction, if available head-sign). | -| **UC-SE-M3** | Efficiently request (in mean <250ms) connections between two stops. | -| **UC-SE-M4** | The minimum transfer time can be set by the user in the connection routing request. Already provided transfer times from the public transit schedule should be preferred, but can optionally be overridden by the minimum transfer time set by the user. | -| **NF-SE-M1** | The complete service must be able to run on a normal machine (8 cores, 16GB). | -| **NF-SE-M2** | The prototype implementation of the service, router, and GTFS reader is completely in Java. | -| **NF-SE-M3** | The communication with the service must be stateless (caching of results is still allowed). | -| **UC-SC-M1** | Use the GTFS (General Transit Feed Specification) as input for the transit schedule. | -| **UC-SC-M2** | Read all required components from GTFS static schedule. | -| **UC-SC-M3** | Read optional transfers from GTFS and make them available to the router. | -| **NF-SC-M1** | The schedule is read into a memory-efficient structure, which takes less than 1.5GB (the size of the schedule file on disk) for all required fields of the GTFS Switzerland. | -| **UC-RO-M1** | The routing algorithm RAPTOR (Round-Based Public Transit Routing) is used to find connections with the earliest arrival in the schedule, as its data structures are optimized for cache locality. | -| **UC-RO-M2** | The returned connection solutions have to be pareto-optimal (duration and number of transfers). | -| **UC-RO-M3** | The integration in the performant programming language C++ with JNI is evaluated. | -| **NF-RO-M1** | At least 5 manually chosen connections from the SBB app are used to validate the solutions from the algorithm. | -| **NF-RO-M2** | Efficiency of random route requests is measured in relation to the complete transit schedule of Switzerland of 2024 in a benchmark test. The results are written to a file. The file must have a date-time stamp to be able to track the progress of the development. | -| **UC-VW-M1** | Simple frontend to display connections from origin to a destination stop for demo purposes. | +| ID | Done | Description | +|--------------|------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **UC-SE-M1** | āœ”ļø | Efficiently (<250ms) find the nearest stops (beeline distance) with a limit (max 5km) with stop information (coordinates, name, routes). | +| **UC-SE-M2** | āœ”ļø | Find the next departures from a given stop with information (name, direction, if available head-sign). | +| **UC-SE-M3** | āœ”ļø | Efficiently request (in mean <250ms) connections between two stops. | +| **UC-SE-M4** | āœ”ļø | The minimum transfer time can be set by the user in the connection routing request. Already provided transfer times from the public transit schedule should be preferred, but can optionally be overridden by the minimum transfer time set by the user. | +| **NF-SE-M1** | āœ”ļø | The complete service for Switzerland must be able to run on a normal machine (8 cores, 16GB). | +| **NF-SE-M2** | āœ”ļø | The prototype implementation of the service, router, and GTFS reader is completely in Java. | +| **NF-SE-M3** | āœ”ļø | The communication with the service must be stateless (caching of results is still allowed). | +| **UC-SC-M1** | āœ”ļø | Use the GTFS (General Transit Feed Specification) as input for the transit schedule. | +| **UC-SC-M2** | āœ”ļø | Read all required components from GTFS static schedule. | +| **UC-SC-M3** | āœ”ļø | Read optional transfers from GTFS and make them available to the router. | +| **NF-SC-M1** | āœ”ļø | The schedule is read into a memory-efficient structure, which takes less than 1.5GB (the size of the schedule file on disk) for all required fields of the GTFS Switzerland. | +| **UC-RO-M1** | āœ”ļø | The routing algorithm RAPTOR (Round-Based Public Transit Routing) is used to find connections with the earliest arrival in the schedule, as its data structures are optimized for cache locality. | +| **UC-RO-M2** | āœ”ļø | The returned connection solutions have to be pareto-optimal (duration and number of transfers). | +| **UC-RO-M3** | āœ”ļø | The integration in the performant programming language C++ with JNI is evaluated. | +| **NF-RO-M1** | āœ”ļø | At least 5 manually chosen connections from the SBB app are used to validate the solutions from the algorithm. | +| **NF-RO-M2** | āœ”ļø | Efficiency of random route requests is measured in relation to the complete transit schedule of Switzerland of 2024 in a benchmark test. The results are written to a file. The file must have a date-time stamp to be able to track the progress of the development. | +| **UC-VW-M1** | āœ”ļø | Simple frontend to display connections from origin to a destination stop for demo purposes. | ## Should-have -| ID | Description | -|--------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| **UC-SE-S1** | Update the static transit schedule at the defined interval (most often weekly) by the publisher (pull new GTFS static from URL and replace the current schedule in the service). | -| **NF-SE-S1** | The public transit service should be able to process concurrent requests in parallel. | -| **NF-SE-S2** | Containerized deployment ensures portability. | -| **NF-SE-S3** | Open-Source release under a permissive or copy-left license. | -| **UC-SC-S1** | Apply the realtime GTFS updates on the static GTFS schedule at the defined interval (most often 2 minutes) by the publisher. Since the login procedure is different for every publisher, the focus is set on Switzerland. | -| **UC-RO-S1** | Implement range queries (rRAPTOR) to find the connections with the earliest arrivals in a departure time window. | -| **UC-RO-S2** | If the effort of the C++ implementation does not justify the performance gain, the JNI integration should be terminated based on this reasoning. | -| **UC-RO-S3** | The routing should support isoline requests: How far can someone travel from an origin stop given a time budget. | -| **UC-RO-S4** | A generic footpath routing interface is provided, which allows for extension of the router in the future. | -| **UC-RO-S5** | Default implementation of footpath routing, which approximates the footpaths between stations with a sensible factor times the beeline distance. | -| **UC-VW-S1** | The connection routing results should be displayed on a map or line network graph. | +| ID | Done | Description | +|--------------|------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **UC-SE-S1** | āœ”ļø | Update the static transit schedule at the defined interval (most often weekly) by the publisher (pull new GTFS static from URL and replace the current schedule in the service). | +| **NF-SE-S1** | āœ”ļø | The public transit service should be able to process concurrent requests in parallel. | +| **NF-SE-S2** | āœ”ļø | Containerized deployment ensures portability. | +| **NF-SE-S3** | āœ”ļø | Open-Source release under a permissive or copy-left license. | +| **UC-SC-S1** | āŒ | Apply the realtime GTFS updates on the static GTFS schedule at the defined interval (most often 2 minutes) by the publisher. Since the login procedure is different for every publisher, the focus is set on Switzerland. | +| **UC-RO-S1** | āœ”ļø | Implement range queries (rRAPTOR) to find the connections with the earliest arrivals in a departure time window. | +| **UC-RO-S2** | (āœ”) | If the effort of the C++ implementation does not justify the performance gain, the JNI integration should be terminated based on this reasoning. | +| **UC-RO-S3** | āœ”ļø | The routing should support isoline requests: How far can someone travel from an origin stop given a time budget. | +| **UC-RO-S4** | āœ”ļø | A generic footpath routing interface is provided, which allows for extension of the router in the future. | +| **UC-RO-S5** | āœ”ļø | Default implementation of footpath routing, which approximates the footpaths between stations with a sensible factor times the beeline distance. | +| **UC-RO-S6** | āœ”ļø | Connection requests should support setting the latest departure time in addition to the default case, which is the earliest arrival time. | +| **UC-RO-S7** | āœ”ļø | The router should support connection requests that span multiple days (e.g., a connection combining a night bus with the first regular service of the following day). | +| **UC-VW-S1** | āœ”ļø | The connection routing results should be displayed on a map or line network graph. | ## Nice-to-have -| ID | Description | -|----------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| **UC-SE-N1** | Implement user accounts with login, which allows saving favorite connections in a database. | -| **NF-SE-N1** | Horizontal scaling: Store the parsed static GTFS schedule and built Raptor data structures with a validity timestamp to a common storage (mounted volume or database), which is used by new instances of the service when started, instead of parsing the GTFS again. | -| **NF-SE-N2** | The service should be horizontally scalable. | -| **NF-SE-N3** | Deployment of public transit service in a cloud environment. | -| **UC-SC-N1** | Read the optional fares from the GTFS static schedule and make them available to Raptor. | -| **UC-RO-N1** | Implementation of the footpath routing interface with a graph-based routing algorithm (e.g. A*Star or A* Landmark), that uses a network read from OpenStreetMap data (e.g. from Geofabrik). | -| **UC-RO-N2** | Supports efficient matrix route queries, and Raptor can potentially be optimized for this. | -| **UC-RO-N3** | Implement multi-criteria queries (mcRAPTOR) to find the cheapest connections based on fares. | -| **UC-VW-N1** | A more sophisticated user interface. | -| **UC-VW-N1.1** | Explore and visualize the GTFS schedule. | -| **UC-VW-N1.2** | Visualize the estimated vehicle positions from the GTFS realtime feed. | -| **UC-VW-N1.3** | Display lines with departure times at selected stations. | -| **UC-VW-N1.4** | Query connections using the Raptor-Router and display the results on a map. | -| **UC-VW-N1.5** | Query reachability from a station within a given time budget. | -| **UC-VW-N1.6** | Provide an option to visualize the functioning of the Raptor algorithm by visualizing the Raptor rounds until the target stop is reached. | +| ID | Done | Description | +|----------------|------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **UC-SE-N1** | āŒ | Implement user accounts with login, which allows saving favorite connections in a database. | +| **NF-SE-N1** | āŒ | Horizontal scaling: Store the parsed static GTFS schedule and built Raptor data structures with a validity timestamp to a common storage (mounted volume or database), which is used by new instances of the service when started, instead of parsing the GTFS again. | +| **NF-SE-N2** | āœ”ļø | The service should be horizontally scalable. | +| **NF-SE-N3** | (āœ”) | Deployment of public transit service in a cloud environment. | +| **UC-SC-N1** | āŒ | Read the optional fares from the GTFS static schedule and make them available to Raptor. | +| **UC-RO-N1** | āŒ | Implementation of the footpath routing interface with a graph-based routing algorithm (e.g. A*Star or A* Landmark), that uses a network read from OpenStreetMap data (e.g. from Geofabrik). | +| **UC-RO-N2** | āŒ | Supports efficient matrix route queries, and Raptor can potentially be optimized for this. | +| **UC-RO-N3** | āŒ | Implement multi-criteria queries (mcRAPTOR) to find the cheapest connections based on fares. | +| **UC-RO-N4** | āœ”ļø | Supports availability and bike information in connection queries. | +| **UC-VW-N1** | (āœ”) | A more sophisticated user interface. | +| **UC-VW-N1.1** | āŒ | Explore and visualize the GTFS schedule. | +| **UC-VW-N1.2** | āŒ | Visualize the estimated vehicle positions from the GTFS realtime feed. | +| **UC-VW-N1.3** | āŒ | Display lines with departure times at selected stations. | +| **UC-VW-N1.4** | āœ”ļø | Query connections using the Raptor-Router and display the results on a map. | +| **UC-VW-N1.5** | āœ”ļø | Query reachability from a station within a given time budget. | +| **UC-VW-N1.6** | āŒ | Provide an option to visualize the functioning of the Raptor algorithm by visualizing the Raptor rounds until the target stop is reached. | From 2a9f865807a3c4aad2f57301816fd4ad4e600c3c Mon Sep 17 00:00:00 2001 From: Merlin Unterfinger Date: Mon, 2 Sep 2024 14:27:16 +0200 Subject: [PATCH 5/7] FIX: NAV-166 - Remove duplicate title --- Writerside/topics/requirements.md | 36 +++++++++++++++---------------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/Writerside/topics/requirements.md b/Writerside/topics/requirements.md index 94206c5..0ad13e0 100644 --- a/Writerside/topics/requirements.md +++ b/Writerside/topics/requirements.md @@ -67,21 +67,21 @@ Requirement ID = `{TYPE}-{COMPONENT}-{PRIORITY}{NUMBER}` ## Nice-to-have -| ID | Done | Description | -|----------------|------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| **UC-SE-N1** | āŒ | Implement user accounts with login, which allows saving favorite connections in a database. | -| **NF-SE-N1** | āŒ | Horizontal scaling: Store the parsed static GTFS schedule and built Raptor data structures with a validity timestamp to a common storage (mounted volume or database), which is used by new instances of the service when started, instead of parsing the GTFS again. | -| **NF-SE-N2** | āœ”ļø | The service should be horizontally scalable. | -| **NF-SE-N3** | (āœ”) | Deployment of public transit service in a cloud environment. | -| **UC-SC-N1** | āŒ | Read the optional fares from the GTFS static schedule and make them available to Raptor. | -| **UC-RO-N1** | āŒ | Implementation of the footpath routing interface with a graph-based routing algorithm (e.g. A*Star or A* Landmark), that uses a network read from OpenStreetMap data (e.g. from Geofabrik). | -| **UC-RO-N2** | āŒ | Supports efficient matrix route queries, and Raptor can potentially be optimized for this. | -| **UC-RO-N3** | āŒ | Implement multi-criteria queries (mcRAPTOR) to find the cheapest connections based on fares. | -| **UC-RO-N4** | āœ”ļø | Supports availability and bike information in connection queries. | -| **UC-VW-N1** | (āœ”) | A more sophisticated user interface. | -| **UC-VW-N1.1** | āŒ | Explore and visualize the GTFS schedule. | -| **UC-VW-N1.2** | āŒ | Visualize the estimated vehicle positions from the GTFS realtime feed. | -| **UC-VW-N1.3** | āŒ | Display lines with departure times at selected stations. | -| **UC-VW-N1.4** | āœ”ļø | Query connections using the Raptor-Router and display the results on a map. | -| **UC-VW-N1.5** | āœ”ļø | Query reachability from a station within a given time budget. | -| **UC-VW-N1.6** | āŒ | Provide an option to visualize the functioning of the Raptor algorithm by visualizing the Raptor rounds until the target stop is reached. | +| ID | Done | Description | +|----------------|------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **UC-SE-N1** | āŒ | Implement user accounts with login, which allows saving favorite connections in a database. | +| **NF-SE-N1** | āŒ | Store the parsed static GTFS schedule and built Raptor data structures with a validity timestamp to a common storage (mounted volume or database), which is used by new instances of the service when started, instead of parsing the GTFS again. | +| **NF-SE-N2** | āœ”ļø | The service should be horizontally scalable. | +| **NF-SE-N3** | (āœ”) | Deployment of public transit service in a cloud environment. | +| **UC-SC-N1** | āŒ | Read the optional fares from the GTFS static schedule and make them available to Raptor. | +| **UC-RO-N1** | āŒ | Implementation of the footpath routing interface with a graph-based routing algorithm (e.g. A*Star or A* Landmark), that uses a network read from OpenStreetMap data (e.g. from Geofabrik). | +| **UC-RO-N2** | āŒ | Supports efficient matrix route queries, and Raptor can potentially be optimized for this. | +| **UC-RO-N3** | āŒ | Implement multi-criteria queries (mcRAPTOR) to find the cheapest connections based on fares. | +| **UC-RO-N4** | āœ”ļø | Supports availability and bike information in connection queries. | +| **UC-VW-N1** | (āœ”) | A more sophisticated user interface. | +| **UC-VW-N1.1** | āŒ | Explore and visualize the GTFS schedule. | +| **UC-VW-N1.2** | āŒ | Visualize the estimated vehicle positions from the GTFS realtime feed. | +| **UC-VW-N1.3** | āŒ | Display lines with departure times at selected stations. | +| **UC-VW-N1.4** | āœ”ļø | Query connections using the Raptor-Router and display the results on a map. | +| **UC-VW-N1.5** | āœ”ļø | Query reachability from a station within a given time budget. | +| **UC-VW-N1.6** | āŒ | Provide an option to visualize the functioning of the Raptor algorithm by visualizing the Raptor rounds until the target stop is reached. | From 4f56fe5ba3447f0d22b657702cc0189888eb142a Mon Sep 17 00:00:00 2001 From: Merlin Unterfinger Date: Mon, 2 Sep 2024 15:01:47 +0200 Subject: [PATCH 6/7] DOC: NAV-167 - Section about the deployment of the naviqore system --- Writerside/topics/deployment.md | 63 ++++++++++++++++++++++++++++----- 1 file changed, 55 insertions(+), 8 deletions(-) diff --git a/Writerside/topics/deployment.md b/Writerside/topics/deployment.md index 912309f..84bfc4b 100644 --- a/Writerside/topics/deployment.md +++ b/Writerside/topics/deployment.md @@ -1,19 +1,66 @@ # Deployment -Deployment of the public transit service, based on GTFS and the extended raptor, and viewer. +Deployment of the complete Naviqore system, which consists of a public transit service based on GTFS and the extended +Raptor algorithm, along with a simple viewer. ## Configuration -TODO: Describe application.properties +The configuration of the public transit service is best handled through environment variables. This approach +provides flexibility and allows for easier management across different environments, such as development, and +production. Below are some of the key environment variables that are essential for configuring the router: -## Helm Chart +- **GTFS_STATIC_URI**: URL or file path to a static GTFS feed. The service will initially fetch the GTFS from this URL. + If the provided value is a file path, the GTFS is loaded from the file and the update interval is ignored. + Example for Switzerland: `https://opentransportdata.swiss/en/dataset/timetable-2024-gtfs2020/permalink` + +- **GTFS_STATIC_UPDATE_CRON**: Cron expression for updating the static GTFS feed from the provided URL. Public transit + agencies update their static GTFS data regularly. Set this interval to match the agency's publish schedule. Default is + to update the schedule daily at 4 AM. + +- **TRANSFER_TIME_SAME_STOP_DEFAULT**: Default transfer time between same stop transfers in seconds. If GTFS already + provides same stop transfer times, those have precedence over this default. If the value is set to 0, no additional + same stop transfer times are set. + +- **TRANSFER_TIME_BETWEEN_STOPS_MINIMUM**: Minimum transfer time between the different stops in seconds. If stops are + closer than this, this time has precedence over the actual walking time, which accounts for leaving the station + building, stairways, etc. If GTFS already provides a transfer time between two stops, the GTFS time has precedence + over this minimum. If the value is set to -1, no additional transfers will be created. + +- **TRANSFER_TIME_ACCESS_EGRESS**: Time in seconds required to access or egress from a public transit trip. This time is + added twice to the walking duration of transfers between two stops and once to first and last mile walking legs. + +- **WALKING_SEARCH_RADIUS**: Search radius in meters. No walks with a longer beeline distance between origin and + destination will appear in connections (first/last mile and between stop transfers). The actual distance of the walk + might be longer. Note: This radius is also used to generate same stop transfers. -TODO: Describe helm chart +- **WALKING_SPEED**: Walking speed in meters per second. The default value is based on the average preferred walking + speed. -## Docker compose +- **WALKING_DURATION_MINIMUM**: Minimum walking duration in seconds. If the walking duration, without access or egress + time (see 'TRANSFER_TIME_ACCESS_EGRESS'), is shorter, no first or last mile walk is needed to reach the location. This + avoids very short walks inside stations that give a false sense of accuracy. + +- **RAPTOR_DAYS_TO_SCAN**: Number of dates surrounding the queried date should be included in the scan. This is useful + if the previous GTFS service day includes trips on the queried date. Or the connection is so long that it continues + into the next service day. The default value is 3, which includes the previous, current, and next service day. + +- **RAPTOR_RANGE**: Maximum range in seconds to identify departures or arrivals for scanning in order to reduce the + travel time (a.k.a. range Raptor). Values smaller than 1 are allowed and imply using the standard Raptor algorithm. + The default value is -1, which means no range. + +For further configuration settings, such as those related to caching, logging, and application management, please refer +directly to +the [application.properties](https://github.com/naviqore/public-transit-service/blob/main/src/main/resources/application.properties) +file. + +## Helm Chart -TODO: Describe docker compose setup +This [Helm chart](https://github.com/naviqore/deployment) defines the Kubernetes resources required to deploy the +service and viewer in the cloud. The public transit service can be configured by overriding the default environment +variables via Helm's values mechanism. -## References +## Docker Compose -TODO: Add link to Github repository. +This [Docker Compose](https://github.com/naviqore/deployment/blob/main/docker-compose.yml) setup provides an alternative +method to deploy the service and viewer, particularly suited for local development. To configure the routing service, +the environment variables should be adjusted within the Docker Compose file. From 561d03bb297a5d2c5c42c7f66de9eea28b6c3e8f Mon Sep 17 00:00:00 2001 From: Merlin Unterfinger Date: Mon, 2 Sep 2024 15:03:49 +0200 Subject: [PATCH 7/7] DOC: NAV-167 - Typo --- Writerside/topics/deployment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Writerside/topics/deployment.md b/Writerside/topics/deployment.md index 84bfc4b..f74a121 100644 --- a/Writerside/topics/deployment.md +++ b/Writerside/topics/deployment.md @@ -6,7 +6,7 @@ Raptor algorithm, along with a simple viewer. ## Configuration The configuration of the public transit service is best handled through environment variables. This approach -provides flexibility and allows for easier management across different environments, such as development, and +provides flexibility and allows for easier management across different environments, such as development and production. Below are some of the key environment variables that are essential for configuring the router: - **GTFS_STATIC_URI**: URL or file path to a static GTFS feed. The service will initially fetch the GTFS from this URL.