Feature/nav 48 reverse arrival time direction implementation

naviqore / public-transit-service

Public transit schedule information and connection routing service based on GTFS data and the RAPTOR algorithm.

MIT License

4 stars 1 forks source link

Feature/nav 48 reverse arrival time direction implementation #64

Closed clukas1 closed 3 months ago

clukas1 commented 4 months ago

More tests are potentially possible, but I'm pretty sure everything works as it should. And closing this issue is probably good sooner than later,

clukas1 commented 4 months ago

Thanks @clukas1, nice work!

I have some discussion points concerning the interface of Raptor and duplicated code in the scan methods.

Do you want to integrate this with the service in a separate branch?

https://github.com/naviqore/public-transit-service/blob/f6cfb360562da8c3a1d920adaec80425a995de4b/src/main/java/ch/naviqore/service/impl/PublicTransitServiceImpl.java#L62

But looks good in general.

Implementation in service coming tonight.

clukas1 commented 4 months ago

@munterfi All comments (and more have been addressed), including the Service Implementation (also on Viewer side, but haven't created pull request yet on viewer repo)

All unit tests etc. pass, but I get some weird behavior, which I still want to debug.

And sometimes (maybe already resolved) the legs not connected error. So more debugging. Feel free to dive into it, but will have some more time on Tuesday or Wednesday to follow up.

munterfi commented 3 months ago

Ok, the isoline error is due to a change of the name from departureDateTime to dateTime:

This works:

### Connection between two stops
GET http://localhost:8080/routing/connections?sourceStopId=STAGECOACH&targetStopId=NANAA&
    departureDateTime=2010-01-01T01:10:01
Accept: application/json

Nevertheless, we should set the default time to now if no time is specified.

munterfi commented 3 months ago

I fixed the errors in https://github.com/naviqore/public-transit-service/pull/64/commits/b8b801d3ec8075bf37d5385acdff304f93cee302.

The error in connection is due to the limited validity of the example feed. If we don't provide a dateTime, the current time is used. The example schedule is only valid until 2010, which results in no departing trips. However, the error message is a bit misleading: "No valid stops provided."

The stop is valid, but there are no departures. We should introduce better error messages and also pass them to the user via the REST Controller instead of a generic 500 - Internal Server Error.

I created a new issue, NAV-107, for this.