Slope shading in different colours, <30°, <35°, <40°

I agree with onelook. Don't restrict to <25 because for cycling gentler slopes <3 <6 <8 <10 are more important than steeper slopes. Selectable slope and color will be needed otherwise continual arguments between user groups (cycle, 4WD, ski) for more angles and colors will forever continue.

I don't see the purpose here - especially for cycling. The slope on a path (where you cycle) has nothing to do with the slope of the hill surrounding it (which is subject of this idea).

I agree with Christopher here as a slope is direction dependent. A hill slope and a way slope are loosely related, but independent things. Much more useful for cyclists is a route slope.

I do not object against the usefulness for offroad activities in free terrain.

Check http://help.locusmap.eu/topic/user-defined-colors-for-steepnessgradient-in-a-track for track steepness :)

sure, it is for planning only. When you are in the terrain you have many other more reliable ways to choose the track. Including your eyes, experiences and rutsch block snow stability test etc.

The OA overlays are certainly nice, but I don't see why these should be used, when Locus already makes use of the "raw" NRTM data for hill shading.

Basically, the hill shading palette just has to be changed/made customizable. The algorithm would stay more or less the same. Same input data as already available, no need for extra download.

1. using finished overlay doesn't require any programming
2. hillshades are pretty important for skialpinists, literally vital. Outdooractive is official supplier of map contents for OEAV/DAV (correct me if I'm wrong). Since it's that much important, I prefer a such source instead of (maybe) not-that-exact opendata.
3. There is no other use for steepness but skialpinism and maybe downhill skiers (for cycling it doesn't make any sense, nobody climbs direcly uphill, cyclists are interested in road/path steepness which is definitely completely different).

First of all, don't forget the snowshoers ;)

As one of those, I totally agree with you - this data is vital. And I also agree that "official" data is better. However, living in Switzerland, for me that wouldn't be OA, but Swisstopo. Afaik these maps are already available in Locus. And I don't mind making more specialised maps available in Locus, also for money if not otherwise possible.

And there the problems start: Different sources for different regions. But for a general Locus functionality, there's no way around general, worldwide data. That has to get better, sure - but I'm not expecting the Locus developers to implement a specific overlay solution for different regions of the world.

That's why I support this as a basic, general solution that doesn't take much - I think - for implementation. Just make the palette customizable.

First aid would be begging at Locus for adding a such hillshade overlay supplied by Swisstopo.

I've remember to mention one more point - for most users is more comfortable to have ready-to-go solution, they don't want to search and set anything.

But there is one universal solution- render one global OSM overlay 30-35-40 (with no customization) and add it to Locus shop. Now it's possible to download hillshade, so this would be another option.

Do you maybe know how to convert shapefiles and other format to formats that we can use? For Austria there is a lot of very detailed (5m, 10m) available for free: https://www.data.gv.at/suche/?search-term=10m+Gel%C3%A4ndemodell&searchIn=catalog

I haven't tried it. I'm going to try before my next holiday.

Shapefile

Looking at Supported by Lous Map Formats I can't see a format common with QGIS. There is SQLite (*.sqlitedb) for Locus and SQLite (*sqlite) for QGIS, but I would try, at least ,,conversion" by renaming extension.

Rest formats on the Austrian website are rasters. Menu Layer/ Add Layer/ Add raster layer. In a Layers panel double click the opened layer to open Layer Properties window. Style tab for editing appearance. There is some help under Help button but much more there is on-line.

For saving: menu Raster/ Conversion/ Translate and Select MBTiles. There is also Rasterlite (*.sqlite)...

Target SRS (projection) should be WGS 84 (web maps projection).

Shapfiles can be rasterized. Menu Raster/ Conversion/ Rasterize. I haven't practised it.

Google map, OSM and others can be browsed in QGIS. Menu Plugins/ Manage and Install Plugins and install OpenLayers.

No idea what you're talking about haha :P But I will try to read a bit about it when I have time. I just noticed that for Austria elevation models with very high resolution are available. But I cannot use them as DEM in locus or other applications because of the format. The guy from viewfinderpanoramas.org said he is working on converting them, but that was 1-2 years ago, and there is still nothing.

I've written about making a map in QGIS and trying to use it in Locus. Now I guess you want just use height data like in manual:faq:how_to_add_map_shading. QGIS doesn't save in hgt. Was whole Austria available 1-2 yesars ago in geo tiff ? If not you can write it about to Ferrati or start a new idea topic about adding height reading from a geo tiff, that is the standard in GIS for raster data.

Ah I understood.. have to read and try again with qgis

No progress here for now.

It should work for all maps. It's just little bit modified basic shading that also works for all maps without any limits.

You have to fully close Locus before change this config file. Othewise changes won't be used.

And for you, Locus force-closed after you enabled this feature in config file??

Well, I have relied on closing dialog after back button press,

and removing from recent apps list ( android 4.3), then I modified the file.

should the shading to be allowed, or is it independent on it ?

I cannot locate the forced close setting in config, it it there, or has to be added manually ?

By "fully close" it though exactly what you did.

Just enable shading in settings ... if parameter is correctly set, you won't see an classic hillshading, but this "slope shading" instead.

It does work for me (Galaxy S5, Android 5.0, "Alps" from openandromaps and Elevate XL). I did modify the config.cfg prior to starting the new version though :)

Awesome feature and perfect timing for the season!

One thing I noticed is, that obviously shading changes the scale used for calculating slopes with zoom-level - so it basically turns the alps red if you zoom out (shocked me a bit after starting the app), but works really nice once you zoom in to a level of detail useful for hiking.

Cheers

Flo

Hmm looks like too much transparency on your screenshots. It now needs to find optimal colors that should be predefined in app.

Anyway general problem (visible mainly on alps) is that Locus compute altitude values every 16 pixel. So tile 256x256 is divided into squares 16x16 px and in corners are computed altitude values. Colors are then interpolated. So if you zoom out more, details are lost and colors starts looking similar ... I should reduce size of small squares, but it will slow down rendering. So this is a compromise for now.

16x16 explains it ;) I guess this is only an issue in situations with lots of steep slopes in relatively small areas. Could transparancy be increased with decreasing zoom level (i.e. less pronounced color with lower zoom)?

And I rather prefer red alps to slower rendering speeds ;) i can always turn off hillshade easily anyway.

Thanks!

Hmm, strange, I see nothing like the colours in screenshots, restarted previously the device, having already colouring set to 1 in config file...

I have also tried to set ON/OFF the overlay settings with hike and bike shading as online overlay map ( blending mode off, as I do not orient is this setting ). Only normal shading occurs.

Normal shading seems not to be active is overlay is off, so it is possible the is some wrong settings in my Locus.

Are you enabling this settings: http://docs.locusmap.eu/doku.php?id=manual:user_guide:maps_settings:misc - "Map shading"?

I have tried the all combinations od the shading and overlay ON/OFF.

I have noticed it may be cause by elevation files.. but, at least for Czech republic Locus does show the interactive elevation.....

i have downloaded the hgt files with guidance of youtube video, and it works now.

But I am not decided yet if I would prefer it to the classical shading. :-)

it looks like it may have sense to have option to kick the colouring ON since selected zoom level only,or as mentioned, change the slope colour scaling, or both. For low zooms it seems disturbing, hiding / distorting map details.

A possible alternative could be to generate similar overlay map as online bike/hike hillshade overlay,

but as a filtered slope gradient instead. it could be in grey tones as well.

I got similar impression it is usable in quite narrow range of zooms.

For high zooms colour is cleared but slope is well distinguished by isoclines.

For low zooms colour creates unpleasant cast over the map.

The usability range depens on tarrain, for flatter areas moves down.

----

The Normal shade vs slope colouring switching threshold makes sense. A user could set it to please him in the particular area, as optimal value is terrain specific.

Hehe, nice difference :). What are the coordinates of that place so I may test it also? Thanks

Point, N 47.56817° , E 010.87852°

That's also what I would expect, for ski touring for example the locus implementation is too smooth

Hello Pawel, thanks you are correct. I've uploaded here my testing file and not the original included. Fixed and topic now has original file.

good point!

have to ask same question Menion.

slo.pe aaa rrr ggg bbb ??

Yep ... it's in header of file ;)

It's a first try, hopefully things can be improved based on this :)

About #2 - vector maps - it works after I updated the vector map to most recent one, but the colors disappear when zoomed in..

I created a coloring_dem_file to match caltopo and it worked.

However, I am finding that the coloring is incorrect when the map is zoomed out and fixes itself when zoomed in. This happens in multiple map types (Vector or SQL). When zoomed out, nearly everything appears like slope level 60+, and then depending on the zoom level it becomes more accurate. This will make it a bit difficult to plot the approx route using a high level view of the terrain - have to zoom in quite a lot and then decide the approx route.

Can someone pls advise me on how to fix the above problem? Love the feature, but it needs a slight tweak to make it work.

Joeloc has done a better job describing the problem.

No good idea in my opinion and can be even dangerous. You should always stick to known and established scales - which is, when talking about avalanches, something like 30, 35, 40..

A too fine resolution complicates reading as well, but an editable scale would maybe be helpful for different preferences.

Agree to disagree I suppose. I know plenty of trained mountain guides who like this setup just fine. Knowing the difference between 35 & 40 is not as useful because both are prime time avalanche steepness, while knowing the difference between 30 & 33 is more important. All good either way. You are entitled to your opinion.

Oh well, I know plenty of mountain guides that died in avalanches.. that's not really valid reasoning :) I understand your point, I'm just saying you should stick to the most common interpretation of a scale.

It's a risk if you've got yellow from 30-31 whereas on another map you've got yellow from 30-35.

I'm fine with either one, and there are advantages of course (if the resolution allows it, which is questionable for most free sources). However, one has to be aware of the implications.

We use caltopo.com for planning the route when at home, and then locusmap in the field for on the go adjustments. Hence, better for both to use same defaults for color.

Christoph, I'm curious what "common interpretation of a scale" are you talking about? Is there some other well-established color coding slope angle scale that's used in avalanche education or something? If so, I agree that it would make sense to use an existing color scheme... but I've never seen that before so I'd be interested if you have a link to share.

Blahdi, FYI you can use the exact caltopo map as an overlay on your locus pro offline in the field. Then toggle it on-off vs any other map (i.e. satellite so you can see trees vs not). Let me know if you're curious and I can tell you how. You can also use the same caltopo overlay file to see the slope angles in Google Earth. It works better on desktop than app Google Earth though.

I have tried to use calttopo overlays - that is good for a rare event, but hard to use when u are go on new routes regularly. Currently, before every trip, someone posts a gpx file, and then only thing that we sync everywhere is the gpx file which is small, and it is loaded on GPSs of all the members of the team. Then, those who have locusmaps get the additional benefit of checking the slope offline. No need to download overlay files.

In Europe we mostly have mostly yellow, orange, red and slopes of 30,35,40 deg. It makes sense as it allows to easily interconnect avalance levels to slope gradient. That's not written in stone though.

What I want to say is not that you should not use a higher resolution scale, but to match the colors accordingly to portals people use or not at all settle on a predefind scale - I understand though that caltopo is what people use in the US?

I'm not sure if there is a standard or anything when specifically talking about avalanches. I know a couple of accidents where people had different scales on their devices which caused a) a confusion and b) different or wrong assessment of the risk.

I would like to stop this discussion guys. When such feature will be possible, it will be probably also possible to define colors for certain range as it works now. It is not a problem.

Huge problem for me is in performance, where I need a lot of altitude values for certain grid of points to interpolate correct colors and this operation is quite slow for this purpose.

I have to find out some a lot faster solution. For map shading it is not a big problem (but even there are nicely visible small squares). So I don't have nice solution for now, sorry.

You could cache it in bitmap tiles... just kidding... I know you hate caching with all your heart :-).

Anyway, I am usually the first to complain about Locus performance. But if the choice is between a horribly slow feature or no feature at all, I'd still go for horribly slow. I am sure we can spare a few seconds here and there when it concerns possibly life threatening situations.

I find the current performance quite acceptable btw. And the action seems to happen in a separate thread without blocking zoom/scroll/fps/usability, so speed is pretty much a non-issue. It takes about a second here at the moment to slopecolor a screen. Even ten seconds would be fine as long as it happens in the background.

If only that bug with the randomly jumping colors for different zoom levels was gone...

If a slope map is used for a risk assessment a warning should be added that slopes are calculated as an average slope between grid points so a slope can be very variable between points especially if line of slope doesn't come through these grid points. I'm against discrete scaling when all points in a given range get the same representation. Linear scale makes harder to access values whether it is between 30 and 35, but it minimises chances for an attitude ,,I got green light on a map to go there" what is important because a slope map is already simplification and there is no bigger difference between 29 and 31 than 31 and 34.

Hi Stef

Nice setting.

plz share your 9 lines of setting

I think I simply took some example from one of the posts above. It doesn't make sense anyway at the moment because the colors jump around happily on every zoom level. The only thing that seems to work for now is Zoom 16.

Ah yes - same problem here with other settings.

fine - so just wait for next step - thx

What for to add a blur (interpolation)? Slope, contrary to elevation, doesn't have to go through intermediate values between grid points so bitmap is the answer.

I've made some slope maps in QGIS on SRTM data 3 arc second resolution. I increased map resolution by root of 2 in comparison what QGIS told me is 1:1 resolution. Menion, this one you could be personally interested in. Pixels become noticeable at zoom 11, so if Locus samples data every 16 pixels it is like zoom 15, isn't it? I don't understand why Locus shows higher values of slopes in lower zoom than in native resolution of SRTM data. It is not a change in elevation data sampling because it would average valleys with ridges.

I can try to add some screenshot for comparison later, first I have to learn how to do it.

I've made a few screenshots at zoom 16 and 11 with Locus slope shading, (I hope it is enough to change extensions of lcp file to allow Locus to return to default palette), my slope map (white is at least 100 %, 45 degree slope), my map in default Locus slope shading palette. Unfortunately without transparency. QGIS plugin QTiles allows to export to set of directories with png files and they are with transparency. As mbtiles there is no transparency no matter whether they are set as a background or a cover. By comparison of my slope map with Locus slope shading it seems zoom 16 is the only correct for Locus slope shading. I exported zooms 9-13

Once I thought that redness at lower zoom is due to slope spilling or casting slope shadows in all directions but it seems slopes rise at lower zoom.

I hope setting config.cfg dev_enable_slope_coloring is still valid, and file coloring_dem_slope.lcp is still used? I found colors for cycling with gentler slopes <3 <6 <8 <10 quite useful.

ah, I can now see a new setting in Maps - Advanced > Map Shading > Type. Why is it limited to 30/35/40 slopes? Surely this feature could be generalized as in the alpha version?

Nice job. But as mentioned above, coloring MUST NOT disappear at zooms > 16. Ski touring / free riding is a very "high-resolution" thing, I quite often use 17 or 18 when figuring out my lines. Disappearing colors are highly irritating.

I am also not sure that coupling coloring to hill shading is good. Why not allow both?

Line figured out with Locus Slope Coloring :)

Great. I would call it usable if it will be shown as a layer over hillshading. If you make it part of the production app, I'll start using it. Best if it could be controlled by Quick settings a same way like hillshading.

One more level over 45° would help. That one is significant in better conditions.

It seams quite a broader than the OA version. I understand the measurement might be a different, but this seams to be systematically broader. Worth checking if the calculation is right.

Thank you Menion.

Great that this made it into the "normal" user interface - I love the feature!

But - I see the same thing happen as myneur - more areas highlighted above 30, 35, 40° than on outdooractive. I had the same feeling with the original feature around christmas, so i tweaked the scp-file by changing the slopes i coloured - i added about 10° to make it look more like outdooractive....

Do I know who is more correct? No :)

I add some screenshots from what locus calculates, the output of my changed scp file, outdooractive and TIRIS.

Hello Hrabosh, may you explain this to me little more? What you mean by "slope grades"? Just a thin lines? Anyway currently there is no additional settings for this feature (in latest 3.16.0 version).

Quick turn on/off is already possible over "Quick settings" : http://docs.locusmap.eu/doku.php?id=manual:user_guide:settings:quick_settings

Lets imagine that I want to use some different map without height information (summer Outdooractive Topo, that includes creavasses, grabbed from website). It would be nice to have hillshade (skialp-coloured) over that image. I can grab the map with hillshades in this case, but it wouldn't work in general.

Slope grade - sklon svahu. Here in four four categories, so slope grades.

One more idea slightly linked- take elevation from overlay (if not present at basic layer). Now it's possible to have basic layer with elevation with 100% opacity ovelay without it (so I can see elevation in the map without elevation information and without internet connection). But it would't be possible with this feature.

Layer with slope angles is independent on the map you select. Nevertheless, the elevation data are vital for this feature as the graphics is calculated from them.

All required information may be found here: http://docs.locusmap.eu/doku.php?id=manual:faq:how_to_add_map_shading

You can sort of already do this, if you use an overlay map to shade your hills instead of the builtin Locus function. The Locus function will then only be used for slope coloring. Both work together nicely and look great.

+ overlay relief maps are faster than builtin shading.

- overlay relief maps need extra memory or an internet connection.

I don't know if the default Locus config contains overlay relief online maps... if not, you can add one yourself via Locus/mapsOnline/providers.xml

1. <provider id="11234" type="0" visible="true" required="false" background="-1"><name>OSM Layers Uni Heidelberg</name><mode>Aster/GDEM Hill Shading</mode><area></area><url><![CDATA[http://korona.geog.uni-heidelberg.de/tiles/asterh/?x={x}&y={y}&z={z}]]></url>;<zoomPart>{z}-8</zoomPart><zoomMin>8</zoomMin><zoomMax>26</zoomMax><tileSize>256</tileSize><attribution>http://korona.geog.uni-heidelberg.de/contact.html</attribution>;</provider>

You can download any online map into an offline sqlite map. Works also with the relief things and map overlays. I just did that with the alps... guess zoom 11 is enough for pretty shading. Not too much sdcard space wasted.

PS, I dont know why the decision was made to not allow builtin shading & coloring together. Maybe it was too slow to start with. But the speed majorly increased with the latest release, so maybe menion will reconsider.

Wow, just found this archive http://download.osmand.net/hillshade/

Performance acceptable.

Solves everything, and i think it looks nice! Hillshade as overlay.. 50 % opaque.

Thanks for pushing me :-)

Nice find. I havent checked in detail... but I could imagine hillshading as sqlite db uses much less memory on sdcard than the uncompressed srtm data tiles that Locus downloads. Plus it renders way faster and uses much less battery, at least on my phone.

Obviously, Locus can use the downloaded srtm tiles for other stuff as well... like adding altitude values to downloaded track data, enhancing gps altitude values (does it really?) and of course for slope coloring. So there is some need to keep both datasets.

You want's compare SQLite map for 1x1° with 2.8 MB that is HGT file? Hmm not sure if you may get lower value with SQLite map :). Faster? Hmm, on my device is shading on 256x256 tiles usually on +- 20ms , loading and converting PNG from SQLite will be close to this as well. And rendering of overlay should be definitely slower because Locus needs to draw "two maps" at once, while shaded tiles by internal shader are just "one map". Just my two cents.

And if allow shading and slope coloring at once or not - I didn't do any decision if yes or no! It just needs some extra time to optimize both tasks that now works separately into one process. And for now, I spend on this more time then I wanted, so maybe later.

You are right... I just did some more free-eye speed checks between offline sqlite overlay hillshading and Locus builtin hillshading and there is no more major difference in total rendering time. Your new optimizations for the release version really were a major step forward.

I think, to me, the overlay method just "feels" a lot faster because the overlay is pretty much visible immediately when scrolling. The vector data appears on top a while later. I can hardly see any "empty screen".

The builtin shading syncs each tile to vector rendering, so there is plenty "empty screen" to be seen on scrolling. Effect gets worse on lower zooms obviously, because mapsforge sucks big time then.

But all in all... the builtin shading is amazingly fast now. I wish it werent synced to mapsforge tiles and I wish it allowed coloring independently, but thats really just nitpicking on a high level. Everything is fine!

As far as prettyness goes:

Uni Heidelberg Tiles (see above posting)

beats

Locus internal shading

beats

Osmand sqlite maps.

But thats maybe just a matter of taste.

Nice video. And it precisely demonstrates how "blank screen time" is minimized when hill shading and mapsforge rendering is not(!) synced per tile.

Maybe it's just me... but "blank screen time" really makes Locus feel unsnappy.

I am thinking of ways to combine a world overview (zooms 1 to 8) with hill shading (zooms 9 to 12) in one sqlite map. And then obviously have a vector map on top. That could make Locus really smooth. I am afraid some blending options might still be missing for that.

Nice work, hmm!

I will keep throwing amazing GL algorithms into your face until you finally give in :)

How about mapsforge rendering in GL with 20 fps? Maybe that would convince you?

Maybe if you return from your trips and take care about all around Locus for at least three months, I should spend on secret island this time to learn and implement OpenGL ;).

Buy the company/hire the developer of this app..

https://play.google.com/store/apps/details?id=org.elevmaps

Seriously, you've done great so far...time for a well deserved break :-)

Hehe, thanks Hallgeir, I was already thinking about something similar :)