Low lvl API - Force curbsides

Developers
1

Hiyas,
I’ve implemented low level API and its currently processing at about half the time it takes using standard GH requests. I would like to implement forced curbsides in the low lvl API

Normally I would force curbsides in the GHRequest;
GHRequest request = new GHRequest(fLat, fLong, tLat, tLong).setProfile("van").setCurbsides(CURBSIDES).putHint(Parameters.Routing.FORCE_CURBSIDE, false);

Now when using low level API - I’m unsure how to force curbsides.
Does it have to be set in the algo?
BidirRoutingAlgorithm algo = new CHRoutingAlgorithmFactory(graph.getRoutingCHGraph("van"), queryGraph).createAlgo(new PMap());

Or the path?
Path path = algo.calcPath(fromSnap.getClosestNode(), toSnap.getClosestNode());

2

You need to use set the sourceOut/targetIn edge when calling algo.calcPath: graphhopper/BidirRoutingAlgorithm.java at e2d844309ac47395298e57b5aaa3e4086573a081 · graphhopper/graphhopper · GitHub

Btw what are you trying to achieve? Are you trying to make the routing faster? If using the low level API seems faster that is most likely only due to the fact that you are skipping the path post-processing like calculating instructions and path simplification. You can also disable them for the higher level API without dealing with the low level stuff directly.

3

Thanks.
I was already using the following on my requests.

request.putHint("instructions", false);
request.putHint("calc_points", false);

Are there additional fields that can be turned off?
Using the above standard routing takes 33-40 seconds

Using the way I used low level API 21-25 seconds.

Essentially I just want the quickest way to return distance and time between two points.

4

Ok if you already disabled calc_points and instructions I don’t know of any other options that you could use. But… this speed difference is rather unexpected. I will take a look, because that should not really be. Maybe you can also use a profiler to figure out where the additional time is spent? Are these long routes with many via points or just routes from between two points?

5

My testing is point to point relations only in urban areas. A to B, there are no A to B to C routes.
Typically distances aren’t greater than 20km per route but there is no cap.
A total datasize of 60,702 points.

Also to reduce some dataset size I have implemented a dynamic bounding box constraint to only build point to point relations with points within the bounding box. This is due to the nature of points being quite clustered and there being no long stretches of distance where there are no points (Urban centers)

image
image704×696 139 KB

image
image632×682 85.9 KB

Using this method I see the following results;
First run with no constraints, 177 seconds to process 859,329 distances.
Second run with constraints, 23 seconds to process 140,411 distances.

Adding the bounding box check adds 0.00001 second per request.

Time (sec) Calculations Time per calc
No constraints
15 100000 0.00015
With constraints check
23 140411 0.00016

I’m currently taking an iterative approach to implementing speed improvements to my project as this is only a small component overall. There is bound to be better ways of calculating these distances and times but it enables me to quickly release a stable version while working on more chunky bits.