If configured, add subway station entrances from OSM to walk steps #6343
Conversation
# Conflicts: # application/src/main/java/org/opentripplanner/model/plan/Entrance.java # application/src/main/java/org/opentripplanner/model/plan/StepEntity.java # application/src/main/java/org/opentripplanner/street/model/vertex/StationEntranceVertex.java # application/src/main/java/org/opentripplanner/street/model/vertex/VertexFactory.java # application/src/main/java/org/opentripplanner/transit/service/datafetchers/StepEntityTypeResolver.java # doc/user/BuildConfiguration.md
Co-authored-by: Joel Lappalainen <lappalj8@gmail.com>
Co-authored-by: Joel Lappalainen <lappalj8@gmail.com>
leonardehrenfried
added
New Feature
bump serialization id
|
@optionsome I have a question: if we don't expose ENTER_OR_EXIT_STATION at all and use the entrance() method is a step has one, do we even need it at all? |
There was a problem hiding this comment.
Btw can you rename this class to follow the class naming convention, idk why this is the only file that doesn't follow it. Hopefully the renaming doesn't mess up git history.
| if (includeOsmSubwayEntrances && node.isSubwayEntrance()) { | ||
| String ref = node.getTag("ref"); | ||
|
|
||
| boolean accessible = node.isTag("wheelchair", "yes"); |
There was a problem hiding this comment.
This has three states instead of two, use the unknown one when the tag isn't specified.
| "Station entrance or exit, originating from OSM or GTFS data." | ||
| type Entrance { | ||
| "Short text or a number that identifies the entrance or exit for passengers. For example, `A` or `B`." | ||
| code: String |
There was a problem hiding this comment.
I think @t2gran wanted this to be called publicCode, but I don't have a strong preference for either way. The public doesn't really make it more understandable for me but I'm used to the stop code concept.
@t2gran wanted to use enum to determine which "feature" is available, but I don't know if we save any lines of code by checking the enum value vs checking that x feature is non-null when we add support for more features. |
|
Can you add a bit of documentation for the RelativeDirection enum in the schema as well to document this CONTINUE/ENTER_STATION/EXIT_STATION relationship. |
Summary
This takes over from #6076. We led @HenrikSundell down a few dead-ends which I'm sorry about.
I have analysed the problem of the inheritance of
TransitEntranceVertexandStationEntranceVertexand have concluded that it's a problem that is too big to be solved in this PR.The big question we have to answer is if we want to flatten the Vertex hierarchy and rely less on
instanceOfchecks to describe vertex behaviour. If we have clarified what we want (of which I'm not sure myself) we can change the code and unifyTransitEntranceVertexandStationEntranceVertex.Issue
Closes #6078
Unit tests
Tests added.
Bumping the serialization version id
✔️
cc @optionsome