GraphHopper.com | Forum | GitHub | Maps | Blog

Questions for developing with graphhoper open source


#1

Hello all of you,

I just wanted to ask some question after looking into your documentation :slight_smile:
We develop some local routing for our planning algorithm and use your software for the routing. So I have to make some adjustments and have some questions after looking into your documentation.

I hope you can help me, just to clarify some things :slight_smile:

  1. In Routing via Java API is a section about alternative routes. It is described to only work with flexible mode. Is the speed mode only calculating one route per request or is it also possible to use with the speedmode or hybrid mode for it?

  2. As I see in TruckFlagEncoder in Core the TruckFlagEncoder isn’t in the core version at the moment. So we have to create our own. I’m relativly new to graphhopper. Is there any update to it or do you have plans to publish the TruckflagEncoder in the near future? :slight_smile: Can you also give me some hints, what I have to look for or where I have to investigate more time into to do it properly? For example: If i’m adding “hgv=yes” as a restriction, a truck can’t use streets which have “hgv=yes” as a tag in germary, am i right? :slight_smile:

  3. We want to calculate toll distance and later toll costs. I found Toll Cost and Distance Calculation.
    If i’m understanding it the right way: If I add some new EncodedValue to my TruckFlagEncoder like “tollEncoder” (which saves a boolean flag for example) and set it to true each time the “toll=yes” flag is present? Later in the response I somehow can get to this values to get the distance and calculate the costs of it? :slight_smile:

  4. Which version do you would suggest to use? The latest unstable or the 0.9.0 stable? I’m tending to the stable version.

The questions are long, but I hope they are understandable.

Thank you for your help in advance.

Best wishes,
Martin


#2

Hi Martin,

interesting questions.

Alternative routes should work with flexible and hybrid mode, but not speed mode. I will have a look at the docs and update them, thanks.

Why would you forbid hgv=yes? Anyway, restrictions work together with the restrictedValues and intendedValues, but you can change all that in your custom encoder.

Yes, you can also have a look at PathDetails for calculating this.

Unless you need any features developed after the release of 0.9.0, sticking with major releases is probably better, in between versions things might change.

Cheers,
Robin


#3

Regarding the truck stuff (weight&height restrictions) also have a look into the DataFlagEncoder


#4

First thank you for your quick answers :slight_smile:

So i’m understanding it wrong? :slight_smile: I have to add hgv=no to the restrictions, so an truck can’t use streets which he is not allowed to drive? As of OSM hgv I understood it like: A road is hgv=yes if the traffic sign on the right is present on the street. So a truck with more than 3,5t is not allowed to use it.

As it looks like, PathDetails are implemented after 0.9.0. But thanks for the help :slight_smile:

As I thought. PathDetails would be one of the things, why it could be good to switch to a newer version.

Thanks for your help :slight_smile:

Edit: Question about Weighting irrelevant, found out myself.

So I just have another question :slight_smile:

I created a new weighting which has 20% distance and 80% time weighting.
My weighting looks like this:

public class MyWeighting extends FastestWeighting {

	private final static double TIME_WEIGHTING = 0.8;
	private final static double DISTANCE_WEIGHTING = 0.2;

	public MyWeighting(FlagEncoder encoder, PMap map) {
		super(encoder, map);
	}

	public MyWeighting(FlagEncoder encoder) {
		this(encoder, new HintsMap(0));
	}

	@Override
	public double getMinWeight(double distanceInMeter) {
		double timeInSecondsWeightingPart = super.getMinWeight(distanceInMeter) * TIME_WEIGHTING;
		double distanceInMeterWeightingPart = distanceInMeter * DISTANCE_WEIGHTING;
		return distanceInMeterWeightingPart + timeInSecondsWeightingPart;
	}

	@Override
	public double calcWeight(EdgeIteratorState edge, boolean reverse, int prevOrNextEdgeId) {
		double timeInSecondsWeightingPart = super.calcWeight(edge, reverse, prevOrNextEdgeId) * TIME_WEIGHTING;
		double distanceInMeterWeightingPart = edge.getDistance() * DISTANCE_WEIGHTING;
		return distanceInMeterWeightingPart + timeInSecondsWeightingPart;
	}

	@Override
	public String getName() {
		return "myweighting";
	}
}

I had the idea of calculating the weight of distanceInMeter/timeInSeconds, so each edge has a m/s cost and it discribes a nice value for a street. My idea was “a street is better, if you can drive through it with more meters per second”. For some reason it fails to find a path (example was from Berlin to Munich). Do you have any idea why? With the addition it works fine :slight_smile:

Edit: One logical error in it also. A street is better in the meanings of weighting, if you have lower m/s.

Cheers,
Martin


#5

Hi Martin,

Yes :).

The current master works well, so if you want to use PathDetails, use it.

Please have a look at the ShortFastestWeighting, this looks pretty much the same. BTW: It might be easier for you to use the ShortFastestWeighting with the hosted TruckProfile via the Directions API then :).

Do you get a route when using the ShortestWeighting or FastestWeighting?

Cheers,
Robin


#6

Hi Robin,

sorry for the late answer. I was not at my pc on my weekend. I hope you had a nice weekend.

Problem is we are using maven and save no local sources in our repository. So we could only use the versions in maven. I think I will try to use the Encoder-Method for it :slight_smile:

Ah I looked into it and it looks the same, yes :slight_smile: I’m getting an result with addition in my weighting :slight_smile: Just throught addition isn’t good, but after thinking about it division doesn’t make any sense because better streets would have a bigger weight.:smiley:
Also thanks for the suggestion, but we try to use automation for planning of jobs and that could produce thousands of requests on “bigger” problems. So that’s out of the question, sorry.

Edit: Question clear.

Does a path have all edges in it or do I have to add some edges myself manually?

Cheers,
Martin


#7

Hi Martin,

thanks I had a good weekend, I hope you had a good one as well :).

Have a look at our documentation :).

Yes, look at how Instructions or PathDetails are created :).

Cheers,
Robin


#8

Hi Robin,

I also had a good one thanks :slight_smile: Week is very busy. Sorry for the late answer.

Oh okay, thanks. I overread it. :slight_smile: I just implemented it with a new EncodedValue :slight_smile:

But it raises another question. Is there any possibility to overcome the 64 Bit limitation for storing flags at the moment or do you have any other suggestions to minimize the bit space for storing the flags?

The scenario is:
We have multiple Flagencoders, which mostly change the maxspeed for cars: {90,100,110,120,130} and two for trucks: {30,80}. I created an TollFlagEncoder which extended the CarFlagEncoder and all other encoder should extend from TollFlagEncoder, but it seems like the toll bit is stored multiple times.
Is there any way to store it only ones? :slight_smile:
We also want to have all of the profiles prepared, because it would slow down the algorithm if the distance calculation takes more time.

If not, I just will implement it for our trucks, but I’m interessted :slight_smile:

Cheers and have a good day,
Martin


#9

Hi Martin,

AFAIK, not really, sorry.

I created an TollFlagEncoder which extended the CarFlagEncoder and all other encoder should extend from TollFlagEncoder, but it seems like the toll bit is stored multiple times.
Is there any way to store it only ones? :slight_smile:

We are currently working on this in this PR. Until then, it is only “hackable” but there is no nice way of doing this. Essentially everytime you create a new EncodedValue the bits get used. You can try setting up something like the DataFlagEncoder and use it alongside your current encoders.

Cheers,
Robin


#10

Is there any possibility to overcome the 64 Bit limitation for storing flags at the moment or do you have any other suggestions to minimize the bit space for storing the flags?

You can always store data in a separate array (DataAccess)


#11

Can you go a little bit deeper into it please? :slight_smile:


#12

As the node and edge IDs are consecutive you can store additionally information in an array while import and use this in your Weighting while routing.

The disadvantages of an array or ArrayList is that it does not grow nicely (if size does not fit you have to copy into a new, bigger array) also there is no efficient storing mechanism and if there is few RAM you cannot easily use memory mapping. For this you can use the GraphHopper-array called “DataAccess” e.g. new RAMDirectory().find(“xy”). The disadvantage there is a bit strange usage like the ensureCapacity but it doesn’t have the previous mentioned downsides.


#13

I have a question here about getMinWeight(double distance) of your ShortFastestWeighting class. Your minweight is only including the distance factor, but not the time factor. Why is that?
Or do you consider minimal weighting with time factor 1?

Also sorry for not replying, but I had my head in work the last weeks, sorry. Thanks for the help :slight_smile:


#14

Ah, interesting question. I think this might actually be an issue and this should be included in the calculations, WDYT @karussell?


#15

Ah, yes we might need to add timeFactor * distance / maxSpeed


#16

Also why is the minWeighting not specified as distance distance * distanceFactor + timeFactor * distance / maxSpeed like in the calcWeight method? Why is there another math behind it? :slight_smile:


#17

getMinWeight is for guessing the weight based on the distance, used for A* algorithm

calcWeight is for calculating the exact weight based on the known path, the speed and priorities etc. Used for all algorithms.


#18

But isn’t it inaccorrate because you use another calculation rule for guessing and the actual weight later?


#19

if you return 0 it is correct and so all values below the best minimum are correct (although suboptimal). So yes, a better minimum would be the proposed one and result in a better performance for this weighting, feel free to create an issue.
BTW: if too high values are return one could speed up the calculation further - you only risc getting suboptimal routes :wink:


#20

I just created a PR for the minWeight.