Show road grade along with altitude

Thanks for your comment, Andrew. Personally I think I would prefer if the road grade calculation were not affected by zoom level because it would yield inconsistent results depending on how you look at the map. I expect that the grade calculation could be made reliable, since routing sites such as ridewithgps.com already provide grade data for routes. (Perhaps the grade shown on the dashboard is inaccurate because it relies on GPS readings?)

I agree with gynta. Grade is not at the point of your finger, but between two points. Hrvoje how would you specify which two points to use?

@gynta If the calculated grade were indeed (as good as) random, I would also argue against its inclusion in Locus. Fortunately, it is easy to check the grades calculated by existing routing software, which does manage to calculate a usable grade. In my experience, the reported grade is not random, it strongly correlated with the slope observed in the field.

For example, take a look at https://ridewithgps.com/routes/13050338 (or any other route on that site). You can hover over any point on the route, or on the elevation graph, and the software reports the grade. It can even draw the grade along with the elevation, display maximal grade in the statistics, etc. And none of this is specific to that mapping site; AFAIK all apps for cycle planning are able to report road grade at a point on the route. Just try a route in an area you are familiar with, and see if the calculated grades are useful.

Currently to obtain the grade of the road in Locus, I am forced to find the altitude lines in the vicinity and try to assess the slope based on their distance and the chosen zoom level. This kind of task is what machines excel at.

On https://ridewithgps.com the grade is also changing between two trackpoints on the given trackline. Zoom in and look! (or see attached clip)

Your topic sounds like "show me grade on any place (road) under my crosshair". Maybe my fault.

Anyway to to clarify your idea: "Snap crosshair on exists track and show grade". right?

Well ok, should we discuss about meaningfulness of this values now?

Hrvoje - you make new important qualification - you want grade displayed around tapped point on existing route (like RideWithGps) - that now makes more sense - the two points, one either side of your tap maybe (assuming tap on route point) is not two random points, but two points on the chosen route. Your original post didn't mention anything about a route. I like the idea again.

I can see how it would be calculated for a point on a route (like RWG), but how could it work for any point not on a existing route/ track? There are an infinite number of directions around the point you tap in which the grade between 2 points could be calculated.

Of course, the idea is to show grade while over a *road*, not at an arbitrary point. (See the original description, and the follow-ups - a "road" is always mentioned.)

If this feature didn't work off-line, it would be much less useful, at least to me. Are you saying that Locus basically doesn't know what piece of map represents a road (or track, etc.), in off-line mode?

Then you are indeed out of luck. The path data is not stored anywhere inside any of Locus offline maps (neither in sqlite pixel maps nor in mapsforge vector maps as far as i know). It would only work when you're online.

Then you are indeed out of luck. The path data is not stored anywhere inside any of Locus offline maps (neither in sqlite pixel maps nor in mapsforge vector maps as far as i know). It would only work when you're online. Obviously, you could cache that stuff locally... but that leads a bit too far.

Supporting the online query on the other hand should be relatively easy to implement. It could even be done by a 3rd party with a clever URL and a couple php lines, if only Locus supported external thingies better.

It could work offline if the tapped point was on a route or track.

offline:

I never received accurate altitude values from GPS or hgt files.

+- 20 Meters ? (compared with real values)

Wrong values will be also stored in saved track/points.

Most time(!), we have a calculation between two inaccurate altitude values.

So - how accurate/useful is the result?

It's again a question of "(coding)effort and benefit"

Calculating grades for existing tracks in the database isnt exactly rocket science. Obviously you have to deal with funky data errors... but hey... that has been done since ages. Just look at one of your altitude profiles... if your eyes and brain can sort of figure out how steep it is at a certain point, so can a software.

The trick is to get this track data realtime then you tap your map anywhere. OSMs overpass-API can be used to find out what is below (or sufficiently close) to your tap. If there is a "way" (osm slang for track), it returns all the "nodes" (osm slang for points) that make up the (part of) road/path/whatever. You'd then query their alitude values either from offline srtm data or online and could render an instant profile... or display the grade at the current point...

You can do the same thing manually right now... find some start and end points that match your thingy... calculate a track with brouter or whatever... store it... fill in altitudes... check out the profile... etcpp. Super complex... nobody does it just to quickly check out an interesting trail on a map.

Locus could automate this with the overpass-api into a single menu item on long tap... like "evaluate current path". It will never happen though... because neither menion nor 90% of the geocaching-infested locus crowd is interested in altitudes :-).

you are right