-
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
Extract stairs handling into separate edge #5177
Conversation
4fc9378
to
40f7e9e
Compare
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## dev-2.x #5177 +/- ##
=============================================
+ Coverage 65.67% 65.69% +0.02%
- Complexity 14723 14739 +16
=============================================
Files 1769 1772 +3
Lines 68568 68609 +41
Branches 7288 7281 -7
=============================================
+ Hits 45035 45076 +41
- Misses 21037 21040 +3
+ Partials 2496 2493 -3
☔ View full report in Codecov by Sentry. |
@@ -6314,10 +6314,62 @@ org.opentripplanner.routing.algorithm.mapping.TransitSnapshotTest.test_trip_plan | |||
"absoluteDirection": "WEST", | |||
"area": false, | |||
"bogusName": false, | |||
"distance": 1470.24, | |||
"distance": 5.54, |
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 tried hard to figure out why the results are different in this case but I failed. The new path takes a shortcut through a park which seems like an improvement to me.
/** | ||
* Abstract base class for edges derived from OSM data. | ||
*/ | ||
public abstract class OsmEdge extends Edge { |
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 should have different name and description but unfortunately I have no idea what.
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.
Adding classes in a class hierarchy that "only" provide some common code is usually a bad idea, it lead to fragmented code. An in this case also extra memory usage. The only logic I can see is in the constructor, that could be extracted and shared in other ways. Can the many setters and the lack of polymorphic behaviour be replaced with a builder instead - or just revert?
I will wait with the review until this is 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.
I agree that these setters are ugly but the problem here is that these setters are making the code more polymorphic, not less. If we removed these, then I have to put instanceOf
in many places to figure out if that edge handles them or not. These setters are not only used to construct the object but also to modify the edges later on in the build process.
I also want to get rid of them but that would be a larger refactoring. We have two options here:
- Always use builders until the last possible moment in the build process and then build the graph at the very end.
- Make edges more immutable but allow it (perhaps via a builder) to replace them in a graph with a version with updated values.
All in all, I think that this is a topic for a dev meeting when Thomas is back from holiday.
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 will be there today, if not I will try to join next Thursday. I think the second option is the best choice. To do that you can do the following (psudo code):
abstract class AbstractEdge<T> {
/** Default implementation does nothing!!! */
T withX(x : X) : T { return this; }
}
class ElevatorEdge extends AbstractEdge<ElevatorEdge> {
ElevatorEdge withX(x : T) : ElevatorEdge {
var newEdge = new ElevatorEdge(..., x);
replace_ this_with_newEdge();
return newEdge;
}
}
inAngle = calculateAngle(DirectionUtils.getFirstAngle(geometry)); | ||
} catch (IllegalArgumentException iae) { | ||
LOG.error( | ||
"exception while determining street edge angles. setting to zero. there is probably something wrong with this street segment's geometry." |
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 isn't necessarily a street edge.
private final I18NString name; | ||
private final byte[] compactGeometry; | ||
private final double distance; | ||
private float walkSafetyFactor = 1f; |
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 think we should consider safety for stairs as we have a separate reluctance for stairs.
import org.opentripplanner.street.search.state.State; | ||
|
||
/** | ||
* Represents a flight of stairs that are derived from OSM data. |
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.
Do we actually have to have different classes for stairs coming from OSM and GTFS pathways. What is the difference between stairs coming from different data sources? This is also a more general question, does it make sense to have the PathwayEdge class which can be stairs etc and then these specific edges coming from OSM data?
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 class has slightly confusing name as this is used by StreetEdge class but also by other classes that have no relation to that class.
I'm going to put this PR on hold until we have worked out a strategy for the clean up when Thomas is back from holiday. |
I'm no longer going to work on this. |
Summary
As discussed in the A* meeting a few weeks ago, this extracts the handling of the stairs out of the
StreetEdge
and into its own edge.This makes it easier to reason about the logic of
StreetEdge
and as the conceptual weight of it is decreased.The newly created abstract base class
OsmEdge
will also make it easier to implement the escalator handling that @optionsome and @nurmAV are working on at #5046.Unit tests
Added.
Bumping the serialization version id
Automatically.