Closed gcheval closed 3 years ago
Thanks for reporting this. Unfortunately our tests did not caught this - do you have a reproducer? And does it work with these changes? (Please note that in this branch profiles are required, see the changes in pt config)
A temporary workaround could be to disable subnetwork removal.
@karussell Hey Peter,
I'm still seeing an invalid polygon with issue_2341 branch.
To reproduce, I'm using district-of-columbia-latest.osm.pbf and 81e47cffd9a6df6ed30257f3b58bac3a6a547cbb.zip GTFS file.
My config:
graphhopper:
graph.flag_encoders: foot,car
profiles:
- name: foot
vehicle: foot
weighting: fastest
- name: car
vehicle: car
weighting: fastest
profiles_ch:
- profile: foot
- profile: car
profiles_lm: []
Tell me if there's anything else I can do to assist.
Thanks!
Guillaume
Hey @karussell, I've created a PR #2342 towards this one. It seems like combined with your changes, it fixes the PT isochrones generation.
Thanks! See #2343 where your changes are merged.
Now we only need a small test that catches this (preferable without the need to add a different data set :) ). Will see if I can find it :)
Describe the bug A regression was introduced to the generation of public transit isochrones in PR #2290.
Depending of the location where the isochrone starts, the code will generate an invalid polygon.
To Reproduce
Steps to reproduce the behavior. For examples:
java -Ddw.graphhopper.datareader.file=district-of-columbia-latest.osm.pbf -Ddw.graphhopper.gtfs.file=81e47cffd9a6df6ed30257f3b58bac3a6a547cbb.zip -jar *.jar server config-example.yml
Expected behavior The isochrone generated should be valid and relevant.
Screenshots & Logs
Isochrone generated using commit 9a0a032e0440d26a1b9f2c7c071192739bb559e7.
Isochrone generated using previous commit 7c289fecac4aef0a41ac1a9ae95b0d999648d8a8.