-
Notifications
You must be signed in to change notification settings - Fork 403
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
base: main
Are you sure you want to change the base?
Conversation
a2d7dd1
to
d0235a5
Compare
AbstractSpeedCalculatorWeighting weighting1 = (AbstractSpeedCalculatorWeighting) weighting; | ||
if (weighting1.getSpeedCalculator() instanceof RoadPropertySpeedCalculator) { | ||
((RoadPropertySpeedCalculator) weighting1.getSpeedCalculator()).setRoadPropertySpeedMap((RoadPropertySpeedMap) ((ORSPMap) request.getAdditionalHints()).getObj("user_speeds")); | ||
} |
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'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?
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 |
Hey, 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? |
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]>
14f42d0
to
747475f
Compare
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:
|
@TheGreatRefrigerator Could you please remind me, what this PR was trying to address? 🧐 |
Dynamic passing of speedlimits directly to the request it seems |
Thanks @TheGreatRefrigerator ! @MichaelsJP any thoughts how to deal with this? Unless we want to merge, I would propose to close the PR 💀 |
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. |
@TheGreatRefrigerator Where does this come from though: was it an internal/external project, and does any documentation of it exist outside of this thread? 🤔 |
Pull Request Checklist
have been resolved.
[Unreleased] heading.
along with a short description of what it is for, and documented this in the Pull Request (below).
(at least Germany), and the graphs build without problems (i.e. no out-of-memory errors).
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.
and why the change was needed.
Fixes # .
Information about the changes
Examples and reasons for differences between live ORS routes, and those generated from this pull request
Required changes to ors config (if applicable)