Shortest route on (train)platforms and squares.

[sven4all]

Expected behavior

The shortest route as travelers will use in the real world on (train)platforms and squares (redline).

Observed behavior

Routing along the edges of a (train)platform / squares. In worst case this results in >5 minutes longer walking routes compared with the real situation (grey line).

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

2afa6f8ea5b15eaf0c39ad0159fd4eddf27e12ae (dev-2.x), but same issue on OTP < 2.0

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

https://data.moopmobility.nl/gtfs/new/gtfs-nl.zip https://data.moopmobility.nl/gtfs/new/gtfs-iff-nl.zip

http://download.geofabrik.de/europe/netherlands-latest.osm.pbf

Command line used to start OTP

/usr/bin/java -Djava.io.tmpdir=${OTP_TMP} -XX:NewRatio=1 -Xms$MAXMEM -Xmx$MAXMEM -server -jar "${JAR}" --load "${BASEPATH}/graphs" --serve --maxThreads 16

Router config and graph build config JSON

config_otp.zip

Steps to reproduce the problem

Plan trip from (52.08884, 5.10993) to (52.22613, 5.18141). There are several trainstations where similar problems are occurring.

[gmellemstrand]

I don't know if there is an issue about this, but it is a known problem. What happens is that the street graph is built from OSM data, then the area visibility edges are generated (both in the OSM module), and then in another module the stops are linked to the platforms. This results in the visibility edges not taking into account the new vertices where stops have been connected to the platform edge, creating these detours.

A solution to this could be to split the visibility edges generation into a separate module that is run after the stops have been linked.

[sven4all]

Thanks!

I was already trying this morning to tweak with some parameters:

I setted to "areaVisibility": true "extraEdgesStopPlatformLink": true

This helped to improve the working, I think some documentation could be improved because it's not completely clear to me what it is doing.

[JohanEntur]

There is an issue where edges are generated across one platform, but other one is left with routing only on outer edges. Same result as mentioned above, the interchange is forced up to 5 minutes when it really should have been 3-4.

Porsgrunn stasjon

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days