Messages

[JPEG/PNG compression]

JPEG/PNG compression
I'm surprised by your discover, nice. Check topic and mainly my post here: https://help.locusmap.eu/topic/sqlite-maps-compression-png-vs-jpeg#comment-26019 . It explains all.

Agree that with new rescale of raster maps, this topic may be re-open to the discussion.

Thx for the link, interesting. However, it's 3 years old, so I have the feeling that especially the comparison might not be up-to-date. I was also just thinking, that perhaps now WEBP should be considered as format. It's developped and endorsed by Google, so I assume the Android support should be good and is more likely to be improved in terms of speed and efficiency in the future than the others. What do you think?

[@slarti76]

Menion, don't worry about long post, appreciate the extensive reply!

@slarti76
texts are drawn on the tile so yes, the mentioned topic is a problem because of this. In latest MapsForge versions are some attempts to render texts separately, but how exactly it works and mainly if this may be used by maps like Locus Map: do not know yet. Anyway, texts are still drawn directly into the tile. What you see is a small alpha effect I made, that just do small interpolation during drawing between old and new map tile.

I see, makes sense looking at it again. I totally see the technical difficulties here, it's just - as the comments in the Idea also show - one of the few aspects where Locus is really not state-of-the-art anymore.
Then again, point icons are always shown "upright", so there is a layer above the tiles that is updated all the time. Can't the texts go there?

"Increase map resolution" should have the same effect on both raster and vector maps. You see a difference there? Weird. Maybe raster maps look sooner little blurred. It is as I wrote to Michael before. Raster maps itself are already little scaled by device DPI.

Yeah, I still didn't do a direct comparison, but my gut feeling is also that raster maps look worse.
Which brings my to a question I always wanted to ask: How are tiles stored when you do "Download Map"? As JPG? Because I have a raster map that was created by someone else which looks much better when zoomed compared to Google Maps downloads by Locus. With the latter, I'm pretty sure I see JPG artifacts, whereas the other map probably uses PNG.
Is that correct/possible? Would it perhaps make sense to offer a PNG option for the Map Download? Shouldn't be such a biggie, the libraries are all there in Android. Maps get bigger, I presume, but phones with SD cards don't really have a problem there...

(Also to John's post): it is correct that the visible area remains the same. Usage of this feature is to see bigger content in the same area. So rescale maps by 200% result in using lower zoom level scale to 200% (to keep same visible area).

Anyway as I see, John is correct that result is ok for raster maps, but not exact for vector maps. Most probably because the road in lower zoom level X is thinner than in next zoom level Y, so "road width X times 200%" is not same as expected "road width Y times 200%". Hmm, an alternative solution should be using still the same zoom level rescaled by X% and display a smaller area

(also to Johns answer) While I like the current effect with vector maps, I do see his point and would actually prefer if both map types behave the same way here.
But tell me if I got the behaviour of "Increase Map Resolution" correct:
With raster maps, you take a tile and just enlarge it by X %.
With vector maps, in the old system, you also render a tile at 100% and then enlarge it.
With vector maps in the new system, what exactly happens? Is there still enlarging (with loss in precision/resolution) involved? Or is it always rendered with best precision?

In fact, two factors involved. Example for 250%:

• 1a) Take current zoom level and multiply all sizes by 2.5
• 1b) Take closest zoom level (here: +1) and then multiply all sizes by 1.5
• 2a) Keep field of view identical to 100%
• 2b) Make field of view smaller by factor 2.5

Right now, it seems to be 1b)+2a), John proposes 1a)+2b), do I understand that correctly?

Clickable POIs are a little funny. I noticed this also a few days ago. It is not my intent, it is more a side effect that happens if you enable LoMaps and then any other map. Anyway, I found it really useful so maybe we may consider adding LoPoins into side menu > layers and allow to enable/disable them independent on LoMaps? Hmm ...

Please do that! Much simpler and less in-your-face (smaller icons) then having to activate those POIs in the POI menu. Always wanted to be able to use the POI the same in all map types.

Exclude certain maps from "quick map switch" ... the ideal candidate for voting? (mainly because it's not a 5-minute task)

Fair enough, will do.

Lastly, @scale belo 50%:
I see your point about 10% and the "good name protection", I just think for both cases, not allowing it at all is too much of a restriction, what with modern fast phones. My personal compromise suggestion would be 50% minimum for a) and 25% for b).

sorry i´m a old man

I really like the "tilt" feature.

where to find and how to handle??

Don't worry, nothing about being old, it's just not "advertised" at all. And it's no setting, just double tap and move fingers up or down. Actually kind of a "standard" gesture used by other map apps, too. As I wrote, should be explained to users.

@slarti76 But wouldn't you expect road widths to increase in the same way as texts do?

Tbh, I find the way it currently behaves quite balanced - I do think that road widths have to increase, too. When I choose "Increase resolution" (or whatever we call it in the end), I want to be able to also better see small roads/tracks. So say your feeling is right that when texts increase by factor x, widths increase by sq(x), to me, visually, that looks good. Apart from the fact that I chose 250% and am pretty sure that even texts only increase by factor 2. But it is kinda confusing (why not everything with same factor?) and will have to be according to some fixed rule (what element uses which f(x)).

I'd just noticed the same issue with "increase map resolution" on a vector map. If I lock the zoom then magnify the map, everything grows in size, which is correct and expected. If I "increase map resolution" to 200% the texts grow by 200% (linearly) but the map otherwise goes to an enlarged  version of the next lower zoom level, displaying exactly the same map area. The road widths are only slightly greater.

As I wrote above, I also think the factor is wrong - but the fact that the map area is unchanged to me is exactly as expected. Actually, that's what I ind great about the new system, the decoupling of two different aspects: Zoom (determining what area is shown) and resolution (size of the elements on the map). Also as I wrote, "resolution" may be a misleading word, because now with vector maps, we always have, one could say, ideal resolution. So perhaps for vector maps, it's also rather "enlarge map content sizes" (while for raster maps, it's "enlarge map"). Doesn't roll off the tongue that easily, granted...

My first thoughts of the new system:

• Vector maps look much nicer
• Overall feels slower, also had the odd crash, but mostly some missing tiles. Is to be expected, I suppose, but stability has to be improved.
• "Increase map resolution" on vector maps muuuch better due to not just enlarging the tiles. That said, it is a little confusing: My standard setting was 250%. But not all elements seem to be zoomed by 2.5. Streets get only about 50% wider, labels are perhaps double the size. That's at least confusing. Furthermore, now that vector and raster maps are handled differently, "map resolution" seems not the right term for both operations. For vector, resolution may be right, but for raster maps, it's more an "enlarge map".
• Clickable POIs from my vector maps now also appear on my downloaded raster maps. That's kinda nice, but I don't see where that could be turned off - icons may overlay icons within the map, which is not great. Also, icon size seems to be fixed.
• Love the fact that you can now overlay anything other anything. I had some overlays that I couldn't use before (like hiking trails), which work great now. However, now that I copied them back to my phone, they clutter up the "Quick Map Switch" menu. As they're only overlays (with alpha channel), they make no sense to use on their own. Please add a flag to mark a map  as "overlay only". Or at least a "Don't show in Quick Map switch".
• Like the tilting, but as I wrote in main thread for current version, user should be somehow informed about the functionality. Easily confusing.
• The "zoom lock" restructions also bother me a little. As I wrote in main thread, I think user should not be restricted for no reason to zoom to lower than 50%. Sure, things get slower, but that's up to the user to decide whether it's OK still. On my HDPI devices, I love the overview+details I can get by zooming out with zoom lock.

Apart from that, I must admit, the whole MapForge V3, V4, V5 discussion has me confused. By now, I seriously wonder if I'm missing out on functionality that would be possible if I just used the right maps/themes. I can't even seem to figure out what the default Locus Maps + Internal Themes combination uses. Perhaps it doesn't matter much, but I'm wondering if I would gain a lot by using OpenAndroMaps plus their themes again. Perhaps some Knowledge Base article would be nice together with the next version - or did I miss something?

I stumbled upon the new Quick Action Menu. Did I miss something or has that not been mentioned here/in the release notes? I like it, but when is it planned to go live? Does look basically ready to me...

Hmm to be true, I see no simple solution here.
The current system as is, is itself a lot better than was before. Anyway, in these cases, when the text that appears in the second tile should be drawn over already visible map tile, it is a problem. For now ...

Correct me if I understand the current system incorrectly: Everything is rendered "by tile", including texts. So this would also be the reason that https://help.locusmap.eu/topic/vector-maps-dont-rotate-labels-and-icons is difficult to do? Or is there any chance this will be easier with new system? I noticed that in new beta, when zooming in and out, text labels usually appear after the rest of the map, implying they're now rendered separately?

I really like the "tilt" feature.  But I suspect more people will accidentally activate it, then wonder how to reset it back to normal.

Maybe it could be a simple on/off setting, and in the UI beside "Rotate Map"?  (Then I'll know I've got it tilted the maximum; I'd never want it half-tilted.)

With me, tilt was activated after first start, was wondering if that was a mandatory feature now. Then it was suddenly gone, didn't realize why and how and wondered how to get it back. Menion, this desparately needs some information popup or the like.

Anyway, "half-tilted"? I can only seem to get Full or None, no steps in between.

[@slarti76]

@slarti76
hmm I see where this "toast" appears, but to fix it correctly, I need to know steps to simulate it. It should appear only when you try to do something and by some accident, no trackpoint is selected (so it should work only as a rare warning in case of a problem).

Ok, will keep an eye out. Perhaps the toast does make sense after all, but it could also be related to the fact that I edited on a rather slow phone, I think it happens more often (or only) on that. Perhaps some race condition...

[@slarti76]

@slarti76
funny comparison to Word . Oki agree, messages removed.

Great, thx! Always happy to make a convincing argument

"To edit the track, tap it" message also inform that there is no activity running. I do not see a problem with this message to be true.

After writing this, I realized there's two of those: There's a banner below the header that has this message, which takes away a little bit of screen real estate, but OK. Wouldn't mind it to have an "X" to close it on my small outdoor phone... No need for storing a default setting there, just that you can remove it once per session.
But there's also a toast with the same message. I actually don't know quite when it appears, but I assume it shouldn't be too hard to find in the code. It's orange, I think. If there's already a banner, there's no need for a toast, is there?

I reported that before: Almost every action in the track editor leads to a "Process successful" message that stays on for several seconds, which is far too long and covers the < and > buttons. I think you only removed this for "Delet point", but not for the other operations.
Honestly, I don't see the need for this message at all - the user can see the result of all these actions immediately. If I delete a text in Word, it also won't tell me if it succeeded, only if there was a problem.
If you still want to keep the toast, please make it smaller so that the back and forth buttons are usable again immediately.

PS: Also, I again and again get the "To edit the track, tap it" message. Why? Been using the editor for hours and still get it.

Hello slarti76,
hmm, what is your settings > maps > advanced features > Increase map resolution?
Seems this setting affect lower limits of "zoom lock".

Yeah, I got that activated.

I believe that in the special alpha version we test here on the forum, this issue no longer exists.

Didn't have the time yet, but will try out on the next version.

Dunno how long it's been like this, and if it's a bug or a feature:
When I lock the zoom level and zoom out, I cannot zoom out below 100%. Some while ago, it was possible to zoom out to <100%, so you could see a bigger area of a more detailed high resolution zoom level. Granted, at some point the repainting of the tiles got reaaaally slow, so I can imagine that might have been a reason to disallow it. However, I think it would be unproblematic and still usable if it's at least allowed to zoom out to 25%.

In the track editor, when I e.g. delete points, there's a big green "Process successful" toast.
a) That's pointless - I can see that the process was successful. Only makes sense to show when something goes wrong.
b) It stays on way too long, and as long as it's there I can't use the < and > buttons. Slows quick deleting of track parts down a lot.
I don't know if that's new in this version, but it wasn't like this from the beginning.