Web Route Planner: Calculate Elevation When Planning Routes in Manual Mode
Gathering feedback
When planning a route in the web route planner, if a route section is drawn manually (instead of e.g. "Walking") on off-track areas of the map, the distance is updated, but not the elevation loss/gain.
This limits you a lot if you want to plan a route off the existing tracks.
It would be really helpful to be able to plan routes anywhere using the web planner and to have the elevation calculated.
I like this idea
Hi, I second this.
It would also be so more helpful to see the manual route elevation profile instead of a flat sea level ;-)
Thanks in advance for considering this, and have a good one :-)
Hi, I second this.
It would also be so more helpful to see the manual route elevation profile instead of a flat sea level ;-)
Thanks in advance for considering this, and have a good one :-)
Hi team, any update on this?
Hi team, any update on this?
Looks like web planner does not have as easy access to elevation data as the app does. So when bypassing the routing service for manual mode, elevation data is also not available. Perhaps manual darw should be a function of the routing service too? Either way, this is not just a feature request, but another inconsistencty between webplanner and app route planner which is most likely already on teams TODO list ;)
Looks like web planner does not have as easy access to elevation data as the app does. So when bypassing the routing service for manual mode, elevation data is also not available. Perhaps manual darw should be a function of the routing service too? Either way, this is not just a feature request, but another inconsistencty between webplanner and app route planner which is most likely already on teams TODO list ;)
Dear Locus-Team, please add at least a comment to answer your User's questions, and not ignore them, thank you!
I'm also wondering why no elevation data is provided in manual drawing mode - unlike using Hiking, Cycling, Car modes. Manual drawing mode is important if e.g. hikers want to reach mountain peaks which aren't connected to a path but have to be reached cross-country. Right now the elevation values and the elevation diagram is not correct if planing such hikes by Web Planner.
(There's been a similar thread: https://help.locusmap.eu/topic/35025-draw-manually-and-uphill-and-downhill )
Dear Locus-Team, please add at least a comment to answer your User's questions, and not ignore them, thank you!
I'm also wondering why no elevation data is provided in manual drawing mode - unlike using Hiking, Cycling, Car modes. Manual drawing mode is important if e.g. hikers want to reach mountain peaks which aren't connected to a path but have to be reached cross-country. Right now the elevation values and the elevation diagram is not correct if planing such hikes by Web Planner.
(There's been a similar thread: https://help.locusmap.eu/topic/35025-draw-manually-and-uphill-and-downhill )
Hi guys, Bartek is right. Web planner currently doesn't have elevation data outside routed track segments. This is something what might change next year, so we are waiting whether we would be able to rely on this for solving this matter.
To rely on routing service for plotting manual segments is not great, so we would like to avoid this.
So I am afraid I don't have the answer yet how and when this will be handled. But for sure we track it as the issue to be solved. If optimal solution would still be long way to reach, we would try to handle it temporarily at least by plotting the line on the altitude graph between locations with known altitude - instead of showing altitude zero and generating a hole in the graph.
Hi guys, Bartek is right. Web planner currently doesn't have elevation data outside routed track segments. This is something what might change next year, so we are waiting whether we would be able to rely on this for solving this matter.
To rely on routing service for plotting manual segments is not great, so we would like to avoid this.
So I am afraid I don't have the answer yet how and when this will be handled. But for sure we track it as the issue to be solved. If optimal solution would still be long way to reach, we would try to handle it temporarily at least by plotting the line on the altitude graph between locations with known altitude - instead of showing altitude zero and generating a hole in the graph.
Hi Jan, thanks for your explanation!
But where does Locus get its elevation data for the routed segements? Is the data provided by a 3rd-party routing service?
You're right, one first step would be the temporary solution by plotting the line on the altitude graph between locations with known altitude.
But in this case I'm not quite sure what is better: The temporary solution with no holes but giving the User the illusion of a correct-calculated elevation profile althougt elevation Totals maybe quite off - depending on length and terrain of manual segemen. Or keeping the current solution with holes but the user knows at first sight that the manual segments are not included.
At least it would be nice if you explain the holes in manual drawing mode here: https://docs.locusmap.app/de/doku.php/manual:user_guide:webplanner:planning
Hi Jan, thanks for your explanation!
But where does Locus get its elevation data for the routed segements? Is the data provided by a 3rd-party routing service?
You're right, one first step would be the temporary solution by plotting the line on the altitude graph between locations with known altitude.
But in this case I'm not quite sure what is better: The temporary solution with no holes but giving the User the illusion of a correct-calculated elevation profile althougt elevation Totals maybe quite off - depending on length and terrain of manual segemen. Or keeping the current solution with holes but the user knows at first sight that the manual segments are not included.
At least it would be nice if you explain the holes in manual drawing mode here: https://docs.locusmap.app/de/doku.php/manual:user_guide:webplanner:planning
I'm having the same issue in the Android route planner. Planning an off-trail jaunt, and want to advertise it properly to my friends/victims. Drawing a straight segment between, say, two ridge tops, with a valley below, doesn't account for any elev gain/loss due to the valley, just the simple difference between the endpoints.
Workaround is to (remember to) mark a point at the valley bottom.
I'm having the same issue in the Android route planner. Planning an off-trail jaunt, and want to advertise it properly to my friends/victims. Drawing a straight segment between, say, two ridge tops, with a valley below, doesn't account for any elev gain/loss due to the valley, just the simple difference between the endpoints.
Workaround is to (remember to) mark a point at the valley bottom.
In the Bikerouter forum as well, the topic of elevation onto the beelines or manual track sections is currently a hot topic.
Just check out the recent discussions. Let's start here.
https://www.mtb-news.de/forum/t/bikerouter-de-brouter-web-fragen-antworten-hilfe-profile-tipps-etc.917910/post-20479771
Notice a feature that the Locus (app) offers in a fairly unique way but, in my opinion, doesn’t make the most of in that still-mediocre Locus web planner. What a pity anyway
When it comes to features such as adding elevation data, there are clearly more options and possibilities available through some external route planners.
Elevation is also discussed in more detail further here.
https://www.mtb-news.de/forum/t/bikerouter-de-brouter-web-fragen-antworten-hilfe-profile-tipps-etc.917910/post-20489965
However, the elevation data itself does not seem to appear to be included (yet) in the exported GPX beeline track points.
Video: https://www.youtube.com/watch?v=OPyVcnRmukE
Since the steepest climbs in my area are just a few molehills, this is less important to me personally.
For those who are interested, I hope this is quite informative. However, I doubt this will ultimately trigger and lead to any additional activity or optimisation in the Locus Web Planner application.
I think it’s indeed a good idea to try something different for a change— goiing strange it seems more adventurous.
The Pitstopper app’s web designer is also quite active on this (and other) topics very recently.
Feel free to ask questions about possible optimizations. By the way, the designer’s name is Andrew, and he’s very approachable. Anway It’s also interesting to read through some of the published Pitstopper blog posts.
One example to start with: https://pitstopper.net/blog/gpx-navigation-extensions.html
It certainly offers a different perspective on issues that ultimately concern every GPS user.
In the Bikerouter forum as well, the topic of elevation onto the beelines or manual track sections is currently a hot topic.
Just check out the recent discussions. Let's start here.
https://www.mtb-news.de/forum/t/bikerouter-de-brouter-web-fragen-antworten-hilfe-profile-tipps-etc.917910/post-20479771
Notice a feature that the Locus (app) offers in a fairly unique way but, in my opinion, doesn’t make the most of in that still-mediocre Locus web planner. What a pity anyway
When it comes to features such as adding elevation data, there are clearly more options and possibilities available through some external route planners.
Elevation is also discussed in more detail further here.
https://www.mtb-news.de/forum/t/bikerouter-de-brouter-web-fragen-antworten-hilfe-profile-tipps-etc.917910/post-20489965
However, the elevation data itself does not seem to appear to be included (yet) in the exported GPX beeline track points.
Video: https://www.youtube.com/watch?v=OPyVcnRmukE
Since the steepest climbs in my area are just a few molehills, this is less important to me personally.
For those who are interested, I hope this is quite informative. However, I doubt this will ultimately trigger and lead to any additional activity or optimisation in the Locus Web Planner application.
I think it’s indeed a good idea to try something different for a change— goiing strange it seems more adventurous.
The Pitstopper app’s web designer is also quite active on this (and other) topics very recently.
Feel free to ask questions about possible optimizations. By the way, the designer’s name is Andrew, and he’s very approachable. Anway It’s also interesting to read through some of the published Pitstopper blog posts.
One example to start with: https://pitstopper.net/blog/gpx-navigation-extensions.html
It certainly offers a different perspective on issues that ultimately concern every GPS user.
Replies have been locked on this page!