-
Notifications
You must be signed in to change notification settings - Fork 1k
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
If configured, add subway station entrances from OSM to walk steps #6343
base: dev-2.x
Are you sure you want to change the base?
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 <[email protected]>
Co-authored-by: Joel Lappalainen <[email protected]>
@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? |
application/src/main/java/org/opentripplanner/apis/gtfs/datafetchers/stepImpl.java
Outdated
Show resolved
Hide resolved
application/src/main/java/org/opentripplanner/graph_builder/module/osm/VertexGenerator.java
Outdated
Show resolved
Hide resolved
"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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really have an opinion here. The documentation is clear so I would be fine with either.
@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. |
8c83970
to
b621a6d
Compare
Done in 0b6a74a |
b621a6d
to
0b6a74a
Compare
- Passing through a station entrance or exit when it is not know whether the passenger is | ||
entering or exiting. If known then entrance information is in the `step.entity` field. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a bit vague here what the "known" refers here to. Currently if it's known that are we entering or exiting a station, this information is not exposed, right? However, I think you are trying to refer to the other station information here. You could cross reference to the ENTER/EXIT_STATION here so it's more clear that those enum values are related. The step field is now called feature, not entity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, correct, if we are entering/exiting we get the information from pathways but don't actually add the entity feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, it wasn't a lot of work to extract the Entrance
from the pathway data so I did it here instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if you want to keep the "if available" line then.
application/src/main/resources/org/opentripplanner/apis/gtfs/schema.graphqls
Outdated
Show resolved
Hide resolved
95db61e
to
628bf95
Compare
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
TransitEntranceVertex
andStationEntranceVertex
and 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
instanceOf
checks to describe vertex behaviour. If we have clarified what we want (of which I'm not sure myself) we can change the code and unifyTransitEntranceVertex
andStationEntranceVertex
.Issue
Closes #6078
Unit tests
Tests added.
Bumping the serialization version id
✔️
cc @optionsome