Hello,
It looks like “maximum speed” is just ignored with the current version.
Any information about that ? Is this a regression, or an expected behavior ?
Best regards
Hi,
thanks for reaching out. We are currently in the process of deprecating certain options and restriction filters, including maximum_speed. It might be the case that even though the parameter is already disabled at backend some of the documentation and/or error handling hasn’t been updated yet. We will look into this.
Cheers,
Andrzej
Thanks Andrzej for that quick response !
The maximum_speed option was quite useful for isochrone maps. It is a pity that this parameter was deprecated… Out of curiosity, what was the rationale of removing it ?
Thanks again
Renato
I’m very sad to see the “maximum speed” option removed 
It was very useful when planning a route with caravan or trailer which legally (Sweden) can go only 80 km/h. This means that I no longer can trust the calculated time of travel, since the calculation now is based on the maxspeed of the road, not the maxspeed of the vehicle 
Thanks for your feedback!
It’s an interesting use case, I’m wondering whether we could introduce a dedicated caravan/trailer car subprofile then? CC @timothy @nils
Cheers,
Andrzej
I think it would be better and more flexible to simpy reintroduce the “maximum speed” option. Why? “Maximum speed” then could be used by everyone for whatever reason they would like to travel slower than the speed on the road signs. Examples:
-
I would guess that different countries in the world might have different regulations regardning maximum speed for caravan/trailers, so a predefined subprofile would at best be a blunt approximation.
-
If my 1930’s car has a comfortable speed of 60 km/h, I wouldn’t be helped by a predefined 80 km/h caravan/trailer subprofile.
-
If I prefer to drive maximum 100 km/h instead of 120 km/h on motorways (to save fuel and wear), I wouldn’t be helped by a predefined 80 km/h caravan/trailer subprofile.
The programming should be rather simple. When calculating the trip duration, simply use the minimum value of “user maxspeed” and “road maxspeed”.
Thanks a lot for sharing your concerns.
It would be exactly the opposite, as the subprofile could consider country-specific speed limit regulations. In fact, for international routes you would be better off with it than with a fixed max speed capping.
The other two points you mentioned are fair enough. However, you seem to underestimate the actual technical details behind the routing. In short, travel speed is the key factor for calculating fastest routes. The problem is much more complex than just scaling the results computed with default speeds, because the speed capping might actually influence the route geometry itself.
We have removed the maximum_speed setting for now because it was a limiting factor preventing us from implementing a much faster routing algorithm than the currently used one. The new algorithm has a much better scaling with distance in dynamic scenarios such as avoid features, allowing us to compute longer routes in shorter time than before. The problem with user defined max speed was that it was hindering such scaling. However, there is still room for some improvement. In particular, we might consider re-introducing the speed capping but with some reasonable lower bound. We will certainly investigate this, so stay tuned!
Cheers,
Andrzej
Ooh, even better! Great! 
I know that routing caclulations definately are complex. But nevertheless, time = distance / speed, and the vaule for “speed” has to be fetched from somewhere, for every little section of the journey.
Reasonal lower bounds would be… reasonable 
Hi @tomastomas,
the key to fast routing is preprocessing. Preprocessing requires knowledge of speeds per route segment at preprocessing time. Reevaluating the speed by a given maxmimum user speed at runtime negates the correctness of the preprocessing and will in turn lead to suboptimal (aka wrong) routes. It is not as easy as changing the value @runtime.
However, we are currently working on reintroducing the maximum speed functionality with our new high-speed flexible routing algorithm. You can follow the progress at https://github.com/GIScience/openrouteservice/issues/480.
1 Like
Great! I am waiting with excitement 
Hi,
i also searching for the option to set an maximum speed as a filter in the isochrones.
I need it, to see how long needs a emergency-car to arrive any point in a area between 10 minute (by limiting the speed!)
Is that possible?
No sorry it’s not at this point. However, we’ll soon release an upgrade taking this into account.
EDIT: sorry, not for isochrones though (yet). Only directions.
Hi @nils
However, we’ll soon release an upgrade taking this into account.
How soon is “soon”? Still waiting with excitment. I checked the linked github issue, but I didn’t really understand the statuses 
“…moved this from Awaiting release to Last release…” meaning? 
Hi @tomastomas,
this was released with the 6.2.0 update.
But it was only added to the documentation yesterday.
Check out the API Playground, you will be able to make example requests there now.
Please be aware that this is only for /directions POST endpoints, and the lowest speed you can specify is 80 km/h.
Best regards
1 Like
Oh there it is 
I must have been looking for the “maxspeed” option under some of the other profiles, bike or something. My bad 
I think it was the name of the original parameter we removed back in the days 
It’s an interesting use case, I’m wondering whether we could introduce a dedicated caravan/trailer car subprofile then?
What happened to the idea with a caravan/trailer subprofile for cars? Did this suggestion never reach the “todo” list?
Bummer 
It would have been a nice feature