I think a simple workaround for such ‘conditional’ use-cases should be doing some kind of pre-processing: Process all roads and add some custom tag depending on other tags (like surface+road_class) and then use this new custom tag in the custom weighting. Maybe we should make this process more accessible/easier and keep the ‘scripting/custom weighting’ simple.
No, commiting to master does not add the change to an already existing version/jar (like 1.0), but the change will be included in the next (pre)release, the last one of which was on july 17th: Releases · graphhopper/graphhopper · GitHub
1 Like
@plotaroute there is now a new branch in a good shape that allows you to define more complex conditions like:
priority:
road_class == UNCLASSIFIED && surface != PAVED: 0.5
road_class == LIVING_STREET && (surface != PAVED || surface == OTHER): 0.3
Here every statement will be evaluated and the values will be multiplied for priority.
Or something like an if-then-else-if flow where only one value is picked:
priority:
first_match:
road_class == PRIMARY || road_class == SECONDARY: 1.0
surface == UNPAVED: 0
It is slightly more verbose but much more powerful and readable IMO. Let me know what you think. For a migration guide there is currently only the examples and the changed profiles.md documentation in the branch.
2 Likes
Wow, that sounds great - thanks. Looks really flexible. We’re deeply tied up with another project at the moment but will have a look at it when we get chance.
@karussell We’ve got a bit of time now to try out the new conditional priorities. However, I’m a bit unclear what we need to download in order to access it. We use the Map Matching build, as we need a .jar file that has both the route and match endpoints - is the new conditional priority feature available in a Map Matching build?
You clone the repository, checkout the janino_scripting branch and build the jar file e.g. via mvn clean install.
Please note that the syntax of this new feature has further evolved and is described in the initial comment of this pull request. E.g. speed_factor and max_speed was merged and instead of first_match there are now statements with if, else and else if.
btw: the map matching service is now already included in the same repository so no more hassle like you had in Recent Core Build Fails
btw2: currently map matching does not support custom profiles per-request - only if defined on the server-side, but I guess this is sufficient for your needs as this was always the case.
Thanks. I’ve downloaded the janino_scripting branch and have successfully built a new jar file. This runs OK with a simple config file and I can see it also has the match endpoint now, which is great.
I’ll need to convert my custom profile files to the new format before testing. Is the plan for the Janino format to become a permanent new format for custom profiles in future releases or is this just experimental?
As noted in our blog and in the documentation the format always was considered alpha state. Now the plan is to make it production grade after the next 3.0 release (in March or April) but it could take another release (in September or October) to find & fix all problems with that format.
And before that 3.0 release the format might also change. But also here I guess the changes will be small if at all.
Thanks, its a good idea to get used to the new format now then!
I’ve been trying it out but have come across a problem. Is there a limit on the number of conditions you can have in a single if statement? It seems to fail when there are more than 4.
The following example fails with an error saying it cannot compile the expression:
priority:
- if: surface == PAVING_STONES || surface == COBBLESTONE || surface == UNPAVED || surface == GRAVEL || surface == FINE_GRAVEL
multiply by: 0
But the following example works:
priority:
- if: surface == PAVING_STONES || surface == COBBLESTONE || surface == UNPAVED || surface == GRAVEL
multiply by: 0Can reproduce the problem and fixed it. The problem was indeed that it was too long, but this limit is a bit too tight.
Thanks for the quick fix. I’ll download the new version and try it out. We actually need 10 conditions in the if statement to cover all the surface values we want to exclude - will the new limit cope with that?
Yes, the new limit is regarding the overall script size and should allow many single expressions 
I’ve done some testing and all was going OK, but I’ve hit another snag. Building the graph with the latest a whole world PBF file fails with the following error:
ERROR com.graphhopper.reader.osm.OSMReader - Coul
dn't properly add edge with osm ids:[2079122377, 6709044287, 6709044286, 6297662
809, 6297662810, 6297662811, 6297662815, 6297662816, 6297662817, 6297662818, 629
7662819, 6297662820, 6297662821, 6297662822, 6297662823, 6297662824, 6297662825,
6297662826, 6297662827, 7122190335]
java.lang.IllegalStateException: Suspicious distance for edge: 281672234 7617409
5-188783283 2147483.646 vs. 2797459.9022160647, difference: -649976.2562160646
at com.graphhopper.reader.osm.OSMReader.checkDistance(OSMReader.java:738
)
at com.graphhopper.reader.osm.OSMReader.addEdge(OSMReader.java:722)
at com.graphhopper.reader.osm.OSMReader.addOSMWay(OSMReader.java:657)I added this check/error recently. Which file exactly did you try to import? Will have to investigate this. The distances look very wrong: 2147483.646 is just Integer.MAX_VALUE/1000 it seems (two million kilometres meters (=2147km, maybe a long ferry?)). For now can you just comment out this check in OSMReader?
This was the file: https://planet.openstreetmap.org/pbf/planet-latest.osm.pbf
I don’t have the Java expertise to modify the code, so I’ll need to hang on until you have a fix for this.
Can you try this commit? https://github.com/graphhopper/graphhopper/commit/e1cd19df0e91602a724998967cb87d58263219a9 I just changed the error into a warning.
Assuming you cloned the graphhopper repository you just need to either pull the janino_scripting branch again or clone it again and run git checkout janino_scripting.
There now might be a few warnings in the log (instead of the error you saw) like this:
Very long edge detected 281672234 7617409...
It would be of great help if you could paste these here in case they show up when you try again. Otherwise I will try myself.
Thanks. I’ll have a look at it tomorrow and post the warnings you referred to.
1 Like
Quick update - the graph build has been running for 24 hours so far but no sign of the warnings you mentioned.
The graph generation finished OK and I didn’t see any of the warning messages you mentioned.
I’m also pleased to report that it took less than half the time to generate the graph as it did with version 2, so the changes you made to speed up CH preparation have certainly made a huge difference.
1 Like
Hi there @easbar ,
I would like to do the same as you recommended to @Dylansc to modify the RoadClass.java file to add additional tags. Can I add tags that contain integer values to RoadClass.java?
I would like to assign priorities in the custom_model_file to two tags called “routing_priority” and “speedclass”. “routing_priority” = 0 - 4, and “speedclass” = 0 - 7.
I look forward to some suggestions, thanks in advance!