Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Boardinglocations on ways don't seem to work as expected #6056

Open
Brickblock1 opened this issue Sep 10, 2024 · 3 comments · May be fixed by #6247
Open

Boardinglocations on ways don't seem to work as expected #6056

Brickblock1 opened this issue Sep 10, 2024 · 3 comments · May be fixed by #6247

Comments

@Brickblock1
Copy link

Expected behavior

A way in OSM with the a key and public_transport=platform will establish a BoardingLocationToStopLink

Observed behavior

This doesn't happen but the platform does show up in the visualizer as traversable so that isn't the issue.

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

otp-2.5.0-shaded.jar

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

lenna.zip

Samtrafiken netex regional lennakatten

Command line used to start OTP

C:/Users/user/Documents/OTP/jdk-22.0.2/bin/java.exe -Xmx7G -jar otp-2.5.0-shaded.jar --build --save --serve --visualize C:/Users/users/Documents/OTP/lenna"

Router config and graph build config JSON

Steps to reproduce the problem

Build the graph with the provided data
Check to see if SE:116:Quay:9022116000002001 is a BoardingLocationToStopLink or not, compare this to the stops at Uppsala Centralstation where the node and areas with referenced quays are working as expected

@t2gran t2gran pinned this issue Sep 11, 2024
@leonardehrenfried
Copy link
Member

I think you will receive better quality help if you posted screenshots and a link to the OSM way in question.

Also, the very latest dev version of OTP has a much better way of visualising and debugging the street network.

@vpaturet vpaturet unpinned this issue Sep 13, 2024
@miklcct
Copy link
Contributor

miklcct commented Sep 30, 2024

I can confirm with Bond Street station on the Underground platforms using version 2.6.0. I have just done a survey there for the complete underground station mapping (the platforms are narrow so I mapped them as a way), but unfortunately it doesn't work with OpenTripPlanner.

The following is an example for Jubilee line northbound, with Naptan ID 9400ZZLUBND2 . Pedestrian routing from street to platform works as expected.

image

Note that the Elizabeth line routing works correctly on my server but it is because I am using an in-house feed for National Rail which directly takes position data from OpenStreetMap, instead of an external feed for the Underground services.

P.S. I am doing some postprocessing of data to circumvent the problem on Bond Street so you may not see the above bug on my server in the future. However, I have also mapped Chancery Lane station with the appropriate tag (the data pipeline should load the changes 2 to 3 days later), and it is impossible to circumvent this at a data level as the platforms are stacked, so I will leave this as the test case in London.

@miklcct
Copy link
Contributor

miklcct commented Nov 7, 2024

This has become a major usability issue for our journey planner in London for the underground. We have a number of narrow tube platforms (i.e. mapped as a way) which are directly under roads, and getting this wrong can cause unrealistic transfer times.

The following shows two itineraries involving changing between Moorgate (Northern City Line) and Liverpool Street (National Rail), one from Platform 9 and one from Platform 10. They are on the same level underground connected by corridors, yet OSM handles one properly, and the other is placed on the street.

image
image

@miklcct miklcct linked a pull request Nov 11, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants