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

Feature#480 maximum speed #740

Merged
merged 47 commits into from
Jun 24, 2020
Merged

Feature#480 maximum speed #740

merged 47 commits into from
Jun 24, 2020

Conversation

star-pirate
Copy link
Contributor

@star-pirate star-pirate commented Jun 3, 2020

Pull Request Checklist

  • 1. I have rebased the latest version of the master branch into my feature branch and all conflicts have been resolved.
  • 2. I have added information about the change/addition to functionality to the CHANGELOG.md file under the [Unreleased] heading.
  • 3. I have documented my code using JDocs tags.
  • 4. I have removed unnecessary commented out code, imports and System.out.println statements.
  • 5. I have written JUnit tests for any new methods/classes and ensured that they pass.
  • 6. I have created API tests for any new functionality exposed to the API.
  • 7. If changes/additions are made to the app.config file, I have added these to the app.config wiki page on github along with a short description of what it is for, and documented this in the Pull Request (below).
  • 8. I have built graphs with my code of the Heidelberg.osm.gz file and run the api-tests with all test passing
  • 9. I have referenced the Issue Number in the Pull Request (if the changes were from an issue).
  • 10. For new features or changes involving building of graphs, I have tested on a larger dataset (at least Germany) and the graphs build without problems (i.e. no out-of-memory errors).
  • 11. For new features or changes involving the graphbuilding process (i.e. changing encoders, updating the importer etc.), I have generated longer distance routes for the affected profiles with different options (avoid features, max weight etc.) and compared these with the routes of the same parameters and start/end points generated from the current live ORS. If there are differences then the reasoning for these MUST be documented in the pull request.
  • 12. I have written in the Pull Request information about the changes made including their intended usage and why the change was needed.

Fixes #480.

Information about the changes

Examples and reasons for differences between live ORS routes and those generated from this pull request

  • Added the option to compute routes using a maximum speed as a parameter/weighting.

Required changes to app.config (if applicable)

  • Addition of maximum_speed for the appropriate inclusion of edges in the core.

star-pirate and others added 30 commits December 24, 2019 14:03
…mumSpeedWeighting in the development branch.
…ighting in ORSGraphhopper and ORSWeightingFactory.
Copy link
Member

@aoles aoles left a 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!

@star-pirate star-pirate requested a review from aoles June 4, 2020 13:03
Copy link
Member

@aoles aoles left a 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!

*/

public class MaximumSpeedCoreEdgeFilter implements EdgeFilter {
private double maxSpeed = ((AppConfig.getGlobal().getServiceParameter("routing.profiles.default_params","maximum_speed_lower_bound")) != null)
Copy link
Member

@aoles aoles Jun 4, 2020

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.

Copy link
Member

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.

Copy link
Member

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

@aoles aoles Jun 4, 2020

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which HintsMap exactly?

Copy link
Member

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.

Copy link
Contributor Author

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?

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 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?

Copy link
Member

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.

@star-pirate star-pirate requested a review from aoles June 5, 2020 16:14
Copy link
Member

@aoles aoles left a 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)
Copy link
Member

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

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.

@star-pirate
Copy link
Contributor Author

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

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 car-ors and driving-hgv ?

@aoles
Copy link
Member

aoles commented Jun 15, 2020

I just checked my last commit and there the test is still passing. Did you change anything in your last commit?

I've just double checked that with you latest commit e996df7 ResultTest.testMaximumSpeed fails, so maybe you had some local changes which you forgot to commit?

So I should make sure that maximum speed is only called in car-ors and driving-hgv ?

Yes, as discussed before the API parameter maximum_speed should be valid only for these two driving profiles.

Cheers,
Andrzej

…in profile specific parameter section, added error for use with unsupported profiles.
@star-pirate
Copy link
Contributor Author

I just checked my last commit and there the test is still passing. Did you change anything in your last commit?

I've just double checked that with you latest commit e996df7 ResultTest.testMaximumSpeed fails, so maybe you had some local changes which you forgot to commit?

So I should make sure that maximum speed is only called in car-ors and driving-hgv ?

Yes, as discussed before the API parameter maximum_speed should be valid only for these two driving profiles.

Cheers,
Andrzej

Just updated. Everything should be fine now.

@star-pirate star-pirate requested a review from aoles June 17, 2020 11:27
Copy link
Member

@aoles aoles left a 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

@aoles aoles removed the request for review from HendrikLeuschner June 24, 2020 09:18
@takb takb merged commit b9e94ed into master Jun 24, 2020
@takb takb deleted the feature#480-maximum_speed branch June 24, 2020 10:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

User adjustable speed capping
4 participants