-
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
Add flex stop to TripTimes, return geometries in GraphQL API #3757
Add flex stop to TripTimes, return geometries in GraphQL API #3757
Conversation
bddcc2a
to
130c3f2
Compare
Tried to build this with http://oregon-gtfs.com/gtfs_data/lincolncounty-or-us/lincolncounty-or-us--flex-v2.zip and it crashed
|
Does this work with the latest dev-2.x version? |
At least it builds, haven't tested otherwise |
I think I know what the problem is. The trip in question has the following stop times:
I has continuous pick up/drop off set to OpenTripPlanner/src/ext/java/org/opentripplanner/ext/flex/trip/UnscheduledTrip.java Line 46 in 63a1182
and thinks it's not a flex trip. @hannesj Do you know why the check for the continuous pick up/drop off happens? |
It's presumably because of this:
This functionality doesn't exist anymore, isn't it @hannesj? |
I've tested it locally and if i removed the check for continuous pick up it works as expected. |
But I will wait for a comment by @hannesj before I commit the deletion. |
Yet. There is a draft implementation in #3457
I'm a bit unsure what that combination of flags would mean? Maybe a suggestion to the GTFS-Flex specification that continuous stops can't be defined for flex areas/groups |
I'm also puzzled what continuous pick up would mean in this case. Doesn't the flex area already imply that? On the other hand it's probably a permitted combination. What do you think of keeping the code as is and before doing the interpolation we check if the stop times contain a |
I've pushed a simple fix that excludes any trip with flex stops from the interpolation process. This restores the previous behaviour where those trips would not be recognised as flex trips. I've also added a test that the GTFS files can be parsed nevertheless. After some thinking I believe the continuous pick up field is there to stay compatible with the flex v1 spec. |
511377e
to
08a4522
Compare
BTW, @optionsome continuous pickup for flex zones seems to be considered an invalid combination. If you have another opinion, you can comment on the Flex spec issue: MobilityData/gtfs-flex#70 |
src/main/java/org/opentripplanner/gtfs/RepairStopTimesForEachTripOperation.java
Outdated
Show resolved
Hide resolved
@@ -374,7 +375,7 @@ private boolean hasShapeDist(FeedScopedId shapeId, List<StopTime> stopTimes) { | |||
continue; | |||
} | |||
double distance = segment.distance(coord); | |||
if (distance < maxStopToShapeSnapDistance) { | |||
if (distance < maxStopToShapeSnapDistance || isFlexTrip) { |
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.
Should we check if either of the stops is a flex stop 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.
I'm checking whether the trip contains any flex stops. Do you think that this check is too broad?
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, we can just check if the variable stop here is an actual stop, and not a flex one
I'll run some tests using Netex flex routes, and approve if it works ok. |
@@ -132,6 +133,11 @@ | |||
return environment -> null; | |||
} | |||
|
|||
@Override | |||
public DataFetcher<Object> geometries() { | |||
return environment -> getValue(environment, StopLocation::getGeometry, station -> null); |
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.
Should stations also have geometries so the same method could be used for stations as for stops in clients to draw them etc?
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 implemented it as a geometry collection which contains the point of the station and a convex hull of all child stops.
0e20d0a
to
d7cc4dc
Compare
9ecb4d5
to
69a219c
Compare
@hannesj I corrected the transfer priority handling for flex stops and could successfully start the Norwegian graph and send queries. |
I tested this with the Norwegian graph, and it seems to work properly. However i noticed that the unscheduled stoptimes had been broken for some time. I have fixed those in #3782 |
Support and change in GTFS behaviour were in opentripplanner#3757
Summary
As discussed in previous meetings this does the following:
StopLocation
instead ofStop
If you want to know what the GraphQL output looks like, check this out: https://gist.github.com/leonardehrenfried/d2b3abb6bd14a2237bb319ff440f7c89
It wasn't very easy to exclude the stops from the Raptor code, so I disallowed boarding and alighting from them in the Raptor code. This adds another check for each stop in the Raptor code so it has a potential performance impact. I'm running the speed tests right now to see how bad it is.@hannesj has made a really good suggestion: set the board/alight permissions during instantiation of
StopPattern
so adding these stops doesn't have a runtime cost.Issue
#3756
Unit tests
Tests were added.
Code style
Yes.
Documentation
I've added lots of JavaDoc, particularly for the tests.