Note that this is only available for the POST-request.
Reading the elevation: true on openrouteservice Directions, it states “Specifies whether to return elevation values for points. Please note that elevation also gets encoded for json response encoded polyline.” but i believe this does not allow me to set the value for elevation.
sorry, it seems I misread the “set” in your first question for a “get”.
I’m not sure I understand your question though. Any coordinate has a fixed elevation; how would you “set” that?
Can you go a bit more into detail here, please?
I want to be able to set the elevation and the API returns a route where the elevation is closest to the elevation i have set. This could be like a hill walk where a user can set the elevation during the walk and it returns a route with that elevation.
I think you have to split this Problem in at least three Parts:
Programm a Routine, which let the User choose a Point / Destination. Maybe show Users’ current Position on a Map with a Radius around 5 Miles where he can see the Pathes. Or do a search of interesting Places. Etc.
If you have once a Place wiht coordinates, must not be the final Destination, you can get the Elevation and show to User.
Then calculating the Route with the two Points.
Is just an idea.
But how would that be possible? It is practically a given that there is no path that remains on one elevation (even with a margin of error of several meters), unless you go off-track. But I don’t think ORS will show you a route off the track.
Besides, what if the users sets an elevation of 150, but has a starting point at sea-level? Or something similar.
It almost sounds like you want to make a walking route out of a contour, but that would require that walking paths and trails follow contours all the time. Now I live in NL, which is so flat that basically any route you generate complies with this requirement, but in more mountainous regions paths don’t follow contours all the time.
But maybe I misunderstand you as well, I’m not a 100% sure of what you actually are trying to achieve. What is it, in really generic terms, that you want to offer your end user?
A walking/hill walking app that allows them to set their preferences for a route such as distance and elevation.
OK, that starts to make a bit more sense. But I’m still confused about setting elevation as a preference. What should that do: find a walk that starts at that altitude? Or a walk that from start to end has a total ascent of that elevation? Or should it try to stay at that elevation as much as possible, ie follow a contour around a mountain or hill?
Or is it more like a maximum setting, like maximum ascent: I want to go for a walk, but I don’t want to do any climbing (so my elevation preference would be 5m - since I want my walk to be as flat as possible), or I do want to do a lot of climbing (so my elevation preference would be set to 500m - meaning my route can go up and down and possibly contain almost vertical bits)?
I don’t think any of those examples would be possible with ORS out of the box: you’d have to do quite a lot of programming yourself, or create a lot of possible routes and analyze their suitability with respect to the elevation preference.
My idea is to have a walk from start to end has an ascent of the specified elevation but i dont think ORS does this feature.
Indeed, basically you would want to weight the routing graph using elevation and then find all routes closest to your preferred value. You would have to tweak the algorithm quite a bit to do this, but it doesn’t seem impossible to do.
However, this is not something we will implement in the near future
How would you “weigh” the routing graph using elevation? Do you mean using ors directions or elevation for this?
You’d request a route, with elevation=true, then determine whether the elevation info on the geometry of the route fits with your preference.
So you’d take the startpoint z-value and the end-point z-value, and determine whether the difference fits with your preference. The problem there is that the route in between might go up and down as well, so you may have to analyze the full route in order to determine the full ascent and descent during the route. Then, depending on what you find for that route, you determine a weight which indicates how much that route complies with your preference. Based on that weight you can show it to the user or not, and in what order.
Im not understanding the “weight” for the route. Everything seems fine to understand
Maybe take a look at routing algorithms on a weighted graph then
As said before, this is not a trivial thing to do an requires quite some knowledge on graph theory and routing algorithms. Then you would need to use a custom openrouteservice backend where you implement your logic to consider elevation either instead of or in combination with the distance between point.
Giving something a weight, in this context, means giving it a sort of priority or rank, in order for software to be able to judge it. So, using your example for a preference for a certain ascent in a walk:
Suppose I find two walks:
- Walk A has a total ascent of 25, and a length of 100.
- Walk B has a total ascent of 40, and a length of 150.
The user has given as preference for ascent 30, and as preference for length 125.
So Walk A is closer to the users preference for ascent than Walk B, and both walks are equally close to the preference for length. Based on that, you can give Walk A a higher rank or priority, since it matches more closely to the users preferences. This allows you to sort the two walks, or even disregard one of them because it is too far away from the users preferences.
There are numerous ways of calculating weights, based on whatever it is you are doing (it’s a statistical thing as well), but in this case a very simple way of calculating a weight could be taking the absolute difference between the values found on the walks and the values of the users preference. So
25 - 30 = absolute(-5); 100 - 125 = absolute(-25), and
40 - 30 = absolute(10); 150 - 125 = absolute(25).
The weight factors for Walk A would then be 5 and 25, and for Walk B 10 and 25. Depending on what you are comparing you could combine them even further, possibly take the inverse as well, but this already shows what I am getting at. Those values are something software can base a decision on, and that is what is needed here.
For the experts: I am aware that I am taking quite a few shortcuts here, but that is done on purpose in order to explain things
If you want to explore this further, search for “weighting methods”. That will probably give you a bit more of the basics, but it is quite a large area of interest. ORS for example uses different attributes of roads and paths as weights (such as road surface, maximum speed, road type ie a highway or a local road, etc), in order to get to the fastest or shortest route.
I hope that clears things up a bit?