158 bug gtfs stops with no departures 1 #160
Conversation
…n raptor converter test results.
There was a problem hiding this comment.
Upon further reflection, I think my initial approach of just adding all stops from the GTFS schedule to the RAPTOR makes more sense, as it introduces less complexity and no inconsistencies between the schedule and the router.
If a stop occurs in the GTFS schedule, it should be included in RAPTOR, even if no departures are scheduled from that stop. While adding a large number of such stops could negatively impact performance during the generation of transfers at startup, the effect on routing would be minimal since no route scanning occurs from these stops.
Since this issue originates in the GTFS input, we could issue a warning when adding stops with no departures. Ultimately, however, it is the responsibility of the GTFS producer to address this. Our public transit service should handle such cases gracefully but should not attempt to fix the underlying data issue.
What, in your opinion, speaks against this solution?
| @@ -42,9 +41,15 @@ public RoutingController(PublicTransitService service) { | |||
| this.service = service; | |||
| } | |||
|
|
|||
| private static void handleConnectionRoutingException(ConnectionRoutingException e) { | |||
| private static ConnectionResponse handleConnectionRoutingException(ConnectionRoutingException e) { | |||
There was a problem hiding this comment.
I vote against wrapping the responses in DTOs again, as it seems like reinventing the wheel.
Spring already provides built-in strategies for exception handling, and we are already using them. See: Error Handling for REST with Spring
I think the better approach is to have more speaking exceptions names and handle them in the already existing ch.naviqore.app.controllerGlobalExceptionHandler (@ControllerAdvice).
| return map(List.of(), e.getMessage(), MessageType.ERROR); | ||
| } | ||
|
|
||
| private static IsoLineResponse handleConnectionRoutingException(ConnectionRoutingException e, TimeType timeType, |
| } | ||
| } | ||
|
|
||
| private void addStop(String stopId) { |
There was a problem hiding this comment.
Do we still have the inconsistency between the GTFS schedule and the RAPTOR Router? Specifically, there could be stops in the schedule that the router doesn't recognize. I assume in that case, the router throws an exception when a route is requested from a stop with no departures in the GTFS.
There was a problem hiding this comment.
If we decide to add all stops to the router, it would simply result in no connections being returned, which accurately reflects the reality: the stop exists in the schedule, but there are no departures and, therefore, no connections.
Whether it makes semantic sense to include stops without departures in a schedule is another question entirely, but I believe that is not our responsibility to address.
thanks! |
See comment in issue