Messages

Beta 11 multimaps are broken for me. The old ones I had created disappeared and I can't create new ones, they are not saved. Or they are saved but not shown, in any case I don't see them.

I don't understand the zoom limits in the multimap creation phase. Why am I limited to ZL 16 for the slope map and hillshade? Makes no sense, it's common to upsize hillshading.

I briefly tried beta8 on a GPad 8.3, so not exactly a high end device nowadays and the new algorithm is plenty usable wit 1 arcsec DEMs. I just have sometimes some random tiles that take a few seconds to appear. I suppose that some things are strongly device-dependent.

The new algorithm is much better but I still see errors at tile borders. Looks like the calculations are vectorised, looks nice but there are arguments in favour to use the raw pixels with nearest neighbour interpolation (mostly not to give the user the impression of a higher than real precision): I'm agnostic in this, my maps use a 5 m grid and a continuous tone variation so I just don't have the problem. Maybe let the user choose between the two if possible.



Please, pretty please, do not tell the user "if you touch this you need to flush the cache", just do it as soon as the preference change is confirmed.



The measure tool is exactly what I expected, except for the use of % as slope unit. % works well when dealing with low inclines and as such is used on roads, but on slopes we commonly use degrees, at least in the ski touring/alpine world where the request was born.



Please also have a look at the dedicated thread about slope map request.



Thanks,

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.

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.

On desktop you can use QGIS, or JOSM. To merge mbtiles created with MOBAC I use this script for SQLITE.

Code Select Expand

REM based on 'patch' here: https://github.com/mapbox/mbutil/blob/master/patch

@ECHO OFF
REM goto CATCH
REM %1 = source database
REM %2 = destination database
echo PRAGMA journal_mode=PERSIST;PRAGMA page_size=80000;PRAGMA synchronous=OFF;ATTACH DATABASE '%1' AS source;INSERT or REPLACE INTO tiles SELECT * FROM source.tiles; | "sqlite3.exe" %2%
GOTO FINALLY
:CATCH
echo there was an error
:FINALLY

Depending on the viewer you may need to adjust boundaries by hand with a db manager, I use SQLITE Browser.



I don't know about mixing jpeg and png, but I know that with RAMP you can't use PNG at all.

MBTILES works really well in OruxMaps, and can also be used as a local map in MOBAC to subsequently re-export in other formats, so my advice is to use it as a base when downloading maps with MOBAC. If anything you can convert it to other formats later.

The TwoNav RMAP occasionally gave me problems in OM and Jose  confirmed it is a bit problematic at times. On the other hand it works on desktop with TwoNav Land (free and paid) and in QMapShack, an interesting open source option (a bit complex at start, but if you follow the documentation it isn't difficult).

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.

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.

"F-Droid is an installable catalogue of FOSS (Free and Open Source Software)"



OruxMaps is not FOSS

I found two problems using regular Donate version, I suppose it applies to beta as well (I currently do not have it installed).



1) Installed from scratch, tried to record a track. Correctly it asked for permissions, then silently did nothing: I had to tap again on "record track" button. It should do it automatically

2) I stopped track recording from the notification. I have set up the app to automatically save a GPX, but it didn't happen. I had to export the track manually.



Additionally, the app adds a timestamp at the end of the filename when saving the GPX. I can understand the logic when automatically saving without a filename, but if I'm giving the track an explicit filename it makes no sense to me.

I tested again mbtiles after reinstalling 7.x Donate and beta on the tablet since I had removed them. On the phone I always had 6.5 from website, Donate from the Playstore and beta.

On the tablet moving to an area that I had not visualized before I actually see the spiral pattern. When zooming in and out in the same area half of the times I don't see the spiral but rather most of the screen drawn at a single time, without lags, so it's probably from the cache. Behavior is consistent across versions, except 6.5 is much faster at start. Once loaded speeds are similar

On the phone 6.5 has a similar behavior to the tabled, it' just faster (normal, the device is faster), panning is totally fluid and fast. 7.x (beta and donate) are very strange. If I move to an area that I had not visualized before I clearly see the spiral pattern. After a few zooms in and out I get the same behavior of the tablet, but with a lag between the moment I release the fingers and the moment the map start drawing. It's a few tenths of second but it's noticeable. Panning is even worse. In general the behavior is like when zooming, but I get an additional jump when I lift the finger while still moving. The map starts redrawing, than it moves a couple of millimiters further and it finishes the redraw. I'd question the device, but since 6.5 runs fine I think some minor detail must have changed.



About Spatialite. I never tried the feature before so I gave it a go. Personally I find it very difficult to use, selectiong a category

from the list is uncomfortable at best. The list is too huge. Making the checkboxes default to "on" woulbd be a big improvement. Also it

seems that thicking one macrocategory doesn't actually tick subcategories. I know queries are expensive, but scrolling and selectiong

categories is too.

Then I don't see why Spatialite is necessary for this kind of search: it looks like you search a name and you get coordinates, but those can be stored in a plain sqlite database, no? I'd understand if we could set a search radius or geofence, but we can't. What am I missing?

I'd also like to have this search function available for other maps, as far as I understand POIs and map files are not related.



Dashboard, buttons and theme. In beta 9 the missing border between controls is now ok when using solid colors but disappear when using the transparent dashboard. I still see the Android bottom bar popping up when opening a menu, pretty annoying... 6.5 did it too, but I'm rather sure that at some point it was fixed. Also the dashboard gets closed when swiping up to reveal Android buttons, this one is fossil and pretty annoying as well. In current Donate version buttons inherit color from app theme, in beta they inherit it from the dashboard. Of course I liked light buttons and dark dashboard... :-)

Preferences are now a nightmare. When you change the "custom dashboard/buttons background" (which BTW is too long to fit on screen) nothing happens because you also have to select "customized" from the preference above. As a minimum the setting should be grayed out when not used; or, always use the color picker and forget about light/dark preference. And you can also select white text on light background, or black on dark, which is totally invisible. And to add confusion you can always bypass all of this and tie the dashboard theme to the app theme via a checkbox... Why not replace the whole thing with just three settings?

• App theme: light, dark, red

• Buttons theme: light, dark, transparent dark, transparent light

• Dashboard theme: light, dark, transparent dark, transparent light

Fast, easy and should cover everyone needs without conflicts and confusing nested preferences.

In any case dashboard background "clear" should be "light", "clear" usually means "transparent".

I also see now that an old bug come up again. When in immersive mode opening a menu on the action bar causes the Andorid soft buttons to show, like in 6.5

Do you talk about all maps formats, or only with mapsforge maps? The change in mapsforge is that in version 7.x the construction of tiles is multithread, and in version 6.5 it was a single thread. That's why you see that the tiles are drawn in spiral in version 6.5. I do not know if you include other options, such as drawing shadows, ... but that may also affect performance in multithreading mode.

No, at the moment I'm only using mbtiles (no multimap, hillshading or other fancy stuff).



By the way it comes to mind that sometimes after updating I see random tiles missing here and there. Clearing the caches from the preferences always solved the problem. In theory it shouldn't be related because it's offline maps and I don't expect them to be cached. However I notice that the first time I visualize a certain area it is slower then when I go there again after a while, so maybe you are caching offline maps too? Or is it some Android filesystem cache?

exit-> exit the tutorial

got it-> go to the next tutorial screen

Sorry for the misunderstanding. To me "Got it!" sounds like "OK", I think "Next" would be a better wording.

The capabilities of the phones have increased greatly. In the beginning the apps had to work on 16mb of heap. Now they can use up to 512mb, depending on the tlf (32x times). 55mb is few, considering this evolution. The speed of the processors has also increased a lot.

I know technology advances and I don't want to stop that. My devices are three years old, but still they have 2 GB of RAM, which is now the standard for mid-range, cheaper phones do have less even today. What I experience is that switching back and forth between Firefox and OruxMaps on the tablet I often have to wait for OM to reload. It's just memory consumption, not processor speed, and doesn't happen with 6.x.



What I really meant to say is that traditionally OM has been able to run fast on older/less powerful devices without resorting to old versions. I bought my Galaxy Nexus in late 2012, I changed it in 2015 because it wasn't up to the task of web browsing anymore, but OM was still flying on it. I then bought a Moto-X2 and two years later the only app I feel is slowing down is OM. It's still plenty usable, but noticeably slower and heavier than before. Maybe the screen is just drawn differently, but it's more "jumpy". In 6.5 it looks like the screen is drawn from the center in a spiral fashion; in 7.5 it looks like the whole display is built offscreen and then shown at once, which means that even if it takes the same time to have a complete redraw you see a bigger lag.

The app apk now uses much more memory because it includes the native libraries for geopdf map support  (17mb), which is an excellent format, increasingly used, and especially due to the weight of the spatial sqlite libraries to support mapsforge poi databases (28mb). Having to support android in different processors (arm, x86, ...) affects the package sizes that are created. Anyway, this should not affect the performance of the app.

You know, that's the point... every new option or new supported format increases weight and complexity. But when I look at friend's phones most people just use more or less the default setup, with the usual 4Umaps, OpenTopo or OpenAndroMaps. Is it worth supporting so much stuff and having so many options? We have SHP, but it's not even a map format, just pure data... GeoPDF is indeed excellent and I dream about it, but last time I checked there was no free tool to build maps (or at least not to a point that takes advantage of the format capabilities); so I don't expect a lot of free maps to be available any time soon and commercial maps are behind paywalls so we are unlikely to be able to use them. Now you tell me that half of OM weight is due to a single feature (spatialite)... it's an interesting thing but I'm not sure it's worth the cost: are you sure there's no lighter alternative? spatialite.exe on my PC is 13 MB, still a lot but much less than what you indicate. Of course one can go back to 6.5 but the the interface improvements are lost... Cannot the advanced stuff (exotic formats, external sensors, web services support...) be put in a couple of plug-ins?



Anyway, I just installed Beta8. With the light theme the buttons are dark and the lines that separate the dashboard controls are transparent (I see the map moving behind). I liked it better before.

I tried the latest beta yesterday and I'm a bit disappointed. The waypoint creation dialog box has changed for the worse. The new help button is in the same place where we had for a long while the OK button. It makes no sense; for starters muscle memory continues to move the finger to that point, a new button should be in a new place. Then, what is this supposed to be useful for? Really, the help message adds nothing at all. The dialog box is self explaining, it's totally obvious that you have to fill the properties. And finally what is the difference between "got it" and "exit"?



Things like this just contribute to make the app even more bloated, I think this is going out of control. Latest beta is using 55MB in my internal memory, version 6.5 just 11 MB. Latest beta (or Play Store version) takes 6-7 seconds to launch from scratch on my Moto X2 and even more on my G-Pad 8.3 while 6.5 loads in no time, and zooming and panning are much faster in the older version. Basically from 6.x to 7.x app size has grown 5 times, but we don't have 5 times the features we had before.



I'm sorry to be so critic, but I'm really wondering where OM development is heading.