This object is in archive! 

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

Christian Barth shared this idea 10 years ago
Completed

Hi,

in the winter i do backcountry skiing.

For that i need a map which shows the different slopes of the hills in different coulors.

Is it possible to generate the slopecoulours out of srtm files as a ouverlay.

Her is a example:

http://s0.outdooractive.com/map/xGradient/14/8657/5755.png


The map shows different colours for spezific angle areas. (e.g. : <25<30<35<40<45<50 °) or selectable;

Thank you very much

Christian

Replies (45)

photo
1

I like this idea. It's usefull for cycling. But it need to be configurable mapping angles to colors.

photo
2

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.

photo
1

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).

photo
1

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.

photo
2

I use slope angle shading from caltopo.com and hillmap extensively when planning a alpine scrambling trip. I also want to use it offline, but caltopo and hillmap do not support offline use.


Slope angle shading allows me to quicky gauge the slope level of the route I am planning to take. This reduces the chances of me getting into unexpected steeper terrain, and reduces (when used as one of the data points) the chances the chances of getting into a avalanche.


I hope Locus supports a similar capability soon.

photo
2

Would be a killer feature for all winter sports (ski touring, snowshoeing, etc.). Here, it is vital to immediately see where the slope is >30°, because that's where avalanche risk is starting.

As shading is already implemented, it's "just" a matter of coloring. It would be important to be able to define the slope ranges, as 30° might not be the vital slope for all sports.

photo
2

I would add to Ingo's point why all the slope angles are important for backcountry skying. Based on the avalanche risk forecast, you can choose track to avoid risky areas:


  • moderate danger level: no travel on slopes steeper than 40°
  • considerable danger level: no travel on slopes steeper than 35°
  • high danger level: no travel on slopes steeper than 30°
  • extreme danger level: no backcountry travel at all.

So all the levels are important for you to plan the track.

Outdooractive has their own app (although poor), so you can guys use it unless locus will support it.

Or it might be easier if Locus can negotiate adding Outdooractive map sources, including the gradient overlay, to its map sources instead of developing it.

photo
2

I wouldn't rely on map data to judge avalanche safety! That's what eyeballs are for, maybe a clinometer if you're splitting hairs.


Recently I've found some near vertical cliffs that - according to the topo contours - were supposedly just rounded hills. (Tall cliffs, high enough to span several contour lines.) So I've seen for myself how topo data can sometimes be wrong. Dangerously wrong.


I can see the advantage of this feature for general planning, but certainly not for final judgement.


"When the map and terrain disagree, believe the terrain."

photo
1

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.

photo
3

a6a788fccf0e5b94f264abaa8a864d3c


edit

sorry, whole text missing in post. grml

will repeated later...

photo
2

It seems that outdoor active, some maps from them are available now, supplies hill shade overlay (you can find it in application https://play.google.com/store/apps/details?id=de.alpstein.alpregio.AlpenvereinAktiv ).


It would be perfect if Locus supply bc skiers with this overlay.

photo
1

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.

photo
1
  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).

photo
1

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.

photo
1

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


f4c5eebe14e7a2b22b600a931a259327


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.

photo
1

Steepness is very correlated with area attractiveness and and it tells more about area character than hight points especially in case of canyons. Slope maps show where are valleys and how deep they are cut in.


Meanwhile everyone can make a slope map for oneself and for others from open data in a free software - SRTM data in MicroDem and QGIS like this on, like me.


I proposed in vain the author of http://www.maps-for-free.com/ to add slopes as a layer. So I made most maps in those subcategories on Wikimedia covering most of lands on the Earth.


Remarks:

1) Open Digital Terrain Models (DTM) are not very accurate especially in very steep area. For example Matterhorn in SRTM is lower a few hundreds meters (~700 ?)

2) I prefer slopes in % because 90° slope (vertical wall) isn't twice difficult as 45°.

3) There are many algorithms used to calculate slope and usually they are poorly documented. Many of them calculate average slope in all directions not only up and down. MicroDem at least explains them.

4) But its default colours make maps often not readable. I think it is because of change in brightness tendency in the scale. Often greyscale is more readable. So I've worked out a colour scale that also means brighter is always steeper.

4) DTM is a grid with some resolution, SRTM ~90 m. It means that within this 90 m slope can be very variable. Also neighbouring pixels (cells) can very vary so change can be without some intermediate slopes contrary to topographic map with contours. That is why I think first map presented above is very generalized (simplified) but it makes map more readable especially as an additional layer.


If someone is interested in I can write some How to use MicroDem and QGIS to make a slope map because these programs have plenty of options.

photo
1

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

photo
1

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.

photo
1

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.

photo
1

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.

photo
1

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

photo
1

I solved this for alps by using MOBAC and downloading the alpenverein/outdooractive steepness overlay for the entire range of the alps into an SQlite-map, then use it as a map overlay in locus. So for me that works as an offline solution, with a bit of a backdraw in performance (overlay of a huge map over some other huge maps), and no applicability beyond the area covered right now.


Using a DEM for calculating on the go would be great...

photo
1

Any progress and possible official support? Or should I start to seek for some workaround for this season?

photo
1

No progress here for now.

photo
3

Hello guys,

I've wanted to create one nice feature for you that will not take me a lot of time. And this one looked quite easily (compare to rest of features) :).

First steps

So - firstly, it is some kind of "alpha version". Do you have latest version 3.14.1? If not, install it.

Do you know config.cfg file? More about it here: http://docs.locusmap.eu/doku.php?id=manual:advanced:customization:config

In latest version is new special parameter: dev_enable_slope_coloring

Change it from default "0" to new "1". After that, start Locus and enable shading. Working ;)

Second part for advanced users

- shading values are hardcoded in app. But you may supply own file with colors. How to do it:

- created directory Locus/data/interpolators and put inside attached file.

- rename file to coloring_dem_slope.lcp

- modify colors in file to your needs ... simple help: first column is "slope", next four columns are alpha, red, green, blue parameter of color

Enjoy coming free days and hope it will work for you.

photo
1

Hi Menion, thanks for the feature.

But, is it applicable to OpenAndroMaps/Elevate themes as well, or to LoMaps only ?If just Lomaps, it is not a big deal for me, as I am quite satisfied with isoclines and shading.

As it seems I have not noticed any change on my Ost Alps map ( Locus closed at modifying and restarted 2 times )........

BTW, I have tried to switch the shading for the vector maps OFF and ON, without apparent effect.

photo
1

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??

photo
1

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 ?

photo
1

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.

photo
1

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

photo
1

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.

photo
1

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!

photo
1

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.

photo
1

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

photo
1

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. :-)

photo
1

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.

photo
1

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.

photo
1

Works as expected.. great Xmas gift.. thank you, sir!!


Edit : added screenshot

photo
1

Hmm it looks a lot better then Alps on Florian screenshots :).

Did you tried to modify lcp file? Is it clear?

If someone will have a "must have" color palette (Locus Color Palette), let me know. When we all will be satisfied with results, I'll do some UI directly in Locus (so no need for this mess over config.cfg file).

photo
1

Hallgeirs screenshot looks actually similar to what i see on screen (for high zoom level).

Lets see if i find some time over christmas to play with colors. I just checked with my maps - if shading looks good depends on zoom-level (as explained above - calculations based on a pixel-base, not a fixed grid in meters) and also strongly on the map colors. In OSM-data/Openandromaps + ElevateXL forests look particularly bad (not an issue for me - they are also bad for skiing, but mostly not so avalanche-prone ;)), rock and glacier are fine in higher zoom levels - thats where I need this feature most. Is there an upper limit for zoom levels? When using "Alps" from openandromaps - zoom level 17: no hillshade visible, zoom level 16: looks good, zoom level 15: already getting red, but still partially useable, zoom level 14: (almost) every hill is completely red, not usable.

Just an idea while i am typing here: would it be possible to have colored slopes in zoom level 17/16/(15) and normal hillshade on anything lower?


-----

Edit: Libor had at least a similar idea already :)

photo
1

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.

photo
3

I expect vs I got:


d88ff55bfba92a382641a7359cd3d3ab

(slow down device and make no sense with zoom <12)

photo
2

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

photo
1

Point, N 47.56817° , E 010.87852°

photo
1

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

photo
1

Thank you very much!


I'd like a button for switching (slope) shading in panel.


What is a default color palette? I don't think it is what you sent as coloring_dem_slope.txt or I don't understand it. In the file there is

40.00 100 0 255 150

,, first column is "slope", next four columns are alpha, red, green, blue parameter of color"

0 for red or is it BRG?


Merry Christmas

photo
1

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.

photo
1

good point!

have to ask same question Menion.

slo.pe aaa rrr ggg bbb ??

photo
1

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

photo
1

This new feature is just fantastic. I am experimenting with slopes of 5, 8, 10 to better visualize hills for cycle touring. Yet another nice Locus xmas present.

photo
1

When I change from zoom level 15 to 16 the coloring is disabled. I think from reading past comments this is for performance reasons? Certainly on an old Samsung Galaxy Note the performance is still excellent at ZL15. It would be nice to see the new shading at higher zoom levels, especially as this is "alpha version". The user always has the option to disable shading if panning becomes too slow.

photo
2

Thanks for trying. If I am to comment it with respect to usage for Skialpinism: it does not help me as the OutdoorActive:

the colors' meaning is hardly distinguishable, I don't know what exact color mean. OA clearly turns couple of colors into gradient contours which allows to identify slopes over 30, 35, 40, 45 degrees.

The simple fact that they have just couple of colors with clear borders for significant slope degrees makes it usable.

If you blur it, it is hard to read. It does not give much more information than a simple hillshading, which is just for quicker feeling where the hills are but not detailed orientation like contours (either altitude or gradient in OA) which allows you identify problematic areas.

Thanks for trying anyway, m

On Wed, Dec 23, 2015, 19:26 Locus Map <locus.map@asamm.com> wrote:

photo
1

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

photo
1

I verry much like this feature, great for off piste planning.


A nice addition would be to show the slope angle in the elevation path. example attached

photo
1

Menion, i really like the feature. Thank you so much.


Noticed 2 things

1. Most of the slopes are red. Should we break the color like caltopo does - what will be the coloring_dem_file for this coloring?

20-26 = green, 27-29 = yellow, 30-31 = light orange, 32-34 = dark orange, 35-45 = red, 46-50 = purple, 50+ = blue.


2. The slopes are incorrectly shown when you 'vector maps' are loaded. Is anyone elsenalso finding then same problem?

photo
1

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

photo
1

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.

photo
1

Great feature! Still quite buggy though and not yet usable. Testing with blahdis lcp file:


- Disappears at zoom>=17. It shouldnt... just keep it visible.

- Zoom 16 looks more or less correct to me.

- Changes colors randomly between zooms 15 and below. Something going very wrong here.


As for the upcoming GUI, maybe it should be completely independent from hill shading with a separate switch? Would fit better inside the quick switch panel, most buttons there are simple on/off things.


Of course, a threeway-thingy also might work... Shading: OFF/HILLSHADE/SLOPECOLORING

photo
1

Joeloc has done a better job describing the problem.

photo
1

Btw, the whole shading thing (colors or hill shading) does not work on my RMAPs (I made a 3GB Kompass Eastern Alps). Could be a projection thing? Or maybe hillshading is only for mapsforge? Not a biggy... OSM has been getting so much better in recent years, I find myself using it almost exclusively.


One advantage of RMAP (and I guess SQLite as well) though: they render many times faster. Maybe the mapsforge tile caching into bitmaps (does it exist?) could be made a bit more aggressive? Even when I zoom or scroll the very same region repeatedly, mapsforge is ages behind RMAP in rendering speed. Shouldnt it be more or less equal after being cached once?

photo
1

Is there an other app on google play with better solution to handle srtm files in this chase.

Be sure: i don't talk about 3rd party maps - i talk about using pure Shuttle Radar Topography Mission files!

photo
1

Any progress? Ski touring season is just around the corner and this feature seems "almost complete" with only a few tiny bugs to squash. If you wait another month, your Locus skiing community will lose another year :).

photo
2

Agreed with everyone here! If we can get this into the maps, I request that we go one step further on the groupings and follow what caltopo.com does.


0-26 deg: no shade

27-29 deg: yellow

30-31: orange

etc etc as the scale in the upper right of the picture


e9c932924d19d6fb59bbaf6a940db968

photo
1

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.

photo
1

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.

photo
1

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.

photo
1

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.

photo
1

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.

photo
1

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.

photo
1

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.

photo
1

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.

photo
2

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...

photo
1

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.

photo
1

38b19ff1fb284a8cb99f52fc98b7d722

It's already quite nice, please do not abandon this feature :).

photo
1

Hi Stef

Nice setting.

plz share your 9 lines of setting

photo
1

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.

photo
1

Ah yes - same problem here with other settings.


fine - so just wait for next step - thx

photo
2

One idea for speed / algorithms: You could initially render a slope color tile in a very low resolution, like something closer to actually SRTM data resolution instead of current map resolution on screen. You wouldn't care about blurring, just render single pixels.


Then, in a second step, use some android gfx toolkit resize function to increase to actual tile pixel size on screen.


So e.g. you render in 16x16 and then zoom to 256x256. With the proper flags, I am pretty sure the zooming will produce exactly the required blurring effect. And it should be fast as well, because it's handled by the GPU.


Sorry if this is major bullshit, I have no idea on your current algorithms or on android gfx toolkits. It was just an idea that crossed my mind...

photo
1

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.

photo
1

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.

photo
1

Thanks joeloc and Pawel,

I don't know why, but I've spend on this task whole weekend and rewrote whole shading from a scratch, so you (and others) will see in next version if it helped ;). Shading is slower now, but I hope there is a place for improvements.

For me remain one big issue I was not able solve correctly. Interpolation of elevation values from known grid. Bicubic interpolation (from 4x4 values) seems not to be good enough (borders of grid are still little bit visible), so if someone skilled with these interpolation stuff is here, suggestion is welcome ;). Anyway more talk rather with next version.

photo
1

Well, anyone tried latest Beta version of Locus? (switch to enable coloring by slope is already in settings for shading).


Suggest not to use custom palette to start. Locus draws nice thin border between 30, 35, 40 values so it looks a lot better. This is currently not possible with custom palette.


Enjoy it ;)


Idea completed!

photo
1

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.

photo
1

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?

photo
1

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?


hochfuegen-ski1

Line figured out with Locus Slope Coloring :)

photo
2

>switch to enable coloring by slope is already in settings for shading

ahh, the missed info :)

hmm, nice but my devices are too slow for this feature:

outdooractive vs locus:

f6085a59af0830870b99eabe0c862c22ca55515128ccf43e1236ae8502b95927

photo
1

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.

photo
1

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.

photo
1

First of all- great feature.


But I can't be, never ever, fully satisfied :-)


Is it possible to use just slopes grades as overlay? Just for the case that I want to use some other map, but have slope steepness?

Next- it would be nice to quickly turn the feature on/off.

photo
1

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

photo
1

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.

photo
1

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.

photo
1

What data I needs to display hill shading? Previously, elevation data downloaded during configuracji height adjustment, now at this place nothing does happen, and I not see shading..

photo
1

The hgt files in the SRMT folder are needed.

photo
1

Pleas, tell me where I find this file on the web? I think about Poland.

photo
1

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

photo
1

Thanks! Its work, but this model is no too precision on my region : /


Shading from Geoportal WMS server is better, but only online and without new slope coloring. For example ; )

photo
1

I know, its completed. And I know it would be a real performance choker. But wouldn't it be a real showcase, to impress your fellow alpinists, a map with both shading options active at the same time?


Edit: typo

photo
1

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>

photo
1

Thank you for your quick reply!


Yeah, i did screenshot with online Overlays-Hike&Bike hillshade...

Unfortunately our alpine hut is without internet coverage..

photo
1

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.

photo
1

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.

photo
1

Okay, need to find a provider with shading thats downloadable.. OSM overlay Hike&Bike hillshade is cacheable but not downloadable..

We investigate futher, thanks again!

photo
2

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 :-)

photo
1

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.

photo
1

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.

photo
1

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.

photo
1

Joeloc.. you gonna push Menion off a cliff.. haha

Desided to upload a screen recording of my user experience..

https://drive.google.com/file/d/0B6yeLu9CW8zwVk0zZGY2Z09mdU0/view?usp=docslist_api .. size=65mb. Lomap with offline OSM hillshade overlay..

A couple of months ago I had nothing close to this, thats why I impressed by the efforts of the developer and his team on this subject.. I'm sure its gonna be refined in the future :-)

Happy outdoor eastern everybody!


Edit: Device is Note 3..map and hillshade file on external sd card.

Rendering is slightly faster without a screenrecorder running.. sure :-)

photo
1

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.

photo
1

Amazing work indeed - i am now using new feature regularly and its working very well. Thank u Menion and team!!

photo
2

You are welcome, I'm really glad it work!


Suggest all future development around this topic, mark with tag "shading", so it will be a lot easier to search for them: http://help.locusmap.eu/search/tag%3Ashading . Have a nice weekend.

photo
1

I'm very glad now and I don't know whether I'll make tiles from my png slope maps because with transparency is much easier to orientate, thank you. And with transparency with changing background is better when colour scale is not linear except the lowest band. I've made it linear from flat (not transparent black) what gives some shading on gentle slopes here < 20 % (however it is calculated) and with 2 extra colours. The area is the same as in my previous screenshots.

photo
4

Just because it fits the hill shade / slope color topic somewhat, here's a glimpse into a possible Locus future:

http://webgl.uni-hd.de/realtime-WebGIS/index.html

is an impressive OpenGL algorithm demo for hillshading/coloring. It is quite short (view source!) and renders things amazingly quick... on my phone about 40(!) times the speed of Locus hillshading. Runs on the GPU completely, the CPU would be free for vector maps.


Oh... and you can configure the sunshine angle to match reality... for all of us "northerners". Hey... future Locus could even tie that to time of day and position... for a super-real shading experience :-).

photo
1

Nice work, hmm!

photo
1

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

photo
1

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

photo
1

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 ;).

photo
1

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 :-)

photo
1

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

Replies have been locked on this page!