-
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
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>
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
@optionsome It doesn't appear possible to map two internal enum values to the same API value. For that reason I added a mapper that does this before it even gets to the GraphQL library code. |
@@ -75,6 +84,18 @@ void testMap() { | |||
assertEquals("DocumentedEnumMapping[apiName=iH, internal=Hi]", mapping.toString()); | |||
} | |||
|
|||
@ParameterizedTest | |||
@EnumSource(RelativeDirection.class) |
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.
Cool, didn't know this was possible.
case ENTER_STATION, | ||
EXIT_STATION, | ||
ENTER_OR_EXIT_STATION, | ||
FOLLOW_SIGNS -> RelativeDirection.CONTINUE; |
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.
Sorry for the late response here, but this can be dropped. We will just add the new enum values to the Transmodel GraphQL API - I can do it if you want.
The JS GraphQL lib has a validator to compare to schema files for breaking changes - adding Enum values are considered a dangerous change - not a braking change. It should be handled by defensive programming on the client side. So, at entur we want to add the new enum values and we will cross fingers and hope our clients did the right thing.
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 also want to add a better unit-test to the enums we have today - so I can do that in the same change.
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.
Could/should we create a CI test for validating that we are not creating breaking schema changes with the JS GraphQL lib?
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 we still need the mapper so to we don't ever expose ENTER_OR_EXIT_STATION.
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