The multi-criteria range raptor uses uses cost as one of its criteria. We assume that we can time-shift the first access leg toward the transit leg, hence avoid waiting at the first stop by delaying the departure. But, the cost-function do not account for this and calculate a wait-cost between access and the first transit.
Expected behavior
No additional cost added to the cost criteria in multi-criteria Range Raptor.
Observed behavior
Same cost added between access and transit, as between transit and transit.
Version of OTP used (exact commit hash or JAR name)
f76183e
Data sets in use (links to GTFS and OSM PBF files)
Entire Norway Netex
Command line used to start OTP SpeedTest
I used the SpeedTest to verify this with :
--profiles mc --verbose --debugPath 2710,4452
travelSearch.csv
testCaseId,description,departure,arrival,window,origin,fromPlace,fromLat,fromLon,destination,toPlace,toLat,toLon
1,Oslo,16:05,17:05,0:10,Marienlyst,,59.93232,10.72466,Kjøbenhavngata,,59.92898,10.76944
Steps to reproduce the problem
Change the departure time (18:05) above and observe the cost change at the first stop (log).
** RUN RAPTOR FOR MINUTE: 16:06:00 **
ARRIVAL | LEG | RND | STOP | ARRIVE | COST | TRIP | DETAILS
Accept | Access | 0 | 2710 | 16:06:17 | 6800 | | Accepted element: Walk 0:17 > 2710 (cost: 6800)
ARRIVAL | LEG | RND | STOP | ARRIVE | COST | TRIP | DETAILS
Accept | Transit | 1 | 4452 | 16:21:00 | 125100 | null | Accepted element: Walk 0:17 > 2710 > Transit 16:10-16:21 > 4452 (cost: 125100)
>>> PATH | TR | FROM | TO | START | END | DURATION | COST | DETAILS
Accept | 0 | 2710 | 4452 | 16:07:43 | 16:22:10 | 14:27 | 153100 | Accepted element: org.opentripplanner.transit.raptor.api.debug.DebugEvent@28fc2d04
Reject | Transit | 1 | 4452 | 16:24:00 | 143100 | null | Rejected element: Walk 0:17 > 2710 > Transit 16:11-16:24 > 4452 (cost: 143100)
** RUN RAPTOR FOR MINUTE: 16:05:00 **
ARRIVAL | LEG | RND | STOP | ARRIVE | COST | TRIP | DETAILS
Drop | Access | 0 | 2710 | 16:06:17 | 6800 | | Droped element: Walk 0:17 > 2710 (cost: 6800)
->by | Access | 0 | 2710 | 16:05:17 | 6800 | | ->byed element: Walk 0:17 > 2710 (cost: 6800)
Accept | Access | 0 | 2710 | 16:05:17 | 6800 | | Accepted element: Walk 0:17 > 2710 (cost: 6800)
:
SpeedTest SUCCESS 372 ms #1 Marienlyst - Kjøbenhavngata, (59,932, 10,725) - (59,929, 10,769), 16:05-18:05(02:00)
STATUS | TF | Duration | Cost | Start | End | Modes | Agencies | Routes | Stops | Legs
OK | 0 | 14:27 | 130800 | 16:07:43 | 16:22:10 | BUS | Ruter | 28 | 2710 4452 | WALK 0:17 - 2710 - BUS 28 16:10 16:21 - 4452 - WALK 1:10
The multi-criteria range raptor uses uses
costas one of its criteria. We assume that we can time-shift the first access leg toward the transit leg, hence avoid waiting at the first stop by delaying the departure. But, the cost-function do not account for this and calculate a wait-cost between access and the first transit.Expected behavior
No additional cost added to the cost criteria in multi-criteria Range Raptor.
Observed behavior
Same cost added between access and transit, as between transit and transit.
Version of OTP used (exact commit hash or JAR name)
f76183e
Data sets in use (links to GTFS and OSM PBF files)
Entire Norway Netex
Command line used to start OTP SpeedTest
I used the SpeedTest to verify this with :
--profiles mc --verbose --debugPath 2710,4452travelSearch.csv
Steps to reproduce the problem
Change the departure time (18:05) above and observe the cost change at the first stop (log).