Improve stop linking by taking OSM platform polygons into account

[leonardehrenfried]

Summary

Built on the ideas in #4065, this PR implements linking stops to platform ways, more specifically, to a platform's centroid (center of gravity).

It also allows you to configure a list of tags that should be checked for references and matches them up to both stop_id and stop_code.

Result

Schwabstrasse in Stuttgart is a subway station that is often incorrectly linked.

Before

After

Refactoring

It also includes the following refactorings:

• TransitStopStreetVertex is renamed to OsmBoardingLocationVertex
• TransitTaggedStopsModule is equally renamed to OsmBoardingLocationsModule
• Make some fields final in OpenStreetMapModule
• Some tests migrated to Junit5

Issue

closes #4103

Unit tests

Unit tests added.

Code style

Autoformatted.

Documentation

added

cc @demory

[leonardehrenfried]

In today's meeting we all agreed that we don't want to show a line from the center of the platform to the actual stop location to the user, however it will be necessary to show it in the debug client. The last part is not yet implemented but I will do so soon.

[hannesj]

The last part is not yet implemented but I will do so soon.

It should be enough to have it be visible in the debug tiles.

[slvlirnoff]

Another small idea I had afterward, what if you pick the closest point of the platform polygon to the stop instead of the center? Sometimes you have the same platform for two railway and potentially a few different stops (when the platform is split in several sectors). Picking the closest point in the platform geometry could have nice changes between trips on the same platform but on a different railway (for instance from one side to the other side) and would make the distance of that missing line smaller.

[slvlirnoff]

Also, how does this interact with areaVisibility code?

[vesameskanen]

In my opinion, the center is the best choice. We do not know in which car the passenger travels, so starting the walk from the middle gives the best average estimate.

Stop positions from public transit data are often unpredictable an do not necessarily indicate the best linking point.

[leonardehrenfried]

I also think that the centroid is the best option for the reasons that Vesa outlined.

Also, how does this interact with areaVisibility code?

The linking runs after the area visibility has so you will link the waiting point to the closest visibility line. This might look not quite like a straight line. So maybe I should make the centroid also part of the platform polygon so that the area visibility calculator calculates a straight line from all the other nodes.

[leonardehrenfried]

I've now re-added the link in the debug UI.

This is ready for review now.

[leonardehrenfried]

BTW, the screenshot is without areaVisibility so you can actually see what is going on. When you turn it on it becomes hard to see individual lines.