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

Rebase road property speeds #1225

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

Conversation

TheGreatRefrigerator
Copy link
Contributor

@TheGreatRefrigerator TheGreatRefrigerator commented Oct 25, 2022

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)

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

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.

@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
move to switch statements for readability
- 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 <[email protected]>
Co-authored-by: aoles <[email protected]>
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.
Co-authored-by: Hendrik Leuschner <[email protected]>
- add handling of unknown key
- throw StatusCodeException on validation error
adds parameter and result tests for custom speeds

Co-authored-by: koebi <[email protected]>
@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
@aoles
Copy link
Member

aoles commented Oct 1, 2024

@TheGreatRefrigerator Could you please remind me, what this PR was trying to address? 🧐

@TheGreatRefrigerator
Copy link
Contributor Author

@TheGreatRefrigerator Could you please remind me, what this PR was trying to address? 🧐

Dynamic passing of speedlimits directly to the request it seems

@aoles
Copy link
Member

aoles commented Oct 1, 2024

Thanks @TheGreatRefrigerator !

@MichaelsJP any thoughts how to deal with this? Unless we want to merge, I would propose to close the PR 💀

@MichaelsJP
Copy link
Member

Some explanation on this would have been good. @TheGreatRefrigerator is this still needed?

@TheGreatRefrigerator
Copy link
Contributor Author

Some explanation on this would have been good. @TheGreatRefrigerator is this still needed?

Well, it would be one of the easiest ways for users to direclty adjust speeds, which makes adjustments for different countries a lot easier, than setting up ors and adjusting speed limits.

@aoles
Copy link
Member

aoles commented Oct 2, 2024

@TheGreatRefrigerator Where does this come from though: was it an internal/external project, and does any documentation of it exist outside of this thread? 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants