Sometimes it can be helpful to have a weight limit instead of time or distance limit for isochrones.
For example think about a service that shows how far you can drive when spending 50€ in fuel and using a fuel estimation weighting.
WDYT? Should we add something like this to the Isochrone endpoint? The implementation is actually quite straight forward and seems like a nice feature.
The bigger question is: should we allow arbitrary units for Weighting.calcEdgeWeight?
I was long a supporter that we should support time and distance and money etc … but over the last months working with the CustomWeighting I think we should think about converting all costs into time (and e.g. get rid of ShortestWeighting as this is a very unrealistic)
Could you explain this a bit more?
Isn’t that also why we created the calcMillis method?
I can see many use cases where weight shouldn’t be equal to time. Just a few examples: curvy weighting 
, fuel optimized weighting, elevation avoidance (e.g. bicycles or walking), essentially any priority based weighting.
Why is this unrealistic? This seems like one of the classical weighting options 
.
This is for the actual ETA. For the weight you need to calculate everything into one unit (except if you do multi modal routing). And you could choose € or $ but the most natural seems to be time as you always can ask “how worth is this detour?”
As fuel cost is proportional to distance in your case you could already use the ShortFastestWeighting (distance_factor) as it controls the time you want to trade with distance (assume a route that takes 1000sec and is 10km long, then a value of 0.03 (30sec/1km) means that you would like to drive maximum 11km to reduce the travel time to 970sec or 12km to reduce it to 940sec.)
And you can do the same for toll cost (also time vs. money) and for any other priority you mentioned.
Why is this unrealistic? This seems like one of the classical weighting options
People think this is the classical weighting option, when actually they mean “shortest regarding time” not distance. Distance is a very weak measurement, especially for car. But also for bike & walking. Assume a walking route from A to B with a steep mountain in-between and you’ll save 1% of the total distance. Nobody would do this, everyone would go around the hill and arrive faster and invest less energy, i.e. “shortest”
Yes sure, if it’s not used as ETA, the unit doesn’t really matter? If we think of the value as time, cost, distance, or anything else, then the unit has no meaning. The routing algorithm will simply try to find the route with the lowest weight.
But then it would still make sense to have Isochrones calculated by ETA and by “weight time”?
I thought you proposed to use the calcWeight result as ETA, which IMHO, would be a bad idea .
Ah, now I understood … I thought this is already the case but you are right there is currently only distance and time.
Ok, so you would agree that we should also add a weight limit?
A brief update, this has been implemented here: https://github.com/graphhopper/graphhopper/pull/2011