There sould be only one option for the following set of criterias passed into Raptor for access/egress paths:
stop reached on-board is prefered over reached by walking
no openingHours over having one
less number-of-transfer (FLEX)
shorter duration
smaller generalized-cost
Observed behavior
When debugging Raptor I saw that there were a rejected and a accepted path for each path - this looked a bit strange. It turned out to be duplicate access/egress paths.
How to fix
[ ] Filter away access/egress duplicates in Raptor and log these (I will do that)
[ ] Fix the problem in AStar
Version of OTP used (exact commit hash or JAR name)
dev-2.x
Data sets in use (links to GTFS and OSM PBF files)
latest entur
Steps to reproduce the problem
I will add logic in Raptor to filter away duplicates and add debug logging as well, but we also need to look at why this is happening in AStar. The performance overhead is probably small, but it is annoying when debugging Raptor.
Expected behavior
There sould be only one option for the following set of criterias passed into Raptor for access/egress paths:
Observed behavior
When debugging Raptor I saw that there were a rejected and a accepted path for each path - this looked a bit strange. It turned out to be duplicate access/egress paths.
How to fix
Version of OTP used (exact commit hash or JAR name)
dev-2.x
Data sets in use (links to GTFS and OSM PBF files)
latest entur
Steps to reproduce the problem
I will add logic in Raptor to filter away duplicates and add debug logging as well, but we also need to look at why this is happening in AStar. The performance overhead is probably small, but it is annoying when debugging Raptor.