OruxMaps

Quote from: "Maki"Great, Orux!



Some observations. The map looks quite dull, because you put the hillshading below and made the foreground semitrasparent. If you reverse the things with a 20-30% opacity for the hillshading on top and 100% for the map below it gets better, but still a bit flat. If you then multiply the layers rather than just blending them the shadows are better defined and the contrast is retained (black remains black rather than turning grey). If Android standard functions don't help and you have to do the compositing by yourself, the Photoshop formula for multiply is (layer1*layer2)/256. If I have done the maths correctly the formula to multiply and lighten the shadows in one passage could be map*((hillshade*opacity)/255+1-opacity) where opacity is between 0 and 1.



To compare start from this (emulated) screenshot //https://www.flickr.com/photos/30914757@N04/15572753175/ and use the arrows to see the next two. The first is normal blending, the second is "multiply", the third the previous emulation I made.



As I said above this is just the "quick and dirty" way. The advantage is that it can be immediately applied to any map, the problem is that it changes the map colours significantly, unless you make the effect rather light. Changing colours for the background is the desired effect, but changing paths and roads in a non uniform way may pose problems since we relay (also) on colour to distinguish things. The best way to handle this (and the one I emulated in the third screenshot above) is to apply the shadowing only to the background. As you can see the shadow effect is much more evident, but still the paths and the tracks aren't obscured.



In theory that's easy, you just need a theme with a semi-transparent background. Any existing theme can be adapted very quickly. In practice there is a particular problem with OpenandroMaps, because they draw the sea below everything else. Making the map background transparent will just reveal the sea instead of the hillshading. Christian has surely a good reason to do that, but maybe he can change it. At a first look it seems that Freizeitkarte and standard Mapsforge maps don't have this problem, so if you want to do tests I can put together a transparent theme for that.

Quote from: "Maki"Hi goosiebin, you are simply at a tile border. An horizontal junction would be even worse...



Commonly available DEM data is far from perfect, there are artefacts in a lot of places and especially mismatches at tile borders. If you check OpenAndroMaps or OpenCycleMaps contour lines in the same situation you'll easily find mismatches there too (obviously since those are calculated from the same dataset).



The artefacts we are seeing in Oruxmaps are probably due to interpolation at higher zoom levels since they do not show at ZL13 and below. That's part of  the reasons why I say to render at ZL12 and just scale up and down. You can't expect photo-realistic results from DEM data and in any case hillshading doesn't have to be photo-realistic to begin with. It just serves the purpose of guiding our brain into interpreting the contours.



Also keep in mind that currently the shading is very intense, so any defect is immediately visible, with a lower opacity it would be a lot less objectionable.

Quote from: "Maki"Just tried it. Very, very promising...



First thoughts:

1) the light is wrong, it really should come from top left which is pretty much an industry standard. I know the sun is from south(-east) but that's not how our brain works. Lights and shadows are interpreted with reference to the situation in which we are. So, since light is usually coming from above if you light the map from below you reverse the perception of valleys and peaks. See //http://blog.thematicmapping.org/2012/06/creating-hillshades-with-gdaldem.html for some nice examples.

2) the intensity is good for low zoom levels, say 11 or below. It's way too high at higher ZL. It also depends on the terrain nature, smooth hills require a more intense effect than steep mountains where things get black fast.

3) it is a lot pixellated, at every ZL. I would expect it at higher ZL, but not at ZL 13 and below. This, combined with rendering times at different zoom levels, makes me suspect that shadow tiles are recalculated at every zoom step. According to my tests rendering at ZL12 and scaling with filters at other ZL is very fast and gives a very smooth effect without pixellation.



I don't find the rendering especially slow, but given the above, and considering that a 1x1° tile can be saved in JPEG without noticeable quality loss at around 1MB, I'd explore Tobias idea of prerendering at ZL12 and scale that. I doubt people has hundreds of DEMs on the phone, and in any case it's 4% the size of the DEM itself, so no big deal.



I think that the user should have control on the shadow intensity, because the ideal setting will depend on both the map and the area (smooth vs. rugged). Maybe a quick setting in the tweaks menu. It would also be interesting to explore the possibility of automatically changing the intensity according to zoom level, in addition to what the user sets his preference. I'm doing this with buildings, for example, that are solid black when they appear and get progressively lighter when you zoom in. It helps things stand out when they are smaller, without becoming oppressive when they are bigger.



Thanks,

Maki.

Quote from: "orux"

Quote from: "Maki"Just tried it. Very, very promising...



First thoughts:

1) the light is wrong, it really should come from top left which is pretty much an industry standard. I know the sun is from south(-east) but that's not how our brain works. Lights and shadows are interpreted with reference to the situation in which we are. So, since light is usually coming from above if you light the map from below you reverse the perception of valleys and peaks. See //http://blog.thematicmapping.org/2012/06/creating-hillshades-with-gdaldem.html for some nice examples.

2) the intensity is good for low zoom levels, say 11 or below. It's way too high at higher ZL. It also depends on the terrain nature, smooth hills require a more intense effect than steep mountains where things get black fast.

3) it is a lot pixellated, at every ZL. I would expect it at higher ZL, but not at ZL 13 and below. This, combined with rendering times at different zoom levels, makes me suspect that shadow tiles are recalculated at every zoom step. According to my tests rendering at ZL12 and scaling with filters at other ZL is very fast and gives a very smooth effect without pixellation.



I don't find the rendering especially slow, but given the above, and considering that a 1x1° tile can be saved in JPEG without noticeable quality loss at around 1MB, I'd explore Tobias idea of prerendering at ZL12 and scale that. I doubt people has hundreds of DEMs on the phone, and in any case it's 4% the size of the DEM itself, so no big deal.



I think that the user should have control on the shadow intensity, because the ideal setting will depend on both the map and the area (smooth vs. rugged). Maybe a quick setting in the tweaks menu. It would also be interesting to explore the possibility of automatically changing the intensity according to zoom level, in addition to what the user sets his preference. I'm doing this with buildings, for example, that are solid black when they appear and get progressively lighter when you zoom in. It helps things stand out when they are smaller, without becoming oppressive when they are bigger.



Thanks,

Maki.

Hi, Maki;



about ligth, you are right, changed to left-top.



about pixelation;



if you have DEM files with 30 mts. resolution, check your 'settings--maps--relief map--Relief map, resolution'. Try with 'high' or 'very high'.



Delete first the raster cache in 'settings--maps--reset raster cache'.





orux