-
Notifications
You must be signed in to change notification settings - Fork 394
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
Feature#480 maximum speed #740
Conversation
…mumSpeedWeighting in the development branch.
…arams. Everything seems to work now.
…ighting in ORSGraphhopper and ORSWeightingFactory.
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.
Thanks for addressing my previous comments.
I've added some further points for your consideration.
Cheers!
...main/java/org/heigit/ors/routing/graphhopper/extensions/weighting/MaximumSpeedWeighting.java
Outdated
Show resolved
Hide resolved
...routeservice/src/main/java/org/heigit/ors/routing/graphhopper/extensions/ORSGraphHopper.java
Outdated
Show resolved
Hide resolved
openrouteservice/src/main/java/org/heigit/ors/routing/RoutingProfile.java
Outdated
Show resolved
Hide resolved
openrouteservice/src/main/java/org/heigit/ors/routing/RoutingRequest.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.
Thanks a lot for taking your time to improving the code, we are almost there!
First of all please make sure the API tests pass. Currently they fail, most probably because of places where still the old parameter name user_speed
is used. Please search for any leftover occurrences and prune them.
Apart from this, I believe the handling of the maximum_speed_lower_bound
value set through the config file could still be improved - see the inline comments.
Cheers!
PS: Please have a look at any previously unresolved conversations as well, thanks!
openrouteservice/src/main/java/org/heigit/ors/routing/RoutingRequest.java
Outdated
Show resolved
Hide resolved
...routeservice/src/main/java/org/heigit/ors/routing/graphhopper/extensions/ORSGraphHopper.java
Outdated
Show resolved
Hide resolved
*/ | ||
|
||
public class MaximumSpeedCoreEdgeFilter implements EdgeFilter { | ||
private double maxSpeed = ((AppConfig.getGlobal().getServiceParameter("routing.profiles.default_params","maximum_speed_lower_bound")) != 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.
The handling of maximum_speed_lower_bound
value from the config file still needs some refactoring. Currently there are 3 different places over the code where this value is parsed and if missing the hard-coded value of 80 is used. The default value, even if hard-coded, should appear only once in the whole codebase.
I suggest to use RouteProfileConfiguration
class to store the value of maximumSpeedLowerBound
. Have a look at the implementation of the maximum_distance
parameter, it will be probably quite similar.
This change might require, for example, that maxSpeed
value is resolved upstream in ORSGraphHopper
from CmdArgs
set in RoutingProfile
, and passed to MaximumSpeedCoreEdgeFilter
as a constructor argument.
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.
Update: please use GraphProcessContext
rather than CmdArgs
for passing the maximum_speed_lower_bound
.
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 introduction of maximumSpeedLowerBound
has made maxSpeed
redundant, so please remove the latter.
private final Weighting superWeighting; | ||
private final DecimalEncodedValue avSpeedEnc; | ||
private boolean calculateWeight; | ||
private double maxSpeed = ((AppConfig.getGlobal().getServiceParameter("routing.profiles.default_params","maximum_speed_lower_bound")) != 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.
As mentioned before, use RouteProfileConfiguration
as a canonical place to store the dafault. maxSpeed
could probably be passed via HintsMap
.
Actually, validation of maximum_speed
could happen upstream in ORSGraphHopper
where MaximumSpeedWeighting
is created, so there is no need for maxSpeed
parameter here.
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.
Which HintsMap
exactly?
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.
Change of plans. After looking into this further I think maximum_speed
validation should be handled even before in RoutingProfileManager
. It should be safe to assume that once MaximumSpeedWeighting
is created the value has been already verified so no need to check again.
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.
So Should I wait for further info?
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 have any more insights for now. My latest comments reflect how I would proceed with the implementation, however, feel free to look around yourself. Maybe there is an even better and cleaner way of doing 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.
Moving the validation of maximum_speed
upstream to RoutingProfileManager
has rendered both maximumSpeedLowerBound
and maxSpeed
obsolete. If the program execution arrives at this point it is already clear that maximum_speed
is above the threshold, so no need of checking this again, right? Please remove both fields from the class.
openrouteservice/src/main/java/org/heigit/ors/api/requests/routing/RouteRequestHandler.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.
Please make sure that your updates are not breaking the code. In fact, currently the API test for maximum speed does not pass. I leave it to you to figure out what the problem is.
Actually, test driven development is a good way of ensuring software requirements. I've added some additional API tests which cover the following checks:
- that
maximum_speed
value below the configured threshold results in an appropriate error, maximum_speed_lower_bound
setting can be profile-specific,- use with unsupported profile raises an error.
As long as you follow my comments from the review and fix the existing problems the first two tests should pass without the need of implementing anything additional.
The last test where maximum_speed
is provided to the cycling profile will probably require some additional logic. Take your time. Don't forget to add appropriate CUSTOM_KEYS
indicating the profiles for which maximum_speed
parameter is valid to the description in @ApiModelProperty
. This is important from the perspective of our auto-generated interactive documentation.
Cheers,
Andrzej
private final Weighting superWeighting; | ||
private final DecimalEncodedValue avSpeedEnc; | ||
private boolean calculateWeight; | ||
private double maxSpeed = ((AppConfig.getGlobal().getServiceParameter("routing.profiles.default_params","maximum_speed_lower_bound")) != 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.
Moving the validation of maximum_speed
upstream to RoutingProfileManager
has rendered both maximumSpeedLowerBound
and maxSpeed
obsolete. If the program execution arrives at this point it is already clear that maximum_speed
is above the threshold, so no need of checking this again, right? Please remove both fields from the class.
*/ | ||
|
||
public class MaximumSpeedCoreEdgeFilter implements EdgeFilter { | ||
private double maxSpeed = ((AppConfig.getGlobal().getServiceParameter("routing.profiles.default_params","maximum_speed_lower_bound")) != 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.
The introduction of maximumSpeedLowerBound
has made maxSpeed
redundant, so please remove the latter.
...g/heigit/ors/routing/graphhopper/extensions/edgefilters/core/MaximumSpeedCoreEdgeFilter.java
Outdated
Show resolved
Hide resolved
openrouteservice/src/main/java/org/heigit/ors/routing/RoutingRequest.java
Outdated
Show resolved
Hide resolved
openrouteservice/src/main/java/org/heigit/ors/routing/RoutingProfileManager.java
Outdated
Show resolved
Hide resolved
openrouteservice/src/main/java/org/heigit/ors/routing/RoutingProfileManager.java
Outdated
Show resolved
Hide resolved
I just checked my last commit and there the test is still passing. Did you change anything in your last commit? So I should make sure that maximum speed is only called in |
I've just double checked that with you latest commit e996df7
Yes, as discussed before the API parameter Cheers, |
…in profile specific parameter section, added error for use with unsupported profiles.
Just updated. Everything should be fine 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.
Looks good now, thanks for your contribution! I've fixed some minor outstanding glitches in my last commits.
Cheers,
Andrzej
Pull Request Checklist
Fixes #480.
Information about the changes
Examples and reasons for differences between live ORS routes and those generated from this pull request
Required changes to app.config (if applicable)