Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - LaurentG

#151
Yes, I have the very last versions....
#152
Hi,



thank you for answer.



I have a little bit more info about the issue : Actually, there is NO issue if "default Mapsforge theme" is chosen. In such a case, if specific "hillshading" option is selected, hillshading is applied.... and rendering is VERY VERY slow. If only new option is selected, hillshading is also applied, with almost no impact on rendering speed.

And if both option are selected, hillshading is applied, apparently only once (not more "dark" than with only one option selected), but it seems to be, as you mention, the "specific one" which is applied, since huge slowness of rendering.



BUT if Elevate, or Element, Or Tiramisu mapsforge theme is selected (three well known themes promoted on OpenAndroMaps), then behaviour is (and remain after map reload) as mentioned in my initial post.
#153
Hi,

thank's a lot for new 7.3.2 version, and in particular for the ability to apply Hillshading to any map.



But at this purpose, I have to raise a little bug.

Before this version, it was possible to have hillshading specifically on MapsForge maps, thanks to option

   Global settings/Maps/MapsForge settings/Apply hill shadow



Now, with 7.3.2, if this box (specific for MapsForge) is unchecked, then the new "global" option works fine whatever maps type, including MapsForge maps, but if this box is checked, hillshading is NEVER there in MapsForge maps, whatever the value defined for the new "global" option (which on the other hand continue to correctly drive hillshading of non-MapsForge maps).



Rather than "Apply hill shadows using mapsforge built-in capabilities", real behaviour of this box is actually "Never apply hill shadows to mapsforge maps"  :D



Regards

Laurent
#154
ERRORES/BUGS / "Migrate to Ext. SD" failed
August 09, 2018, 03:03:52 PM
Hi,



just after installing OM 7.3.2, I noticed the option "Migrate to Ext.SD" (maybe already existed, but I never noticed it before...), and I tried to use it.

But unfortunately it failed...



First of all, let me say that on my smartphone, Mapfiles were already on the SD card (I manually set them a long time ago), and then an Oruxmaps directory, with only mapfiles as subdirectory, already existed on SD card.

And I'm running Android Nougat (7.0)



But when I used the option, rather than copy/move subdirectories of OruxMaps from phone to SD card, it created for each file to transfer a specific directory, OruxMaps1, then OruxMaps2, OruxMaps3, etc... , with only one file in each...



It's not really a problem, since I repaired all of that myself manually (I initially backed up the original directory....), and changed manually in various preferences/options the location of various subdirectories (some were already changed, apparently thanks to the "migrate", some remained pointing to phone memory), and now everything works fine, but I guess that some users are not skilled enough to do any manual repair....



As a result, for them, this option could be very counter-productive.... while it is not really mandatory for "skilled users" who are able to play the game "manually".



As a result, I'm wondering if it would not be "less risky" to remove this option, or at least, display a "big warning" : use it ONLY if ....



Second "issue" : I've been surprised to see that even now that sub-directories are defined in preferences toward SD card, when launching OruxMaps, they are automatically re-created on phone : customwpts, dem, mapstyles, overly, pictures and tracklogs. Except customwpts, they remain empty and seem to be not used, but why create them ?



And last (but not least ?), even when mapfiles is defined on SD card, mapfiles directory from phone is used for online maps. Why ?