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.

Sign up for GitHub

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

Jump to bottom

Rebase road property speeds #1225

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from
Draft

Rebase road property speeds #1225

wants to merge 7 commits into from

Conversation

TheGreatRefrigerator
Copy link
Contributor

@TheGreatRefrigerator TheGreatRefrigerator commented Oct 25, 2022 •
edited

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 ors-config.json file, I have added these to the ors config documentation
    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.
  • 13. For changes touching the API documentation, I have tested that the API playground renders correctly.

Fixes # .

Information about the changes

  • Key functionality added:
  • Reason for change:

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

Required changes to ors config (if applicable)

@takb takb added this to To do in ors general Oct 25, 2022
TheGreatRefrigerator
TheGreatRefrigerator commented Nov 2, 2022
View reviewed changes
...routeservice/src/main/java/org/heigit/ors/routing/graphhopper/extensions/ORSGraphHopper.java Outdated
Comment on lines 353 to 356
AbstractSpeedCalculatorWeighting weighting1 = (AbstractSpeedCalculatorWeighting) weighting;
if (weighting1.getSpeedCalculator() instanceof RoadPropertySpeedCalculator) {
((RoadPropertySpeedCalculator) weighting1.getSpeedCalculator()).setRoadPropertySpeedMap((RoadPropertySpeedMap) ((ORSPMap) request.getAdditionalHints()).getObj("user_speeds"));
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

i've also changed weigthing1 to weighting here but without any difference.
Not sure which one is correct but i assume weighting. Probably was used to switch between the different weightings locally?

@aoles
Copy link
Member

aoles commented Nov 2, 2022 •
edited

After a quick look it seems to me that you are trying to re-implement the idea of using a speed calculator within the weightings. However, this concept has been established in the GH fork and in the ORS codebase already a while ago in GIScience/graphhopper@68a5fa7 and ea68ed4, 535d6ca, respectively. This change was primary implemented to deal with traffic-dependent speeds or time-dependent speed limits.

Could it be that some of your code is just obsolete and is not integrating well with the existing functionality? Note that as currently any given weighting has an interface to hook-up a speed calculator, it should be enough just to define your new calculators and plug them in into any of the existing weightings such as with MaximumSpeedCalculator or RoutingTrafficSpeedCalculator without the need of any dedicated weightings. Depending on whether you would like to have a default fallback speed calculator in the back you might actually want to extend the AbstractAdjustedSpeedCalculator.

@takb takb moved this from To do to Review in ors general Nov 3, 2022
@koebi
Copy link
Collaborator

koebi commented Nov 3, 2022

Hey,
great finds!!
Turns out, "a while ago" (i.e. May/June 21) is indeed after the above changes have been implemented, which was before February 21.

Yeah, I'd assume that rewriting this to use the existing mechanism makes sense - however, I'm a bit confused since the code actually looks like it is doing that?

@aoles aoles marked this pull request as ready for review November 4, 2022 13:53
@TheGreatRefrigerator TheGreatRefrigerator self-assigned this Nov 7, 2022
HendrikLeuschner and others added 6 commits November 8, 2022 14:58
@HendrikLeuschner @TheGreatRefrigerator
Reimplement Properties as enums
1db3ac8 
move to switch statements for readability
@TheGreatRefrigerator @HendrikLeuschner @aoles
feat: Add road property speed limits
6760a8e 
- Add API Parameter 'user_speed_limits' to specify speed limits for road and surface types
- Add RoadPropertySpeedCalculator, ~Map and ~Parser
- Use custom speeds to adjust weighting in ORSGraphHopper.js
- Add RoadPropertySpeedMap to RouteSearchParameters

- Fix hasTimeDependentSpeedOrAccess variable casing

Co-authored-by: Hendrik Leuschner <hendrik@openrouteservice.org>
Co-authored-by: aoles <andrzej.oles@gmail.com>
@aoles @TheGreatRefrigerator
Compare scaled speed values
5427ee1 
Speed values stored on egdes are already scaled by a factor of 0.9. In order to reliably override them by user-provided values the latter ones need to be scaled as well before doing the comparison.
@TheGreatRefrigerator @HendrikLeuschner
tests: Add RoadPropertyTest
17114af 
Co-authored-by: Hendrik Leuschner <hendrik@openrouteservice.org>
@koebi @TheGreatRefrigerator
feat: enhance RoadPropertySpeedParser
357fe82 
- add handling of unknown key
- throw StatusCodeException on validation error
@TheGreatRefrigerator @koebi
tests: Add user_speed_limits test
747475f 
adds parameter and result tests for custom speeds

Co-authored-by: koebi <koebi@ezelo.de>
@TheGreatRefrigerator
Copy link
Contributor Author

I've force pushed(no diff) some squashing and restructuring of the commits so the review will be less of a torture.

But maybe @aoles and @koebi you can take a quick look through the commits if it makes sense to you.

What's left to do is:

@MichaelsJP MichaelsJP marked this pull request as draft March 2, 2023 10:57
@MichaelsJP MichaelsJP added this to the Release 7.0.1 milestone Mar 2, 2023
@MichaelsJP MichaelsJP removed this from the Release 7.0.1 milestone Mar 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@koebi koebi Awaiting requested review from koebi

At least 1 approving review is required to merge this pull request.

Assignees

@TheGreatRefrigerator TheGreatRefrigerator

Labels
None yet
Projects
ors general
  
Review
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
5 participants
@TheGreatRefrigerator @aoles @koebi @MichaelsJP @HendrikLeuschner