lmeulen / pyraptor Goto Github PK

Describe the bug
When the algorithm cannot provide a solution, this is not shown (traveltime is shown as 1440 minutes) and the application crashes during the journey printing.

To Reproduce
Steps to reproduce the behavior:

1. GTFS of NL, operator NS
2. From: Arnhem Zuid, To: Assen, Rounds: 2

Expected result
A message that no route could be found.

Logfile
python lRaptor.py --i gtfs --s "Arnhem Zuid" --e "Assen" --d "08:30:00" --r 2 --c True
2021-02-22 22:45:32,127 - DEBUG - Parameters : ['--i', 'gtfs', '--s', 'Arnhem Zuid', '--e', 'Assen', '--d', '08:30:00', '--r', '2', '--c', 'True']
2021-02-22 22:45:32,127 - DEBUG - Input directoy : gtfs
2021-02-22 22:45:32,127 - DEBUG - Start point : Arnhem Zuid
2021-02-22 22:45:32,127 - DEBUG - End point : Assen
2021-02-22 22:45:32,127 - DEBUG - Departure time : 08:30:00
2021-02-22 22:45:32,127 - DEBUG - Rounds : 2
2021-02-22 22:45:32,127 - DEBUG - Cached GTFS : True
2021-02-22 22:45:32,252 - INFO - Reading GTFS took 0.1248 seconds
2021-02-22 22:45:32,252 - DEBUG - Agencies : 1
2021-02-22 22:45:32,252 - DEBUG - Routes : 140
2021-02-22 22:45:32,260 - DEBUG - Stops : 866
2021-02-22 22:45:32,260 - DEBUG - Trips : 31996
2021-02-22 22:45:32,260 - DEBUG - Stoptimes : 305913
2021-02-22 22:45:32,723 - DEBUG - Departure ID : [28, 27]
2021-02-22 22:45:32,723 - DEBUG - Arrival ID : [10, 149, 150, 151]
2021-02-22 22:45:32,723 - DEBUG - Time : 30600
2021-02-22 22:45:32,736 - DEBUG - Starting from IDS :
2021-02-22 22:45:32,736 - INFO - Analyzing possibilities round 1
2021-02-22 22:45:32,736 - INFO - Stops to evaluate count: 2
2021-02-22 22:45:32,852 - DEBUG - Evaluations : 316
2021-02-22 22:45:32,852 - INFO - Travel stops calculated in 0.1126 seconds
2021-02-22 22:45:32,852 - DEBUG - 57 stops added
2021-02-22 22:45:32,927 - INFO - Transfers calculated in 0.0760 seconds
2021-02-22 22:45:32,927 - INFO - 66 stops added
2021-02-22 22:45:32,927 - INFO - 90 stops to evaluate in next round
2021-02-22 22:45:32,936 - INFO - Analyzing possibilities round 2
2021-02-22 22:45:32,936 - INFO - Stops to evaluate count: 90
2021-02-22 22:45:34,919 - DEBUG - Evaluations : 4279
2021-02-22 22:45:34,919 - INFO - Travel stops calculated in 1.9837 seconds
2021-02-22 22:45:34,919 - DEBUG - 293 stops added
2021-02-22 22:45:35,289 - INFO - Transfers calculated in 0.3672 seconds
2021-02-22 22:45:35,289 - INFO - 338 stops added
2021-02-22 22:45:35,289 - INFO - 422 stops to evaluate in next round
2021-02-22 22:45:35,302 - INFO - Destination code : 10
2021-02-22 22:45:35,302 - INFO - Time to destination: 1440.0 minutes
2021-02-22 22:45:35,302 - DEBUG - lRaptor Algorithm executed in 2.5795912999999997 seconds
2021-02-22 22:45:35,302 - INFO - Journey:
Traceback (most recent call last):
File "C:\Users\XXXXXXXX.conda\envs\gtfs\lib\runpy.py", line 194, in _run_module_as_main
return _run_code(code, main_globals, None,
File "C:\Users\XXXXXXXX.conda\envs\gtfs\lib\runpy.py", line 87, in _run_code
exec(code, run_globals)
File "C:\Users\XXXXXXXX.conda\envs\gtfs\lib\cProfile.py", line 196, in
main()
File "C:\Users\XXXXXXXX.conda\envs\gtfs\lib\cProfile.py", line 189, in main
runctx(code, globs, None, options.outfile, options.sort)
File "C:\Users\XXXXXXXX.conda\envs\gtfs\lib\cProfile.py", line 19, in runctx
return _pyprofile._Utils(Profile).runctx(statement, globals, locals,
File "C:\Users\XXXXXXXX.conda\envs\gtfs\lib\profile.py", line 62, in runctx
prof.runctx(statement, globals, locals)
File "C:\Users\XXXXXXXX.conda\envs\gtfs\lib\cProfile.py", line 100, in runctx
exec(cmd, globals, locals)
File "lRaptor.py", line 546, in
print_journey(journey, args.departure)
File "lRaptor.py", line 421, in print_journey
frm = a.stop_name.values[0]
IndexError: index 0 is out of bounds for axis 0 with size 0

Desktop (please complete the following information):

• Python 3.7
• Application Version: 22 februari 2021 (96ef67b)

Additional context
Apparently the evaluation at the end of perform_lraptor is no longer functioning.

The calculated and presented travel time is incorrect. See example below:

2021-02-18 20:27:51,641 - DEBUG - Start point : Arnhem Zuid
2021-02-18 20:27:51,641 - DEBUG - End point : Oosterbeek
2021-02-18 20:27:51,641 - DEBUG - Departure time : 08:30:00
2021-02-18 20:27:51,641 - DEBUG - Rounds : 2
2021-02-18 20:27:51,641 - DEBUG - Cached GTFS : True
...
2021-02-18 20:27:51,750 - DEBUG - Departure ID : ['2323104', '2323103']
2021-02-18 20:27:51,750 - DEBUG - Arrival ID : ['2324242', '2324241']
2021-02-18 20:27:51,750 - DEBUG - Time : 30600
...
2021-02-18 20:27:56,000 - INFO - Destination code : 2324241
2021-02-18 20:27:56,000 - INFO - Time to destination: 48.0 minutes
2021-02-18 20:27:56,282 - INFO - Journey:
2021-02-18 20:27:56,360 - INFO - 08:43:00 Arnhem Zuid TO 08:49:00 Arnhem Centraal WITH 7625
2021-02-18 20:27:56,407 - INFO - 08:52:00 Arnhem Centraal TO 08:56:00 Oosterbeek WITH 7526

The calculated travel time is 48 minutes, but should be 08:56 - 08:30 = 26 minutes.

Describe the bug
In query_range_raptor.py all journey options for all departure times are calculated, followed by a postprocessing step which removes all Pareto-dominated (in arrival and departure time) journey options. However, it also keeps non-dominated journey options. Presumably, this is caused by the is_dominated() function only checking strict domination.

Desktop:

• Python version 3.8
• Application Version 1.2.0

Describe the feature you'd like
I think the TRANSFER_COST is the time window for transfer trips.
But I find that it don't work.
Am I wrong?

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
A GTFS file conains the timetable for a periode of time. Trips vary over time so the stop times table seems to include duplicate stops. The calendar opbject must be used to filter the gtfs data for a specific date. This prevents multiple occurances of the same trip in the dataset which will be evaluated each time it occurs.

To Reproduce
Steps to reproduce the behavior:

1. Dataset: GTFS NL

Looking at the possible trips from one station to another, the stop times table returns multiple results seeming duplicate (only the trip_id is different). Dropping duplicates on the ritnumber reduces the list to the correct size where each ritnumber is only returned once.

Before executing the algorithm, the timetable must be filtered for a specific date.
Another advantage is that the used dataset will be reduced in size by approx 75%.

Planning a journey from 's-Hertogenbosch to Rotterdam Centraal does not offer the possibility to use the ICD.
Other Dutch planners present the routes with and without ICD:

21:42-22:10 HT - BD With NS IC
22:15-22:38 BD RTD with ICD
and
21:42-22:10 HT - BD With NS IC
22:23-22:46 BD RTD with NS IC

This seems to be due to the filter that prevents ysing the same timeseries

To Reproduce
Steps to reproduce the behavior:

1. Use Dutch GTFS
2. Plan journey from 's-Hertogenbosch to Rotterdam Central during day hours

Hi

I was looking at the RaptorAlgorithm -> run(self, from_stops, dep_secs, rounds), and I realize that the class is running multiple origins to multiple targets query, which I thought cannot be done as the local pruning functionality only continuing with the earliest trips.

I was wondering how you manage to run a RAPTOR query for multiple origins to multiple destinations.

I can provide some scenarios to discuss if you want.

Best wishes
Mahdi