Inaccurate instruction to "turn onto" a road when a user is already on the road.
jjeffchoi opened this issue · comments
Describe the bug
Misleading instruction to "turn onto" a road when a user is already on the road. For example, "Turn right onto Mavis road" when it should mean "Keep right" or not have an instruction at all. This seems to be a re-occurring phenomenon for lanes that are either expanding the number of lanes or coming to an intersection.
To Reproduce
Installation
- checkout recent and stable version of GraphHopper. I'm using 9.0-SNAPSHOT.
- link to the OSM pbf
- include the config.yml as shown below.
- run
java -Xmx8g -jar web/target/graphhopper-web-*.jar server reader-gtfs/config-example-pt.yml
config-example-pt.yml
graphhopper:
datareader.file: ./ontario-latest.osm.pbf
# for multiple files you can use: gtfs.file: file1.zip,file2.zip,file3.zip
gtfs.file: ./GTFS-UP.zip,./GTFS-TTC.zip,./GTFS-GO.zip
graph.location: graphs/ontario-with-transit
profiles:
- name: foot
vehicle: foot
weighting: custom
custom_model: {}
- name: car
vehicle: car
weighting: custom
custom_model: {}
- name: bike
vehicle: bike
weighting: custom
custom_model: {}
import.osm.ignored_highways: pedestrian,steps
prepare.min_network_size: 200
prepare.subnetworks.threads: 1
graph.dataaccess.default_type: RAM_STORE
server:
application_connectors:
- type: http
port: 8989
bind_host: 0.0.0.0
admin_connectors:
- type: http
port: 8990
bind_host: 0.0.0.0
logging:
appenders:
- type: file
time_zone: UTC
current_log_filename: logs/graphhopper.log
log_format: "%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n"
archive: true
archived_log_filename_pattern: ./logs/graphhopper-%d.log.gz
archived_file_count: 30
never_block: true
- type: console
time_zone: UTC
log_format: "%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n"
loggers:
"com.graphhopper.osm_warnings":
level: DEBUG
additive: false
appenders:
- type: file
currentLogFilename: logs/osm_warnings.log
archive: false
logFormat: '[%level] %msg%nReplicate
- The first way to replicate the issue is by using this API call:
/route?point=43.63760596801055, -79.72452676874094&point=43.59730747633656, -79.68328264351642&profile=car&locale=en&instructions=true&heading=0&ch.disable=true&algorithm=alternative_route&alternative_route.max_paths=2&details=max_speed&points_encoded=false
The road goes from 6-lane to 7-lane to introduce a left-turning lane and the instruction at 43.625503, -79.714227 from one of the paths tells the user to "Turn right onto Mavis Road" even though it's a straight road and the user is already on Mavis Road. The more appropriate instruction would be to "keep right" or no instruction at all.
(heading=0 is actually just a placeholder since it's dynamically generated)
- The second way to replicate the issue is by using this API call:
/route?point=43.69688570414759, -79.3717506690635&point=43.76665194910865, -79.38783723206511&profile=car&locale=en&instructions=true&heading=0&ch.disable=true&algorithm=alternative_route&alternative_route.max_paths=2&details=max_speed&points_encoded=false
Expected behavior
The expected behavior for the first example would be to either not have an instruction, use the "continue", or "keep right" instead of "turn right". The expected behavior for the second example would be either be no instruction or "continue".
System Information
OS: macOS Sonoma
JVM: openjdk version "21.0.2" 2024-01-16
GraphHopper: 9.0-SNAPSHOT
Something is off in your description. Your screenshots show foot routes and your /api queries have profile=car.
As you are using 9.0-SNAPSHOT can you try this on GraphHopper Maps (and provide a link) and see if the same problems occur there?
Here is the link to GraphHopper Maps. There is an instruction to "Turn right onto Mavis road" even though you're already on Mavis road. It looks like it's because of what's seemingly a kink in the road on the map, but in reality it's just a straight road.
Here is another instance where the instruction says to "Turn right onto Dundas Street West" even though you're already on the said road and it's a straight road.
Hm, it looks like these cases happen also relative frequently in the US and other OSM routing engines can handle them without creating a separate turn instruction (at least in your highlighted case). So we should find a way to fix this.
Shouldn't this snippet cover the case?
Edit:
outgoingEdges.outgoingEdgesAreSlowerByFactor(2)is most likely the culprit here
Are there valid cases where InstructionsHelper.isNameSimilar(name, prevName) is not enough?
Thank you for looking into this. Here is maybe a better example.
GraphHopper lists 3 unnecessary instructions:
- Continue onto Bayview Avenue
- Turn right onto Bayview Avenue
- Turn slight right onto Bayview Avenue
- Turn slight right onto Bayview Avenue
- Arrive at destination
whereas Valhalla lists only two, which seems more intuitive for turn-by-turn:
- Drive north on Bayview Avenue
- Your destination is on the left
Thanks a lot for these examples. All those have the "split way" tagging in common associated with a lane count change (often doubling), which makes a good heuristic when to ignore these instructions. If you have time can you review my changes for your example area e.g. locally? (you'll need to add the lanes encoded value in the config graph.encoded_values: lanes)
At least all your linked examples should be fixed with this.
Works great! Thank you very much.