Extend stop area relation linking to include bus stop and platform nodes - #5319
Conversation
It seems that isolated nodes tagged with highway=bus_stop or public_transport=platform are sometimes used for linking transit stops with OSM street network using ref tagging. Such isolated nodes must be linked into surrounding platforms.
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## dev-2.x #5319 +/- ##
=============================================
+ Coverage 66.26% 66.36% +0.10%
+ Complexity 15179 15178 -1
=============================================
Files 1789 1785 -4
Lines 69300 69180 -120
Branches 7355 7336 -19
=============================================
- Hits 45923 45914 -9
+ Misses 20890 20786 -104
+ Partials 2487 2480 -7
☔ View full report in Codecov by Sentry. |
|
There is a strange problem: graph build from the stopareas.pbf test file works as expected, and if I run the single test: mvn surefire:test -Dtest=WalkableAreaBuilderTest then the single test works fine. However, when running all unit tests, one of the tests fails. Also, rearranging assertions within WalkableAreaBuilderTest fixes the problem. I have no idea what is going on. |
|
I'm had a look if I can find some global state somewhere. There is the |
|
I still see random failures in WalkableAreaBuilderTest. Strange enough, another assertion sometimes fails locally as in github workflow. I don't think that the minor code change of this PR can explain the strange behaviour. Maybe an older random bug just started showing up. |
|
My theory is that the If it solves the problem, you can pull it into your branch. |
|
Hmm, that didn't solve it. :/ I'm currently looking around the code for sources of non-determinism and I'm testing one more thing. If that doesn't work, I give up and we can disable the test. |
|
OK, thanks. I found out that in test bench, vertex count is 18. When loaded to OTP (default settings + areaVisibility), vertex count is 35. I suspect that test setup somehow skips some graph processing actions. Anyway, it is strange that the failure and the actual assertion where fail happens changes randomly. |
|
So experimented a bit: https://github.com/leonardehrenfried/OpenTripPlanner/tree/flicker-test I made the maxAreaNodes configurable per test and also made the I still cannot really explain it but I think merging this branch is worth a try. |
|
Your new change set fixed random errors locally! Running the whole test bench or the single test class always succeeds. I am still curious about the graph size difference (unit test graph vs normal OSM loaded into OTP) and will examine that part a bit more. Probably not relevant for approval of this PR. |
| @Visibility(true) | ||
| public void test_calculate_vertices_area() { | ||
| @MaxAreaNodes(5) | ||
| public void test_calculate_vertices_area(TestInfo testInfo) { |
There was a problem hiding this comment.
Is using underscore in test method names ok in our conventions?
There was a problem hiding this comment.
It's not. I don't know how that managed to get past review. I'm in favour of changing it.
| import org.opentripplanner.street.model.vertex.VertexLabel.OsmNodeOnLevelLabel; | ||
| import org.opentripplanner.transit.model.framework.Deduplicator; | ||
|
|
||
| @Execution(ExecutionMode.SAME_THREAD) |
There was a problem hiding this comment.
Is this or other changes that were made in order to get tests to work before the final change still required for the tests to work?
There was a problem hiding this comment.
Seems to work without it as well.
There was a problem hiding this comment.
This line is not necessary but the rest of the changes is IMO worthwhile even if it doesn't fix the non-determinism, which I think was caused somehow by maxAreaNodes and the visibility vertices.
|
I like the handling of isolated nodes (not connected to the road network), if they are part of a public transport relation of kind stop area. It gives me a way forward with #5032 without making up physical ways. The alternative would be for the graph builder to look at every node that is not part of a way and check for public transport tags. Now it just needs a mention in the documentation of this small deviation from the OSM tagging scheme. I think a short note will do https://docs.opentripplanner.org/en/v2.3.0/BoardingLocations/?h=boar#notes e.g.
Example still needing a stop_area relation https://www.openstreetmap.org/node/2382791901#map=19/49.72095/8.84158&layers=D Example that already has a relation https://www.openstreetmap.org/relation/13603101 |
|
Actually, do you want to add Karl's suggestion to the BoardingLocation docs? |

Summary
Stop_area relation processing got stricter rules when PR Bug fixes in stop area relation processing by vesameskanen · Pull Request #5166 · opentripplanner/OpenTripPlanner got merged. Before that, all member nodes got linked, sometimes through different levels or layers.
This PR relaxes linking restrictions back a bit so that nodes tagged with highway=bus_stop and public_transport=platform are accepted as platform linking points. At least Finnish OSM data contains many platforms where the stop ref tag is attached to such nodes. If the node is isolated, it gets removed and ref tag linking breaks.
An example:
https://www.openstreetmap.org/node/1009636736#map=19/60.28262/24.97928&layers=D
Unit tests
New unit test ensures that relation member tageed as highway=bus_top gets linked.
Documentation
StopAreas.md document updated