Bug: GTFS stops with no departures #158
Comments
munterfi
changed the title
munterfi
changed the title
|
Implemented the third option: "Add all stops to RAPTOR, even if no departures" in #159. This PR is a suggestion. If we decide to solve the issue this way, some test cases will need to be updated. In particular, cases involving parent-child relationships between stops should be reviewed in detail. |
|
@munterfi: I don't really like adding all stops, when stops don't have transfers and no departures. To solve this issue, I've now changed some of the converter logic to include new stops if they can be reached by transfer. I also updated the tests to account for this in this branch: https://github.com/naviqore/public-transit-service/tree/158-bug-gtfs-stops-with-no-departures-1 Another change I made, which has some implications for the viewer and other dependencies, is the new introduction of ConnectionResponse and IsoLineResponse dtos. The idea here is that instead of throwing internal server errors we can provide empty responses and include error messages. Also we may extend this in the future with warnings and success messages. However, if you agree with this approach we'll also need to update the viewer/client packages. |
GTFS does not enforce that stops must have departures (=stopping trips). Therefore, handling the case when a stop is present in the GTFS but has no trips should be addressed.
There can be two types of errors:
public-transit-service-1 | Caused by: java.lang.IllegalArgumentException: Target stop MATT does not exist public-transit-service-1 | at ch.naviqore.raptor.router.RaptorRouterBuilder.addTransfer(RaptorRouterBuilder.java:95) ~[!/:1.1.0] public-transit-service-1 | at ch.naviqore.service.gtfs.raptor.convert.GtfsToRaptorConverter.addAdditionalTransfers(GtfsToRaptorConverter.java:111) ~[!/:1.1.0] public-transit-service-1 | at ch.naviqore.service.gtfs.raptor.convert.GtfsToRaptorConverter.processAllTransfers(GtfsToRaptorConverter.java:101) ~[!/:1.1.0] public-transit-service-1 | at ch.naviqore.service.gtfs.raptor.convert.GtfsToRaptorConverter.convert(GtfsToRaptorConverter.java:56) ~[!/:1.1.0] public-transit-service-1 | at ch.naviqore.service.gtfs.raptor.GtfsRaptorService.<init>(GtfsRaptorService.java:59) ~[!/:1.1.0] public-transit-service-1 | at ch.naviqore.service.gtfs.raptor.GtfsRaptorServiceInitializer.get(GtfsRaptorServiceInitializer.java:117) ~[!/:1.1.0] public-transit-service-1 | at ch.naviqore.service.PublicTransitServiceFactory.create(PublicTransitServiceFactory.java:20) ~[!/:1.1.0] public-transit-service-1 | at ch.naviqore.app.service.PublicTransitSpringService.createDelegate(PublicTransitSpringService.java:51) ~[!/:1.1.0] public-transit-service-1 | at ch.naviqore.app.service.PublicTransitSpringService.<init>(PublicTransitSpringService.java:38) ~[!/:1.1.0] public-transit-service-1 | at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:62) ~[na:na] public-transit-service-1 | at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:502) ~[na:na] public-transit-service-1 | at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:486) ~[na:na] public-transit-service-1 | at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:208) ~[spring-beans-6.1.14.jar!/:6.1.14] public-transit-service-1 | ... 26 common frames omitted public-transit-service-1 |I am unsure what the best strategy would be to deal with this. Maybe keep the stops in the schedule and filter the requests before calling Raptor, or just remove them completely from the schedule since they do not add any value to the transit schedule.
A third option could be to add them also to raptor, and maybe they have a transfer to another nearby transit stop, from where a transit connection could start. Otherwise just no connections are returned on a routing request in this case.
What do you think, @clukas1?
The text was updated successfully, but these errors were encountered: