locally created turn restrictions not observed

[jamiedtor]

We've been attempting to use OTP (1.5) to test the impacts of various street-work scenarios, including inserting or removing links/ways and imposing turn restrictions. As a trial, we've attempted to edit a .pbf of the Isle of Wight (provided by the R package opentripplanner) using JOSM and its plugins pbf and turnrestrictions before creating a new graph and testing with Grizzly.

Observed behavior

The removal or addition of new ways are accounted for in routing; new turn restrictions do not appear to be. You can see in this first image, the route between the test origin and destination makes use of "Testing Road" via a left turn from Steynes. "Testing Road" is a completely new way and the routing engine uses it.

In the second image, you can see that with "Testing Road" removed from the .pbf (and the graph rebuilt), a different driving route is selected.

The engine appears, however, to ignore newly created turn restrictions. In this third image, you can see two turn restrictions that should make it impossible to complete the route shown in the fourth image.

Expected behavior

Neither the left turn from Steyne to "Testing Road," nor the right turn onto Swains should be permitted.

Version of OTP used (exact commit hash or JAR name)

1.5 (downloaded by r package opentripplanner

Data sets in use (links to GTFS and OSM PBF files)

https://drive.google.com/file/d/1bV32xoYObXEFwPZW36-xZUnSg7vo2EZP/view?usp=sharing

Command line used to start OTP

Router config and graph build config JSON

Steps to reproduce the problem

[leonardehrenfried]

This sounds a lot like the following bug: #2991

It has long been fixed in OTP2. Is there a reason you're not using the latest version?

[jamiedtor]

Thanks, Leonard! It does appear to be similar. We've re-tested using OTP 2.2 and our locally created restrictions are respected. We'd been using 1.5 simply because it was the default version used by the opentripplanner R package and we already had the correct java version for it installed on our admin-restricted PCs. Now that we know that OTP 2.2 will handle it, we can make the switch, though. Shall I close out the issue as resolved by other means or do you think I should leave it open as still relevant for older OTP versions that people may still be using?

[leonardehrenfried]

Lets close it.