-
Notifications
You must be signed in to change notification settings - Fork 0
14213 Logic to determine which LineString matches direction #8
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: master
Are you sure you want to change the base?
Conversation
import org.locationtech.jts.geom.GeometryFactory; | ||
import org.locationtech.jts.geom.LineString; | ||
import org.locationtech.jts.geom.PrecisionModel; | ||
import org.locationtech.jts.geom.*; |
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.
question: are we using all the sub ".*" options in here to warrant importing them all?
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 change in the imports was done by IntelliJ itself. I don't know where its threshold is. Maybe once it was using four or five imports from the same library it just automatically switches to import them all. Maybe it uses some more sophisticated way to decide or maybe it really needed them.
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 cleanup up the imports.
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.
Pull Request Overview
This PR adds direction-based filtering to the buffer endpoint so that returned LineStrings can be limited to a requested compass direction.
- Introduces a
Direction
enum anddirection
query parameter - Implements
filterByDirection(...)
with cardinal and diagonal logic - Refactors imports and delegates to bearing-based selection for non-cardinal directions
Comments suppressed due to low confidence (3)
web-bundle/src/main/java/com/graphhopper/resources/BufferResource.java:92
- Parsing the direction parameter with valueOf may throw IllegalArgumentException for invalid input. Consider validating the input or catching the exception and returning a 400 Bad Request with a clear error message.
Direction directionEnum = Direction.valueOf(directionUpperCase);
web-bundle/src/main/java/com/graphhopper/resources/BufferResource.java:116
- The new direction-filtering logic covers many branches (cardinal, diagonal, both/unknown). Please add unit tests for each direction and edge cases (empty list, BOTH, UNKNOWN).
private List<LineString> filterByDirection(List<LineString> lineStrings, Boolean buildUpstream, Direction directionEnum) {
web-bundle/src/main/java/com/graphhopper/resources/BufferResource.java:78
- The new
direction
parameter is not documented in the Javadoc or REST API docs. Please update the endpoint documentation to list valid values and describe the filtering behavior.
@QueryParam("direction") @DefaultValue("unknown") String direction,
web-bundle/src/main/java/com/graphhopper/resources/BufferResource.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.
Couple questions
The logic to determine which LineString(s) to return is moved into GraphHopper.
Some nice advantages are: