-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Restore lookup of multi-modal stations and group of stations #6805
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
Restore lookup of multi-modal stations and group of stations #6805
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## dev-2.x #6805 +/- ##
=============================================
+ Coverage 71.76% 72.00% +0.24%
- Complexity 19330 19437 +107
=============================================
Files 2090 2101 +11
Lines 78771 78774 +3
Branches 8027 7963 -64
=============================================
+ Hits 56529 56724 +195
+ Misses 19384 19242 -142
+ Partials 2858 2808 -50 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@habrahamsson-skanetrafiken This one touches the station centroid feature and I'm not sure I've taken all the required subtleties into account. Can you test this with your data set, please? |
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.
This looks fine to me. I'll verify the centroid stuff in our test environment.
There will be conflicts with #6704 i guess.
application/src/main/java/org/opentripplanner/street/search/TemporaryVerticesContainer.java
Outdated
Show resolved
Hide resolved
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.
These changes look good to me and I agree that the restructuring is a good one.
| * return the child stops of that station. | ||
| */ | ||
| public Set<TransitStopVertex> getFromStopVertices() { | ||
| if (from.stopId == 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.
I had a look at the getFromVertices() and getFromStopVertices() methods etc. They look good to me. I understand that the naming is very similar and a bit confusing.
The thing I did with centroid coordinates is basically to be able to have separate vertices for the street search part and the transit search part.
So if you use a station with a centroid coordinate we will do the street search (and access/egress walking etc) using the centroid coordinate but still do the transit search using the child stop coordinates.
Do you think it would be easier to understand if we renamed the methods to getFromStreetVertices() and getFromStopOrChildStopVertices() perhaps?
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 it's fine the way it is. I was just wondering if the street vertex methods should return the centroid vertex or not. Sounds like they should not.
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.
The stop vertex methods should not, but the street vertex methods should. And this PR seems to keep that behaviour so it looks fine.
application/src/main/java/org/opentripplanner/routing/graph/Graph.java
Outdated
Show resolved
Hide resolved
| * <p> | ||
| * It also facilitates the lookup of site ids to the correct vertices. | ||
| * <p> | ||
| * It implements |
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 created this class to take care of disposing temporary changes to the graph[v,e] . It is a framework "thing", and should not contain business rules (decide between centroid/coordinates/ids). I will approve this PR, since it is only patching the existing features - but this should be refactored, so this class get back to its original responsibility.
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.
Where would you put this logic?
| // check if there is a stop by the given id | ||
| var stopVertex = graph.findStopVertex(location.stopId); | ||
| if (stopVertex.isPresent()) { | ||
| return Set.of(stopVertex.get()); | ||
| } | ||
|
|
||
| // station centroids may be used instead of child stop vertices for stations | ||
| var centroidVertex = graph.findStationCentroidVertex(location.stopId); | ||
| if (centroidVertex.isPresent()) { | ||
| return Set.of(centroidVertex.get()); | ||
| } | ||
|
|
||
| // in the regular case you want to resolve a (multi-modal) station into its child stops | ||
| var childVertices = findStopOrChildStopVertices(location.stopId); | ||
| if (!childVertices.isEmpty()) { | ||
| return childVertices | ||
| .stream() | ||
| .map(Vertex.class::cast) | ||
| .collect(Collectors.toUnmodifiableSet()); | ||
| } |
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.
Maybe this could be pushed into the Graph - at least the Graphs responsibilities matches better than this 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.
The vertex part would be a good fit but should the Graph know about resolving stations to stops?
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.
Also @habrahamsson-skanetrafiken might want to chime in because he asked me to move out of the graph to this 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.
I think we should look at this together in the design meeting, with at least all three of us present.
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 agree, but didn't you want something sooner so that you can release to prod?
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 guess the question is if we want the Graph to know about the hierarchy between stops/stations/multi-modal stations etc. If we don't want the Graph to know about that stuff then this code needs to go somewhere else.
If we want to keep the TemporaryVerticesContainer small, maybe we could extract this id -> vertex resolving logic to a separate class that depends on both Graph and TransitService.
We can look at it in a design meeting.
application/src/main/java/org/opentripplanner/transit/service/TransitService.java
Outdated
Show resolved
Hide resolved
…aph.java Co-authored-by: Thomas Gran <[email protected]>
application/src/test/java/org/opentripplanner/routing/core/TemporaryVerticesContainerTest.java
Outdated
Show resolved
Hide resolved
|
I can work on this feature this week if there is a consensus what I should be doing. |
|
This is now blocking #6791 - there is a merge conflict. Can we merge this, and refactor in a separate PR? |
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.
This PR should be followed up with a PR fixing the problem with the TemporaryVerticesContainer (discussed above). But, the bugfix is a blocker - so we want this to be merged.
|
@habrahamsson-skanetrafiken already approved previously so I will merge this and refactor later. |
Summary
It restores the ability to use the id of a multi-modal station or a group of station for the start and end point of routing requests.
It does it by clarifying responsibilities:
TransitServiceresolves site ids into their child stopsStreetIndexonly has references to stop vertices through their ID but doesn't know anything about stations, group of stations...TemporaryVerticesContaineris the glue that takes the various data sources and returns the correct vertices.Renaming
TemporaryVerticesContaineris not a good name anymore and I would like to rename it. Not sure if I should do it in this PR.Issue
Fixes #6804
Unit tests
Lots added.
Documentation
Lots of methods clarified, Javadocs adde and method grouping improved in the various files.