GraphHopper.com | Forum | GitHub | Maps | Blog

How to understand the function handlePriority in the FootFlagEncoder


#1

I am looking into the source codes for both the FootFlagEncoder and the HikeFlagEncoder and I found the main difference located in two places:

  1. FootFlagEncoder won’t take ways with a higher “sac_scale”;
  2. the function handlePriority is different.

It is difficult for me to understand the feature of the handlePriority function and how would it affect the FootFlagEncoder and the HikeFlageEncoder.

Thanks if anyone can give any instructions on this.


How to set higher priority for routes with certain tags
#2

‘hike’ has priorities more like a tourist preferring potential longer roads but ‘better’. ‘foot’ is more straight but still tries to avoid dangerous paths and also rejects extreme hiking stuff.


#3

Hi, Karussell, thanks for your answer. I understand the difference between the purposes of the “foot” and “hike”. The thing that I am not clear with is how these purposes are achieved. More specifically, how to understand the function protected int handlePriority(ReaderWay way, int priorityFromRelation) as well as the function void collect(ReaderWay way, TreeMap<Double, Integer> weightToPrioMap). What is the purpose of weightToPrioMap and what does the 100d mean for weightToPrioMap.put(100d, PREFER.getValue())


#4

Defining priority is a complicated process and making this process extendable is even more challenging. So we use the weightToPrioMap to achieve this and let others put a higher ‘weight’ (associated with a priority) that overwrites previously defined weights (with priorities). As the last step we just pick the priority with the highest ‘weight’:

// pick priority with biggest order value
return weightToPrioMap.lastEntry().getValue();

#5

Thanks for your reply.
Actually, I would like to create a navigation system for a park based on Graphhopper. There are two types of routes inside the park with Tag A and Tag B. I would like to set Tag A route with higher priority compared with Tag B route. But after going through the codes, I still donot know how to achieve this? Could you give me some suggestions?


#6

I have tried to set higher priority for some types of routes, but it seems like the priority is not working. Example as below:

I am moving from point 1 to point 2 and there are two ways. The first way is directly walking from 1 to 2 and the second way is walking from 1 to 3 and followed by walking from 3 to 2.
I have set the following priority:

  1. path (1->2) to 1 (AVOID_AT_ALL_COSTS )
  2. path (1->3) and path (3->2) to 7 (BEST)

Therefore, the final navigation from point 1 to 2 should follow the path 1->3 and 3->2. However, the simulation result is still by 1->2. Will there be anything wrong with my settings? I am using foot flag encoder together with fastest weighting


#7

How did you set the priority for the edge?

When you use fastest weighting - make sure the PriorityWeighting is picked and if it is already picked you could increase the difference between lowest and highest priority to fit your needs.


#8

I am sure the PriorityWeighting is picked.
The setting I gave for priority is:


path (1->2) has the tag of “highway” = “steps”
path (1->3) and path (3->2) has the tag of “highway” = “footway”

This is the biggest gap that I can give based on the priority value given.
The start location is (1.25388,103.819041) and the end location is (1.253926,103.818828).
Could you help to verify on this issue? Appreciate!


#9

You can increase how this integer gap is converted into an actual ‘weight gap’. For that you create a custom PriorityWeighting with a different formula.


#10

Could you specify more clearly on how to give a different formula for the actual ‘weight gap’?


#11

Try e.g. multiplying the formula in calcWeight by 10 or similar


#12

Is the weight only used for choosing the optimal path?
Will it affect the time calculation?


#13

I tried to multiply by 1000:


but it is still not working.


#14

Yes

Will it affect the time calculation?

No

but it is still not working.

if weight(path (1->2)) > weight (path (1->3) + path (3->2)) then 1->3->2 will be chosen. You’ll have to debug it


#15

Is it the other way around?


#16

No. The smallest sum is chosen.


#18

Sorry for hijacking this thread here… but hike is not one of the supported profiles, is it? At least in my config it’s not listed as possible value and using it won’t work?!?


#19

It is. If you add it to the graph.flag_encoders list before the import it will work.