Skip to content
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

Closed

Conversation

leonardehrenfried
Copy link
Member

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.

@leonardehrenfried leonardehrenfried added Technical Debt bump serialization id Add this label if you want the serialization id automatically bumped after merging the PR labels Jun 8, 2023
@leonardehrenfried leonardehrenfried requested a review from a team as a code owner June 8, 2023 10:42
@codecov
Copy link

codecov bot commented Jun 8, 2023

Codecov Report

Patch coverage: 78.46% and project coverage change: +0.02 🎉

Comparison is base (499eb1c) 65.67% compared to head (5fbcca6) 65.69%.

❗ Current head 5fbcca6 differs from pull request most recent head 28c7ded. Consider uploading reports for the commit 28c7ded to get more accurate results

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     
Impacted Files Coverage Δ
...ntripplanner/framework/geometry/GeometryUtils.java 75.18% <ø> (ø)
...raph_builder/module/osm/SafetyValueNormalizer.java 94.44% <ø> (ø)
...ector/raster/TraversalPermissionsEdgeRenderer.java 15.87% <0.00%> (+1.38%) ⬆️
.../opentripplanner/street/model/TurnRestriction.java 72.72% <ø> (ø)
...pplanner/street/model/edge/ElevatorAlightEdge.java 93.33% <ø> (-0.42%) ⬇️
...entripplanner/street/model/edge/EscalatorEdge.java 92.30% <ø> (ø)
...er/street/model/edge/StreetElevationExtension.java 77.41% <ø> (-1.05%) ⬇️
.../opentripplanner/street/model/edge/StreetEdge.java 87.25% <54.54%> (+0.40%) ⬆️
...org/opentripplanner/street/model/edge/OsmEdge.java 60.00% <60.00%> (ø)
...ipplanner/street/model/edge/BarrierCalculator.java 83.33% <83.33%> (ø)
... and 7 more

... and 1 file with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

@@ -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,
Copy link
Member Author

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.

@leonardehrenfried leonardehrenfried added the IBI Developed by or important for IBI Group label Jun 8, 2023
Comment on lines +11 to +14
/**
* Abstract base class for edges derived from OSM data.
*/
public abstract class OsmEdge extends Edge {
Copy link
Member

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.

Copy link
Member

@t2gran t2gran Jun 13, 2023

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.

Copy link
Member Author

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.

Copy link
Member

@t2gran t2gran Jun 15, 2023

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."
Copy link
Member

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;
Copy link
Member

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.
Copy link
Member

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?

Copy link
Member

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.

@t2gran t2gran added this to the 2.4 (next release) milestone Jun 14, 2023
@leonardehrenfried
Copy link
Member Author

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.

@leonardehrenfried leonardehrenfried marked this pull request as draft June 22, 2023 13:32
@t2gran t2gran modified the milestones: 2.4, 2.5 (next release) Sep 13, 2023
@t2gran t2gran modified the milestones: 2.5, 2.6 (next release) Mar 13, 2024
@leonardehrenfried
Copy link
Member Author

I'm no longer going to work on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bump serialization id Add this label if you want the serialization id automatically bumped after merging the PR IBI Developed by or important for IBI Group Technical Debt
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants