SLOPE LAYER USING DEM

[edorap90]

Hi!

I know that this topic was already discussed (http://www.oruxmaps.com/foro/viewtopic.php?f=8&t=1406">//http://www.oruxmaps.com/foro/viewtopic.php?f=8&t=1406) but it's been 5 years since it was opened and I guess something has changed.

Oruxmaps has already introduced the hillshading for Mapsforge maps based on DEMs but a slope map is still missing. Why don't introduce it using DEMs to obtain something similar to this https://www.openslopemap.org/karte/">//https://www.openslopemap.org/karte/?

It could be available for almost all over the world and will be super useful for winter sports and a grate upgrade for oruxmaps. Many skitourers are waiting for it!

[Maki]

Commonly available DEMs (SRTM, Aster, EUDEM) are very poor quality for this purpose. I compared to LIDAR scans and in some areas the difference is awful. But, yes, things are improving in some areas. Several institutions (France and Spain IGN, Swiss) are providing ready-made slope maps, it'd probably be better to find a way to use just them as overlay.



Personally I'd be happy enough to have the drag tool showing slope and/or elevation difference in addition to the distance, it would already solve a lot of situations at almost no cost.

[orux]

Commonly available DEMs (SRTM, Aster, EUDEM) are very poor quality for this purpose. I compared to LIDAR scans and in some areas the difference is awful. But, yes, thinks are improving in some areas. Several institutions (France and Spain IGN, Swiss) are providing ready-made slope maps, it'd probably be better to find a way to use just them as overlay.



Personally I'd be happy enough to have the drag tool showing slope and/or elevation difference in addition to the distance, it would already solve a lot of situations at almost no cost.

Hello!





I have been doing different tests, with DEM files of 1 arc sec. The result is not bad at all. The new beta version allows you to use relief/shadow/slope maps on composite maps.



But the best solution is still to use maps (mbtiles for example) already rendered, with higher resolution DEM files, and use them in composite maps.



I will add slope/altitude diff in drag tool as an option; it is easy,









orux

[Maki]

Results can only be as good as the input data. If DEMs are bogus  results are bogus too. I'll try the beta this week and report back but, just to give you a visual clue about how bad DEMs can be here are three screenshots of the same area (Monviso, Piedmont, Italy) rendered with GDALDEM from EUDEM (allegedly an average between ASTER and SRTM), ViewFinderPanorama's DEM1 (nobody really knows the source), and LIDAR scans from the local government (resampled to match the DEM1 resolution and projection). Overlap them and see how shape and sometimes position of the reliefs change.

https://flic.kr/p/24gYsaX">https://flic.kr/p/24gYsaX">HS_EUDEM by https://www.flickr.com/photos/30914757@N04/">Maki, su Flickr

https://flic.kr/p/EBTPx6">https://flic.kr/p/EBTPx6">HS_VFP_DEM1 by https://www.flickr.com/photos/30914757@N04/">Maki, su Flickr

https://flic.kr/p/24e67S3">https://flic.kr/p/24e67S3">HS_DTM_Piemonte by https://www.flickr.com/photos/30914757@N04/">Maki, su Flickr



You can't see it in a rendering, but data analysis shows the the EUDEM is off by 100 meters about the highest summit in this area.



Those general purpose DEMs are good for large scale evaluations (flood paths, for example) but not for small scale terrain analysis. Skitourers use slope maps especially to estimate avalanche risk, so doing slope evaluation on bogus/rough data is not a good idea. Unfortunately most people is not able to establish if the data they have is good or not, I've seen it in several discussions on dedicated forums.



That said I'm not against the feature, I worked a lot on this kind of maps in the last three years, I'll get back later when I have a little more time.

[Maki]

Ok, I gave a try to the latest beta. Here are some random facts and thoughts.



I don't see the options for the measure tool, are they already implemented?



I created a multimap with my summer maps+slope map created with custom DEMs (out of LIDAR data) and compared with my winter maps. It looks like they match well enough, so I'd say the calculations look right (assuming you used the colour scheme I suggested in the other thread). I say they "look right" because my winter maps are actually using a different colour scheme so it's not a precise comparison. This rises the first request: there are different school of thoughts about colour schemes, and they are equally valid. Would it be possible to have multiple schemes? I think building an interface for this would be cumbersome at the moment, but adopting the GDAL text files would be easy: just create a dedicated folder in the preferences where you put some default schemes and where the user can store optional custom ones. You can let the user chose the scheme with a custom button or in the preferences. I can build the files for the most common schemes if you want.



There are visible tile seams, and this should not happen. In the case of hillshading it is just visually annoying, but for slopes I assume calculations are not reliable there. The most common approach to avoid this problem is to calculate a larger area and then crop the borders.



The multiply option doesn't work, I get a washed out image, multiplying always darkens the image in any app I know of.



A slope map isn't useful at low zoom levels and drags the performances down. You should either hardcode a zoom limit or give the users a choice either in the general preferences or in the multimap creation phase.



I also find limiting the need to use multimaps, it's a complex nerdy procedure. This kind of application is more apt to be used with overlays. The most practical thing would be to have a dedicated button (like we have for the 3D map) to turn the feature on/off on the fly, and a section of the navigation drawer dedicated to set colour scheme, blending mode and opacity (with a slider, please, no text field like when building multimaps...). Also you are usually putting colours on top of other colours which can result in a visual mess. Turning the feature on should (maybe optionally) greyscale the underlying map, to avoid colours clashing and make the thing more readable.



Then data sources. As explained commonly available DEMs are not exactly ideal: not only they are unreliable but they also use different units on the horizontal and vertical axis. But it is increasingly common to find much better open data to work with.  This data is usually supplied with different projections that are better suited for slope calculation (i.e. all units are in meters). It would be nice being able to use compressed geotiffs, with support for nodata areas and arbitrary projection.

[edorap90]

I'm happy that this topic brought to an interesting discussion and a slope map implemented in the new beta (thanks OruxMaps!).



The SRTM resolution is not enough for skitouring purposes, but it can be ok for other stuff. So to make the app more flexible to different usages I suggest the possibility to use different DEM sources, like GeoTIFF with arbitrary projections.



A good color scheme is necessary to provide good informations to the user, so choosing the right colors is crucial. A good start can be the color scheme used also by the swiss avalanche warning service (here is an example https://goo.gl/VDRQXF">//https://goo.gl/VDRQXF).



I think that these two points are the most important ones, than it's possible to refine the details using all the great Maki's suggestions.

[mitxelin]

(english version below)  :-)

Me uno a esta conversacion. Yo tambien soy esquiador de montaña y estoy habituado a preparar los itinerarios en Qlandkartegt/ QMapshack coloreando las pendientes con un DEM desde hace varios años.



Estoy practicamente de acuerdo en todo lo ya dicho por maki. En realidad ver las pendientes coloreadas para preparar el itinerario es un trabajo previo que debe hacerse en casa, antes de salir y para eso es mas practico una aplicacion desktop. En cualquier caso esta caracteristica tambien esta bien en oruxmaps, si estas fuera y necesitas cambiar la planificacion del dia siguiente. Por supuesto los colores no son un semaforo y hay que saber evaluar, y tambien esta la discusion sobre al precision de los DEM.  



He estado jugando un poco con la nueva Beta y probando con varios DEM de zonas que conozco. El primer golpe de vista es bueno, sin embargo creo que el algoritmo no da unos resultados muy precisos, y tal vez deba ajustarse un poco mas.

Para salir de dudas y que sirva de ayuda pongo unos pantallazos de la misma zona en Oruxmaps y en el programa Qmapashack (QMS). Lo importante es saber que ambos pantallazos tienen el mismo mapa y el mismo DEM, sin embargo los resultados difieren mucho. Encuentro que el del QMS se ajusta mucho mas a la realidad. (los pantallazos al final)





El mapa de ejemplo es el mapa Garmin de alternativaslibres.org que tiene unas curvas de nivel muy precisas (fuente IGN), el DEM corresponde a Viewfinderpanoramas de resolucion 1 arc sec. Finalmente tb añado un pantallazo hecho en QMS con el MDT25 del IGN, que posiblemente sea la referencia mas precisa (en este caso usar el MDT05 creo que no aportaria una mejora).

He marcado con flechas en el pantallazo las zonas que a mi juicio (interpretando las curvas de nivel y conociendo el sitio) no son correctas. En algunas zonas parece como si el coloreado se desplazara en exceso al sur, pero no en todas , asi que no puedo intuir que es lo que falla.



Sobre los esquemas de colores no he podido encontrar lo propuesto por maki, pero seguramente sera muy similar a lo que ofrece swissgeo, o a los esquemas que puedes aplicar en QMapashack. En cualquier caso es muy importante hacer varias diferenciaciones, y afinar mucho en el rango entre 30-40 grados. Para entender bien su proposito y el objetivo, la lectura dehttps://www.mendiak.net/viewtopic.php?f=33&t=45214&sid=840fff9b0768ba3a35777796f4b6c676"> este hilo en mendiak.net es muy util. Orux comparar tu algoritmo con lo que ya hace Qmapshack tb puede ser un buen banco de pruebas :-) Supongo que ya lo tienes mas que fichado pero por si acaso, el proyecto con su codigo estahttps://bitbucket.org/maproom/qmapshack/wiki/Home"> aqui



espero que la aportacion sea util y si hay que probar mas cosas no tienes mas que decirlo.



--------------



Hi all I am a skitourer too. :-) I am used to work with coloured DEMs to plan my routes since Qlandkartegt added that feature five years ago, and I agree with maki. I find this is a work to do at home, before you leave, and for this task a desktop app is the appropiate tool. However it would be nice if Orux adds this feature too, and it will become useful if you are away and you have to modify your next day plan.



So I have been playing a bit with the new beta and some DEMs arround well known areas. First impression is good, but I feel that the algorithm is NOT precise, and must be tunned.

Here are some screenshots to compare The first one is taken in Qmapshack and the second one in Orux beta.Leaving apart the discussion about DEMs accuracy, the important thing here is that both screenshots are taken using the same basemap (alternativaslibres.org - Spain topo) and the same DEM (Viefinder panoramas 1 arc sec resolution) but the results differ a lot.  I found that the QMapshack one fits better with the contour lines. I Must point that this basemap has excellent contour lines ( Spanish IGN source) so is a very good reference. I have pointed with arrows some areas that I found incorrect in the orux beta screenshot. It seems like the it was misplaced (to the south) but this not true for all areas , so I can not guess why it fails.



Orux Beta - Spanish topo  by alternativaslibres.org  with Viewfinder 1 arc sec  DEM

https://image.ibb.co/ezsdRS/Bisaurin_orux_VF1.jpg">



Qmapshack- Spanish topo  by alternativaslibres.org  with Viewfinder 1 arc sec  DEM

https://image.ibb.co/b2d2mS/Bisaurin_QMS_VF1.jpg">



Qmapshack- Spanish topo  by alternativaslibres.org  with  Spanish IGN MDT25  DEM

https://image.ibb.co/cRjKY7/Bisaurin_QMS_IGN_MDT25.jpg">



Hope it helps

[Maki]

Actually I think that calculating slope in the viewer is theoretically better as if done well it is more flexible. The problem is really what kind of available data we have, and maybe processing speed. The reason why I say pre-rendered maps are better is that those are usually made by professionals with high quality data. For example in France you have the BDALTI 75 released as open data: it is precise but coarse (75 m grid). Or you have tu use DEMs that have various problems. But you also can use the slope layer from the IGN which is calculated using high resolution LIDAR data not available to the public (not for free, at least). More or less the same thing in Switzerland, only a little part is covered by the HeliDEM project released ad open data, but you have the slope layer from the official cartography which is top notch. In Italy on the contrary we have high quality open data DTMs for most of the Alps, but no official slope maps...



As for QMapShack slope coloring seems mostly ok at a first sight to me but I never took the time to verify. On the contrary the local reading (bottom right of the screen) in my experience is way underestimated. If you want reliable results it is better to use GDAL in QGIS, taking care to verify that you are using a projection where everything is in meters.

[davidecapod]

Hi all,

I am trying to use the slopes map from DEM files (from http://data.opendataportal.at/dataset/dtm-italy">http://data.opendataportal.at/dataset/dtm-italy, 1') and "alps west" map from OpenAndroMaps to make a composite map, for winter outdoor activities.

When trying to create the composite map, if I choose the "alps west" map first and the "slopes" next, it does not work even in the map creator; if I choose the "slopes" first, it works in the creator preview, but it does not work later anyway. I only get an empty map with the "loading" icon with the 2 circular arrows.

What am I doing wrong? Using OruxMaps 7.4.12.

Thanks

Davide

[davidecapod]

I made it to work. Just deleted the raster cache and now the slope map (normal and composite) is working properly...

[petris]

Hi! Is it possible to configure what and how angles are highlighted or at least display a legend how is it done?

[davidecapod]

Trying to bring up this old topic:
what are the angles currently used by oruxmaps to draw the various shades of colours in the "slopes map"?
Thanks

[Haldo]

<r>Hi all,

I am trying to use the slopes map from DEM files (from <URL url="http://data.opendataportal.at/dataset/dtm-italy">http://data.opendataportal.at/dataset/dtm-italy</URL>, 1') and "alps west" map from OpenAndroMaps to make a composite map, for winter outdoor activities.

When trying to create the composite map, if I choose the "alps west" map first and the "slopes" next, it does not work even in the map creator; if I choose the "slopes" first, it works in the creator preview, but it does not work later anyway. I only get an empty map with the "loading" icon with the 2 circular arrows.

What am I doing wrong? Using OruxMaps 7.4.12.

Thanks

Davide</r>

I'm using DEM data downloaded from the opendataportal (sonny's 1")
But I saved them in the DEM folder and using them to retrieve elevation from DEM file

I do not understand how you are using composite map  with those files

Having representation of the different slopes would be useful for ski tourer

The optimum output would be what the Ortovox app is doing

https://play.google.com/store/apps/details?id=de.alpstein.alpregio.Ortovox

Any chance to have the same in Oruxmaps?

[Lenz]

Hello Haldo,

you have to create a slope map from the DEM files (global settings - maps - DEM based maps - slope maps). This slope map can be used to create a composite map with e.g. a map from OpenAndroMaps (switch maps - composite - +).

[Haldo]

Hello Haldo,

you have to create a slope map from the DEM files (global settings - maps - DEM based maps - slope maps). This slope map can be used to create a composite map with e.g. a map from OpenAndroMaps (switch maps - composite - +).

Thank You !!!!!