-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Add a separate layer group in debug UI for elevator edges and vertices #6885
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
base: dev-2.x
Are you sure you want to change the base?
Conversation
| return; | ||
| } | ||
|
|
||
| if (edge instanceof ElevatorHopEdge) { |
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.
Is this still necessary?
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.
In case of ElevatorHopEdges, the condition for early return used to happen the line before because they didn't return a geometry. So this is something I had to add as a special case.
| @Override | ||
| public LineString getGeometry() { | ||
| List<Coordinate> segmentCoordinates = Arrays.asList(fromv.getCoordinate(), tov.getCoordinate()); | ||
| return GeometryUtils.getGeometryFactory() |
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.
You can use GeometryUtils.makeLineString here.
application/src/main/java/org/opentripplanner/street/model/edge/ElevatorHopEdge.java
Show resolved
Hide resolved
application/src/main/java/org/opentripplanner/street/model/vertex/ElevatorVertex.java
Show resolved
Hide resolved
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## dev-2.x #6885 +/- ##
=============================================
- Coverage 72.10% 72.10% -0.01%
- Complexity 19666 20054 +388
=============================================
Files 2125 2177 +52
Lines 79522 80966 +1444
Branches 8049 8135 +86
=============================================
+ Hits 57341 58378 +1037
- Misses 19345 19713 +368
- Partials 2836 2875 +39 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Fix the formatting please. |
|
You need to resolve conflicts. |
3e9e6dd to
14f0bdb
Compare
| StyleBuilder.ofId("elevator-hop-edge") | ||
| .group(ELEVATORS_GROUP) | ||
| .typeLine() | ||
| .vectorSourceLayer(edges) | ||
| .edgeFilter(ElevatorHopEdge.class) | ||
| .lineColor(ORANGE) | ||
| .lineWidth(LINE_HALF_WIDTH) | ||
| .lineOffset(LINE_OFFSET) | ||
| .minZoom(6) | ||
| .maxZoom(MAX_ZOOM) | ||
| .intiallyHidden(), |
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 are slightly problematic as they are used for all elevators, but only visible for the horizontal elevators currently since the line has 0 length usually. I was thinking should we rename this so it's more clear that these will only show up for the horizontal elevators or somehow draw them as circles when they have 0 length and as lines when they don't. However, it's also possible that we don't do anything about it now.
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 somewhat agree but I still think that since we don't do any special filtering for these edges we'd want the name to represent all of them. Then the ui just draws what it can
application/src/main/java/org/opentripplanner/inspector/vector/edge/EdgePropertyMapper.java
Show resolved
Hide resolved
|
I've modified this PR to add a getGeometryForDebugUi method with a default implementation in the Edge class. This way I can implement the special case for ElevatorHopEdge without the risk of breaking something by implementing getGeometry. In case the elevator edge has no horizontal component, I've also added logic to move the other end a little to make it visible in the UI. I'm not sure if that's the cleanest way to achieve what we want but I'd like to hear some opinions. |
| kv("permission", e.getPermission()), | ||
| kv("levels", e.getLevels()), | ||
| kv("wheelchairAccessible", e.isWheelchairAccessible()), | ||
| kv("travelTime", e.getTravelTime()) |
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 default value for the travel time is 0 which means that it's not actually being used. Maybe it would be less confusing to not expose this field for the edge if it's 0 or expose it as null as otherwise it leads to confusion.
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.
Mapping zero to null can be a problem if the value from OSM is zero. Having a default value of -1 is also not good imo because it would represent traveling back in time. Maybe travelTime could be defined as a Nullable Duration instead of an int. We could also just leave it as it is and expect the user to be able to look up what the value represents. What does @leonardehrenfried think of this?
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 method is only used in tests and now here, so we don't have to adjust any calling code. I would indeed return Optional<Duration> and an empty optional in the 0 case.
| } | ||
|
|
||
| @Override | ||
| public LineString getGeometryForDebugUi() { |
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 would like us to think if we consider how the edge should look like in the debug UI to be part of its domain model. If it is, then this code can stay here. It it isn't we should create a new mapper inside the inspector package.
But I generally agree that there can be debug-specific geometries.
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 could be easily moved into inspector.vector.edge.EdgeLayerBuilder where it is called from and have a mapper there. I'm not sure which is better.
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 @t2gran suggested this current solution (although I'm not sure if he gave any name suggestions for the method name).
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.
Okay then, lets call it getDebugGeometry and keep it here. Please add a bit of Javadoc about what it is.
Summary
Issue
This is related to improving indoor navigation #6829
Unit tests
style.json was regenerated by DebugStyleSpecTest.java
Bumping the serialization version id
Minor changes made to both ElevatorHopEdge and ElevatorVertex which requires to bump serialization id