Turn cost and sharp turns

Open Source Routing Engine
1

In a vanilla graphopper (4.x) installation (ch - faster) I see this:

while the expected result is this one

as correclty shown in Driving Directions - GraphHopper Maps

if I enable “turn_costs=true” in config file for both encoder and profiles I obtain the expected behavior, I believe that’s because of a “straight on” relation in one of the ways.

Is there a way to prevent such ultra-sharp turn without enabling turn_costs ? (which emh… seems to cost a lot in term of memory)

Thanks

2

No, this is not possible when you need CH. If you do not need CH then you can enable turn_costs without the higher memory requirements.

btw: note, you can always switch from in-memory (RAM_STORE) to memory mapped (MMAP) and the memory requirements are a lot smaller. Although you have a bit slower requests.

2 Likes
3

thanks for the feedback, so I’ll test more with “turn_costs=true” to determine the extra RAM needed in my use cases.

4

btw: instead of CH you can also use LM preparations which can be a bit slower (but this really depends on your config) but you do not need extra memory when you enable turn_costs
btw: see my added btw above too :wink:

1 Like
5

Note that you can also run the import and CH preparation on a computer with more memory (and using MMAP to reduce the memory requirements), and then use the imported data on a computer with less memory to start the GraphHopper server. See e.g. this discussion: Out of Memory when loading US map when Turn Costs enabled - #6 by drmojo

1 Like
6

Yep, thanks - this is exactly what I am doing.

But I encounter an issue when importing full Europe (2 profiles, CH with turn cost on, graphhopper 4.x) on a 16GB (aws t3.xlarge) server in MMAP data access. No errors but after several hours with high CPU usage, CPU went down at <1% (assume all was IO) - and after 7 hours of no progresses I gave up and fired up a 32GB server (aws r5a.xlarge).

I could then run successfully all Eur import by setting java to 28GB (-Xmx28000m -Xms28000m) even with graph.dataaccess to RAM_STORE (in about 20 hours).

For comparison, although not too meaningful since CPU differs, in a 16GB (aws t3.xlarge) server I was able to import all Europe in MMAP mode (graphhopper 0.13, so no turn costs) in about 10:30 hours.

7

That seems a bit slow, but could be due to the slower CPU(?), or you were close to the memory limit and the import ran slow because there was a lot of GC activity

I think you were able to do this on the 16GB machine using 0.13, because back then the memory requirements were lower. Still, if there was enough memory using 4.x should be much faster than using 0.13.

8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.