I used to use some special file to get lower speed in some areas but I decided to change it for custom areas in my config file. I made some areas with speed and I tested it. Custom areas are low efficient - it takes more time to route. I’m not sure exactly why… Aren’t they taken only during creating a graph ? Or also during the routing ? I mean, it should take more time during creating a graph, but routing the same time? Could someone explain how does it work and where it is used?
Without an example I can only guess what you mean 
But let’s try … and say you have two profiles in your config.yml:
profiles:
- name: car
vehicle: car
weighting: custom
custom_model:
distance_influence: 0
- name: custom_car
vehicle: car
weighting: custom
custom_model:
distance_influence: 0
speed:
- if: true
limit_to: 40
- profiles_lm:
- profile: car
- profile: custom_car
The query speed with profile=car is “normally fast” and when you specify a custom_model like e.g. {"speed":[{"if": "true", "limit_to": 40}]} this query speed will get slower, especially for longer routes >500km. (btw: you can achieve much better performance if you avoid residential roads).
Now when you specify profile=custom_car it usually has the same “normal fast” query speed as the profile=car above and that although the custom_model is included for custom_car! This is due to the fact that the custom_model of custom_car is already known to the LM preparation and so this prepared data can be optimized according to the custom_model too.
Now you could even enable CH preparation for custom_car and this will improve query speed even more (by an order of magnitude), but you’ll loose the per-request customization possibility and the preparation might take longer. See also this blog post.
Please also note that if you want to compare the query speed of weighting: fastest with a custom weighting you should use distance_influence: 0 for the custom_model as the default is distance_influence: 70 and might be slightly slower. But we picked this as a new default as the routing quality is usually better.
I think the witnessed slowdown with custom areas is due to the fact that we need to create a BBox instance for each visited edge and also load the full way geometry for potentially intersecting ones if they’re not a rectangle:
thank you for the response but I meant sth like in the comment below I have one profile, and I made areas (polygones), I slowed down the speed in that areas but it is less efficient than my previous solution - file with route ids and factors (and a few changes in the code). I wonder why ? I thought that after building the graph, the time of the response would be the same but it is slower with the custom area solution and I only want to know why, how does it work that it is slower or how the GH uses that areas after building the graph
thanks I’ll check it
You mean you excluded some roads based on their edge IDs instead of using areas?
I thought that after building the graph, the time of the response would be the same but it is slower with the custom area solution
What exactly are you comparing here? If you compare e.g. a CH profile with a custom_model to your previous solution there should not be a big difference. If yes, then we would need a simple test case to recreate this problem for us.
And if you compare the LM query times, then yes, it might be the problem that a geometric area check is much more computing intense than an ID comparison (even without the fact that @otbutz mentioned)
The legacy approach for this is using the block_area parameter - maybe you can find examples where the custom models with areas are slower than this legacy approach?
Because in this legacy approach we have a case that initially pulls the edge IDs and uses them while routing: https://github.com/graphhopper/graphhopper/blob/master/core/src/main/java/com/graphhopper/storage/GraphEdgeIdFinder.java#L154
We could introduced this optimization for the custom_model too if the benefits are big enough.
@otbutz do you know if we have an issue for this bbox caching in wayGeometry that I mentioned here? Cache tower node bbox in EdgeIteratorState by otbutz · Pull Request #2338 · graphhopper/graphhopper · GitHub
There isn’t so big difference but I’ve tested times frem the file with 1500 lokalization x 2000times and i’ve took the averages. The average from area is about few seconds bigger than from my previous system. But it may be caused, as you told, by a geometric area check is much more computing intense than an ID comparison.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.