Feature request - Show elevation profile of planned route

[Justme]

Hi All,

First of all my compliments for the wunderfull programming. We are very happy with it. We used it for our cycling around the world tour, together with the contour lines plugin.

In mountain areas we can see how the road is going up and down with the help of the countour lines but we have to scroll through the complete map/route..

It would be much easier if we can plan the route and there is a extra option available which shows the road elevation.

I can image the grapgh will look like: x = km, y = alltitude. If you see this in a graph you will have a easy elevation profile. A good example can be found on website http://www.cycleroute.org/

In that way we can compare easily offline which route we should take on the bicycle and saves us a lot of time to scroll around the map.

Ciao,

Youri

[P Wat]

Seems an interestng idea. Would it bring any disadvantages?  Any other supporters?
Paul W
(Fellow cyclist, but less ambtious!)

[Marcel Kelders]

As long if you add a extra button/menu item after the planned route there well be no disadvanges. Processing power will then start after the calculation of the route. The button should only be visible when using the contour lines plugin.

Ciao, Youri

--
You received this message because you are subscribed to a topic in the Google Groups "Osmand" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/osmand/23evUxTytS0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to osmand+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Poutnik]

As alternative option, you can consider usage of LocusMap,
that has already integrated work with elevation profiles.

You can use it together with elevation aware local routing engine Brouter,
that can be used with both OSMAnd and LocusMap.

Poutnik

[Marcel Kelders]

The broutere engine looks very promissing. I will try to install this. 

[Poutnik]

There is the Brouter support Google Group
https://groups.google.com/forum/#!forum/osm-android-bikerouting
IT is configurable to be used as a maillist as well,
so you could than send and receive the posts
without visiting the Google site.

When you get familiar with standard Brouter settings and usage,
you may find useful or at least interesting this
https://github.com/poutnikl/Brouter-profiles/wiki

Poutnik

Dne 02/12/2015 v 07:50 Marcel Kelders napsal(a):

[Mirco Zorzo]

I suscribe, also for pedestrian ruote.

[Marcel Kelders]

I installed the brouter router engine and that works ok in osmand but it is not displaying any elevation profile so the suggestion here is not correct.

If somebody has other suggestions please let me know.

On Wed, Dec 2, 2015 at 9:22 AM, Poutnik <poutni...@gmail.com> wrote:

[poutnik]

Rather suggestions were incorrectly read. :-)

I have not said anything like that OSMAnd with BRouter displays elevation profile, only that BRouter is elevation aware routing engine.

If you want to see elevation profile,
you can view the route on Brouter web or use LocusMap, with Brouter or without.

15. prosince 2015 15:04:17 CET, Marcel Kelders <mkel...@gmail.com> napsal:

--
Sent from my phone via Android email client K-9.
Please, forgive my brevity.

[Marcel Kelders]

The reading is also possible :-) Locusmap cannot be installed from ethiopie :-( 

[Poutnik for NNTP]

Hm, that is bad and very strange,
Eithiopia SW policy is known to be weird,
like long imprisonment for VoIP usage. :-(

But the wrong conclusion about OSMAnd+Brouter
is independent on LocusMap availability :-)

Then, http://brouter.de/brouter-web/ remains.

On 12/15/2015 03:56 PM, Marcel Kelders wrote:
> The reading is also possible :-) Locusmap cannot be installed from ethiopie
> :-(
>
> On Tue, Dec 15, 2015 at 5:40 PM, poutnik <poutni...@gmail.com> wrote:
>
>> Rather suggestions were incorrectly read. :-)
>>
>> I have not said anything like that OSMAnd with BRouter displays elevation
>> profile, only that BRouter is elevation aware routing engine.
>>
>> If you want to see elevation profile,
>> you can view the route on Brouter web or use LocusMap, with Brouter or
>> without.
>>
>>
>> 15. prosince 2015 15:04:17 CET, Marcel Kelders <mkel...@gmail.com>
>> napsal:
>>
>>> I installed the brouter router engine and that works ok in osmand but it

>>> is not *displaying* any elevation profile so the suggestion here is not

[Daniele Carletti]

Any news about this useful feature? Considering there is already the contour lines plugin, it shouldn't be too hard to implement an elevation profile feature.

There is still space in the "directions" screen for an additional button, that when pressed might show the elevation profile for the route selected.

https://drive.google.com/file/d/0B4j0IiU3XVwOMmVFb2YtRl9PakE/view

That would be so useful to have a glimpse of the altitude instead of wasting such a long time to scroll the whole route on the zoomed in map and try to read the tiny altitude number on the contour line. Do that for a several hundreds km route, and you'll see it's an impossible task!

It would be nice to have an author's opinion. Thanks
Daniele

[Poutnik]

Especially if BRouter is used, it provides point elevations in the GPX
route,
and they should be present in API routing data as well( unless stripped
down as OSMAnd does not use it ).

Temporary workaround is the alternative of using LocusMap application,
that is Brouter-aware as well and has this feature implemented.

Dne 31/10/2016 v 07:11 Daniele Carletti napsal(a):

> Any news about this useful feature? Considering there is already the contour lines plugin, it shouldn't be too hard to implement an elevation profile feature.
>

> [...]
>
--

Poutnik ( The Wanderer )

My Brouter profiles
https://github.com/poutnikl/Brouter-profiles/wiki

[Daniele Carletti]

No one here wants to switch to locus map. The topic is "is OSMAnd revert going to implement this feature?".

A developer's point of view would be much appreciated!

[Poutnik]

Dne 31/10/2016 v 07:41 Daniele Carletti napsal(a):

> No one here wants to switch to locus map. The topic is "is OSMAnd
> revert going to implement this feature?".
> A developer's point of view would be much appreciated!
>

The primary background topic is "I want the elevation profile for
planned route".
OSMAnd or LocusMap are just tools.

[gergyverjux]

I am also in favour of this, I don't want to use an external tool to see the elevation along the planned route. Today I export the track to http://www.gpsvisualizer.com/elevation. And elevation is an very important aspect for planning a hike: 100m of elevation is equivalent to 1km of flat route !

[Bart Eisenberg]

Me too--for me as primarily an outdoors user, it's the single biggest would-love-to-have item.  A question though--would this feature require an additional download of DEM data?  Or could it be done using the contour data already available in the Osmand library.

[Marcel Kelders]

hee wunderfull Guys at OSMAND,

How important is this feature for you? 

How are your thoughts about realizing this? 

Bye Youri

--

You received this message because you are subscribed to a topic in the Google Groups "Osmand" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/osmand/23evUxTytS0/unsubscribe.

To unsubscribe from this group and all its topics, send an email to osmand+unsubscribe@googlegroups.com.

[Mirco Zorzo]

The feature is now on the nightly release.

Thank you

[nickjoh...@gmail.com]

On Wednesday, 14 December 2016 14:47:49 UTC, Mirco Zorzo wrote:

The feature is now on the nightly release.

Really? My understanding is that analysis of GPX tracks has been added, showing elevation and speed over time. This is based on data stored in the tracks.

That's not what is being requested in this thread. As far as I understand, the feature request here is for a graph/chart showing the elevation profile of a route you're planning. That's very different, and can't be done without somehow processing elevation data.

Nick

[A Thompson]

Note that the contour lines plugin and Brouter use the data gathered by the 2000 Space Shuttle Mission called SRTM using radar, that has a horizontal resolution of 30m. Hence, using the contour lines plugin, you could walk over a cliff unless it had been marked as such in OpenStreetmap; even if so, you could easily mistake the rendering of a cliff for a footpath and be distracted by the contour lines that smooth everything out to 30m.

Several countries have been open-sourcing LIDAR surveys (laser topography from aircraft). This can be so accurate you can see a car or a tree in the elevation data, and other datasets filter this to give the underlying terrain. OpenAndroMaps recently included this data for Austria. In the UK, 60%+ of the country has been released, concentrated on areas of flood risk. As LIDAR surveys are completed, and hopefully open-sourced, it could change a lot in terms of elevation-aware navigation (and with a resolution of  <=1m, steepness-aware routing too). Meanwhile, Google are independently gathering GPS elevations at least from where people drive, but this isn't open-source. It's an interesting time for map-lovers!

I found a presentation by the man behind Brouter here. My German is only good enough to understand the gist of his powerpoint about the problems with SRTM, but I still found it interesting.

[Poutnik]

I would not see it so dramatically.
Elevation data is not supposed to be a guide for a blind man.

Better precission than 90m / 30m grid of SRTM is fine,
but OTOH extreme precission competes with needed resouces due data size.

BTW I use Austria OAM witjh LocusMaps.

Dne 15/12/2016 v 04:45 A Thompson napsal(a):

> Note that the contour lines plugin and Brouter use the data gathered
> by the 2000 Space Shuttle Mission called SRTM using radar, that has a
> horizontal resolution of 30m. Hence, using the contour lines plugin,
> you could walk over a cliff unless it had been marked as such in
> OpenStreetmap; even if so, you could easily mistake the rendering of a
> cliff for a footpath and be distracted by the contour lines that

> smooth everything out to 30m. [...]

[Marcel Kelders]

Hi All,

I'm very glad that er is progress with this. Getting really exited for this. Yes the request is for planning purposes and not for real data. 

If we are on the bicycle you want to now how hilly some roads are and it does not matter how precise it is. I'm talking about hill with up and downs like 500 meter as we are cycling the world from Europe to africa and from africa to azia en onwards. 

The way I'm doing it now is to move the screen along the planned route and to get an idea how elevation go. Or go online first to see it on some websites. When I have several roads i do this for each road. Just a visual representation of this would be much more faster way.

Is the feature implemented to be used in a planning a route?

Bye bye

[Daniele Carletti]

Totally agree with previous comment. It's not about the analysis of an imported gpx track, but the intended use is to plan a route in the app to see the distance from point A to point B, and see the elevation profile of the itinerary.

Is this what has been implemented in the nightly release?

Thanks

[Daniele Carletti]

Hi, is there any progress about this? What do the developers think about?

A possible implementation might be using the route details screen, there is still a lot of space to add options. The Elevation gain and loss details, and the button to show the actual elevation profile might be available only if the user has the contour lines plugin installed.

What do you think? Check the screenshot attached and say your opinion.

Thanks

[Peter B]

I would love it plannig bike tours.
Peter

[Nico W]

I would like to see it too. For hiking, biking or even driving (finding a gentler slope in winter conditions or when towing a heavy trailer).
There is "gpx viewer", the app, but I don't know how easy it is to use with a route in the planning phase. Afterwards when Osmand has saved it you can open it and see the profile.

[Peter B]

Gpx viewer can only show profile depending on existing <ele> tag info in a gpx file.
What osmand would need is creating a track from a route by completing trackpoints and (!) completing altitude info for every trackpoint. This needs online access as far as I know.
Peter

[Rodolfo]

If it's for route planning at home, are you looking for something like this? http://www.justmapzz.com/products.aspx#elevation

[Josef Kufner]

Rodolfo wrote, on 26.1.2017 23:20:
> If it's for route planning at home, are you looking for something like
> this? http://www.justmapzz.com/products.aspx#elevation

Such plot is exactly what I would like to see in Osmand too!

It should be possible to click through to map on specific location, for
example when I click a peak in the plot, Osman should point me to where
the peak is, so I can add a nearby waypoint to avoid it.

[Daniele]

Sure it is for route planning, but while we're not at home, that's the whole point of an app like OSMAnd isn't it? You can do everything at home but with OSMAnd you can do it on the road too, wouldn't it be amazing?

There's a lot of interest for this feature, and it would be something unique on Android. iOS has the new MapOut app that's having a huge success for this feature alone. Why developers are not considering this?

Fingers crossed it will catch their attention soon!

-
www.becycling.net
www.facebook.com/becycling.net
www.instagram.com/becycling

On Jan 27, 2017 9:20 AM, "Rodolfo" <rodo...@gmail.com> wrote:

If it's for route planning at home, are you looking for something like this? http://www.justmapzz.com/products.aspx#elevation

--

[P Wat]

Danielle hits the nail on the head; it is "..... while we're not at home ..." that Osmand+ is most useful.
Do people really finalise their entire route from the convenience of their desk at home?
Osmand+ enables us to enjoy the spontaneity of amending our route whilst on the road, away from home.
Thus, route elevation profile computed within Osmand+ could be a real benefit (always assuming it does not overload the app).

Developers?  What do you say?
Paul W

[Andrew Davie]

I thought I'd mention that colours can be useful for displaying elevation. Some time back I did some experimental code in OsmAnd to colour routes based on relative elevations, and that's proven quite handy in my own personal custom version of OsmAnd for seeing routes and the "ups and downs" so to speak. There's a bit of a video showing a GPX track coloured by elevation here:  GPX using colour for elevation

[Poutnik]

The LocusMap application has implemented an option
for such a relative route altitude colouring,
along with the interactive displaying of altitude of the pointed place.

It is nice to have.

[gergyverjux]

Should ideally also work when using the 'planning tool' plugin, either directly while adding points, or after having saved the planned route as a gpx file. 

Coloring the track according to the elevation is fine but an elevation profile is far better, imo.

[gergyverjux]

Implementation in 2.6 goes beyond my expectations :) - Congratulation!

[Daniele Carletti]

Oh yeah! I can't believe elevation profile is here, and it's even better than anyone may have imagined! Congrats to the developers!

The match for the best maps and navigating app is definitely over!

[Marcel Kelders]

To all developers from OSMAND a very very big thank you. It is looking very good and works quit well. I will promote it in the world of world cyclist. 

Thanks you so much. 

On Thu, Apr 27, 2017 at 6:22 PM, Daniele Carletti <dnl.s...@gmail.com> wrote:

Oh yeah! I can't believe elevation profile is here, and it's even better than anyone may have imagined! Congrats to the developers!

The match for the best maps and navigating app is definitely over!

[P Wat]

Agreed - A big thank you to the "Devs" for the elevation profile enhancement!0
Paul W
==================

On Friday, April 28, 2017 at 12:27:43 PM UTC+1, Justme wrote:

To all developers from OSMAND a very very big thank you. It is looking very good and works quit well. I will promote it in the world of world cyclist. 

Thanks you so much. 

On Thu, Apr 27, 2017 at 6:22 PM, Daniele Carletti <dnl.s...@gmail.com> wrote:

Oh yeah! I can't believe elevation profile is here, and it's even better than anyone may have imagined! Congrats to the developers!

The match for the best maps and navigating app is definitely over!

--
You received this message because you are subscribed to a topic in the Google Groups "Osmand" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/osmand/23evUxTytS0/unsubscribe.

To unsubscribe from this group and all its topics, send an email to osmand+un...@googlegroups.com.

[Osmandtrier]

And there is a mistake. Opening a recorded gpx-file with an other gpx-viewer, the other party gpx-viewer shows a different difference of altitude than osmand.

So my idea was, perhaps osmand use the srtm-data. So I replaced the recorded elevation-data with srtm-data. I got also a different difference of altitude than osmand.

[nickjoh...@gmail.com]

On Wednesday, 3 May 2017 07:05:31 UTC+1, Osmandtrier wrote:

And there is a mistake. Opening a recorded gpx-file with an other gpx-viewer, the other party gpx-viewer shows a different difference of altitude than osmand.

So my idea was, perhaps osmand use the srtm-data. So I replaced the recorded elevation-data with srtm-data. I got also a different difference of altitude than osmand.

GPS altitude readings fluctuate a lot, so when apps like OsmAnd generate numbers for the total amount of ascent and descent, they usually use some filtering to distinguish errors/inaccurate readings from genuine changes in altitude.

I completely expect different apps to produce slightly different results, as they use different filtering thresholds and different algorithms.

Elevation figures calculated with SRTM data will be different. SRTM is based on measurements every 20-50m across the earth's surface. Presumably this has been interpolated into the OSM ways in OsmAnd's maps, so it will be less precise than GPS altitude measurements from when you've actually walked or cycled the route (though it also depends on how good a GPS fix you had).

Nick

[Osmandtrier]

 slightly

2000 4000 10000 is slightly different? Assumptions are nice, testing is better.

[Marcel Kelders]

Please take in account that the original request is for planning purposes and not for real data as mentioned in one of the emails before in this thread. I do not have any clear view how the specs where when they programmed this.

I guess it will be helpfull to give a complete and formal testcase and test result back to the developers so they have helpfull information about how to deal with you point of view.

On Wednesday, May 3, 2017, 'Osmandtrier' via Osmand <osm...@googlegroups.com> wrote:

 slightly

2000 4000 10000 is slightly different? Assumptions are nice, testing is better.

--

You received this message because you are subscribed to a topic in the Google Groups "Osmand" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/osmand/23evUxTytS0/unsubscribe.

To unsubscribe from this group and all its topics, send an email to osmand+unsubscribe@googlegroups.com.

[nickjoh...@gmail.com]

On Wednesday, 3 May 2017 10:13:54 UTC+1, Osmandtrier wrote:

 slightly

2000 4000 10000 is slightly different? Assumptions are nice, testing is better.

In your post (at least the one I replied to) you didn't specify how different the numbers were.

Nick

[Sergey Po]

Now at 2.6.3 there is altitude graph if there is altitude information in GPX, but there is NO altitude graph if altitude information in GPX is absent.

I would like to ask to add altitude graph even if altitude information in GPX is absent. Looks like this is possible because this is already done for route calculated by OsmAnd.

[Poutnik]

It is mistake to expect that
if elevation stats are not (almost) same, a mistake is involved.
As there is no single correct way how to provide the result.

For elevation aware GPX files,

if it is the planned route, the total elevations stats depend on
Used source of date ( SRTM3=90x90 m, SRTM1=30x30m, LIDAR based, other )
Used postprocesing of these data ( noise or artefact filtering )
Used postprocesing of the rouite elevation profile.

if it is the recorded track, it additionally depends on,
if barometer altitude or GPS altitude was recorded,
if altitude was replaced by SRTM equivalent data.
how noisy was 3D GPS position in case of GPS altitude,
how noisy was 2D GPS position in case of SRTM altitude.
How/if was done the altitude filtering during recording.
How/if was done the altitude filtering during presentation.

Quite a lot of variability to get the same results.
Different procedures and different date provide different results.

Without topografic feedback it is not possible to say
what filtering parameters ( for given typical scenario ) gives results
close to reality.

Not enough filtered GPS altitutes and partially also SRTM-like altitudes
overshoots total stats, as there are altitude jumping artefacts
due 3d/2d position inaccuracy.

Too strong filtering undershoots the stats.

On 05/03/2017 08:05 AM, 'Osmandtrier' via Osmand wrote:
> And there is a mistake. Opening a recorded gpx-file with an other
> gpx-viewer, the other party gpx-viewer shows a different difference of
> altitude than osmand.
>
> So my idea was, perhaps osmand use the srtm-data. So I replaced the
> recorded elevation-data with srtm-data. I got also a different
> difference of altitude than osmand.
>

--
Poutnik ( The Pilgrim, Der Wanderer )

https://github.com/poutnikl/Brouter-profiles/wiki

[gergyverjux]

As an additional request: it would be nice to also have an elevation profile when planning a route with the 'Distance calculator and planning tool' and saving it as gpx.

Search Results

[Sergey Po]

> As an additional request: it would be nice to also have an elevation profile when planning a route with the 'Distance calculator and planning tool' and saving it as gpx.

Agree, very useful! +1