NOTE: this issue system is intended for reporting bugs and tracking progress in software
development. For all other usage and software development questions or discussion, please post a
question in our chat room: https://gitter.im/opentripplanner/OpenTripPlanner.
Expected behavior
I am running an OTP server and using it to query public transport access from origins (SA1 centroids) to destinations (supermarket points). My code finds the 5 closest supermarkets for each origin and then queries the OTP server to return durations for each of the journeys from origin to destination. If I run this at the same time 10 times in a row, this should return the same trip durations each time for the each of the origin-destination pairs (because I am not changing any variables).
Observed behavior
On some occasions, seemingly randomly, OTP will return 'None' because it can't find a suitable PT journey for a particular origin-destination pair. When I run it again at the same time with the exact same input variables, OTP will instead return the correct duration. This means that the OTP server will return counter-intuitive results e.g will make user walk 15 minutes instead of 5 minutes because it has returned 'None' for the closer supermarket.
Version of OTP used (exact commit hash or JAR name)
"docker run -p {port}:{otp_port} -v {data_filepath}:/var/otp/graphs -e JAVA_OPTIONS=-Xmx{max_memory}G --name otp-{city} urbica/otp --server --autoScan --verbose"
otp_port = 8080
max_memory = 10
city = christchurch
data_filepath is just the folder on my Linux machine where I save the files to.
NOTE: this issue system is intended for reporting bugs and tracking progress in software development. For all other usage and software development questions or discussion, please post a question in our chat room: https://gitter.im/opentripplanner/OpenTripPlanner.
Expected behavior
I am running an OTP server and using it to query public transport access from origins (SA1 centroids) to destinations (supermarket points). My code finds the 5 closest supermarkets for each origin and then queries the OTP server to return durations for each of the journeys from origin to destination. If I run this at the same time 10 times in a row, this should return the same trip durations each time for the each of the origin-destination pairs (because I am not changing any variables).
Observed behavior
On some occasions, seemingly randomly, OTP will return 'None' because it can't find a suitable PT journey for a particular origin-destination pair. When I run it again at the same time with the exact same input variables, OTP will instead return the correct duration. This means that the OTP server will return counter-intuitive results e.g will make user walk 15 minutes instead of 5 minutes because it has returned 'None' for the closer supermarket.
Version of OTP used (exact commit hash or JAR name)
"Env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/lib/jvm/java-1.8-openjdk/jre/bin:/usr/lib/jvm/java-1.8-openjdk/bin", "LANG=C.UTF-8", "JAVA_HOME=/usr/lib/jvm/java-1.8-openjdk", "JAVA_VERSION=8u111", "JAVA_ALPINE_VERSION=8.111.14-r0", "OTP_VERSION=1.4.0", "JAVA_OPTIONS=-Xmx1G"
Data sets in use (links to GTFS and OSM PBF files)
NZ pbf: http://download.geofabrik.de/new-zealand-latest.osm.pbf ChCH GTFS: https://storage.googleapis.com/storage/v1/b/mdb-latest/o/nz-christchurch-christchurch-metro-gtfs-1313.zip?alt=media *OSM file clipped using OSM covert and bounds of [171.6078, -44.0205, 173.7639, -43.1110]
Command line used to start OTP
"docker run -p {port}:{otp_port} -v {data_filepath}:/var/otp/graphs -e JAVA_OPTIONS=-Xmx{max_memory}G --name otp-{city} urbica/otp --server --autoScan --verbose" otp_port = 8080 max_memory = 10 city = christchurch data_filepath is just the folder on my Linux machine where I save the files to.
Router config and graph build config JSON
"docker run -v {data_filepath}:/var/otp/graphs -e JAVA_OPTIONS=-Xmx{max_memory}G --name otp-{city}-graph urbica/otp --build /var/otp/graphs"
Steps to reproduce the problem
Query OTP server 10 times in a row for the same time