I am relatively new to GraphHopper, but I started using it successfully for a new application.
This application usually requires multiple (>10 000) and fast (few secs max for all) foot-profile routings and uses the low-level Java API.
From the documentation, this forum, and examples I built a running code using CH + turn_costs=true.
I would need few clarifications please:
Is CH + turn_costs=true really the fastest configuration (with the known Ram constraint)?
Can we directly get an encoded polyline from a GHResponse (similar to points_encoded=true with the GH API), or do we have to use first GHResponse.getBest().getPoints() and then encodePolyline() ?
Many of my route start points are known and often reused, could I avoid snapping them to the network systematically (for example snapping them once, and then use the related way points as inputs) ?
Is CH + turn_costs=true really the fastest configuration (with the known Ram constraint)?
Yes, unless you don’t need turn costs. Otherwise not using turn costs will give you a faster response. May I ask why you use turn_costs=true (for the foot profile)?
Another thing that could speed up the queries is disabling instructions (instructions=false)
Can we directly get an encoded polyline from a GHResponse (similar to points_encoded=true with the GH API), or do we have to use first GHResponse.getBest().getPoints() and then encodePolyline() ?
In theory yes you could build an encoded polyline without creating a point list first and that could be a little faster, but honestly I doubt it. You would have to write new Java code for this though (nothing like this is implemented currently). Also this assumes that you even need the poly line. If you only needed the distance for each route you could disable the path calculation altogether using calc_points=false. Maybe you want to try this anyway to see how much the path calculation adds to your overall routing time.
Many of my route start points are known and often reused, could I avoid snapping them to the network systematically (for example snapping them once, and then use the related way points as inputs) ?
Yes, you could introduce some kind of simple snapping which checks if a query point is a known location for which you already know where to snap. Whether this will be faster probably depends on the number of these known locations, and also not sure if this will really speed up the overall routing time.
Yes, unless you don’t need turn costs. Otherwise not using turn costs will give you a faster response. May I ask why you use turn_costs=true (for the foot profile)?
Sorry this is a mistake: I wanted to write “CH + turn_costs=false”, this is what I use, and so we are aligned.
In theory yes you could build an encoded polyline without creating a point list first and that could be a little faster, but honestly I doubt it. You would have to write new Java code for this though (nothing like this is implemented currently). Also this assumes that you even need the poly line. If you only needed the distance for each route you could disable the path calculation altogether using calc_points=false . Maybe you want to try this anyway to see how much the path calculation adds to your overall routing time.
Thank you for the clarification and proposal. Indeed using calc_points=false provides in my case a x1.31 gain.
Yes, you could introduce some kind of simple snapping which checks if a query point is a known location for which you already know where to snap. Whether this will be faster probably depends on the number of these known locations, and also not sure if this will really speed up the overall routing time.
Ok, so I would need to demonstrate a possible gain here. Would you know please the part of the GH code where this snapping is made? I have globally a difficulty to navigate and understand the code.
I think you could try to put your own LocationIndex implementation into the GraphHopper object. Something that does the faster lookup you envisioned for certain locations and delegates to the built-in location index otherwise. But you’ll need to read the code that initializes/sets the location index in GraphHopper.java carefully to make sure your instance actually ends up being used when the actual routing calculation starts later on (not sure if anybody tried doing something like this yet).
