Author Topic: Re: [APP] - version 3.38.+ ( 22. 5. 2019 ) (Read 55303 times)

Menion · « **Reply #180 on:** June 13, 2019, 16:08:35 »

New version 3.38.4
- mainly fixed major problems

@tapio
correct, I still believe current behavior works correctly. As I wrote, there is a need for one tiny change that causes a little trouble for me. If you set 150% to magnify, the app just needs to do zoom by this 50 % (like by fingers) and then all will work as expected. Anyway, let it be for now, I'll invest more time to it and in next Beta ...

Problem with white areas reported by you and Josef are still not reproducible by me and colleagues, weird. Will need to play with it a little more.

@Tom
perfect you found reason. It means I should be able to simulate it. Weird is that Locus do not search in HGT files and mainly in zoom level on your video, shading should be completely disabled! (it should work till level 8+)

erfi · « **Reply #181 on:** June 13, 2019, 20:12:17 »

New version 3.38.4: This problem still exists: after the automatic map change (OAM v4), the map name in the upper panel (top panel) is not updated.

Menion · « **Reply #182 on:** June 13, 2019, 20:21:56 »

This is correct. With V4 maps, app has no idea which map is used, so always first selected (primary) map is displayed in the top bar and also in map manager.

Tom · « **Reply #183 on:** June 13, 2019, 21:19:59 »

Hi Menion,

Quote from: menion on June 13, 2019, 16:08:35

It means I should be able to simulate it.

Note, that my SRTM data is on an external SD card (SanDisk, don't know the exact spec). IMHO SD cards are much slower that the built-in flash memory.

Quote from: menion on June 13, 2019, 16:08:35

Weird is that Locus do not search in HGT files

I guess you compute the HGT file name from the coordinates of the visible location and then just try to open the file. So, I think it is the file system itself that slows down, when opening a file in an directory with a huge number of inodes.

Quote from: menion on June 13, 2019, 16:08:35

mainly in zoom level on your video, shading should be completely disabled! (it should work till level 8+)

Totally agree with that proposal.

Best regards,
Thomas

slarti76 · « **Reply #184 on:** June 14, 2019, 08:27:25 »

Quote from: menion on June 13, 2019, 16:08:35

@tapio
correct, I still believe current behavior works correctly. As I wrote, there is a need for one tiny change that causes a little trouble for me. If you set 150% to magnify, the app just needs to do zoom by this 50 % (like by fingers) and then all will work as expected. Anyway, let it be for now, I'll invest more time to it and in next Beta ...

It's slarti76

Nevermind...
Tried out 3.38.4. First tried with 200% and 300%: Absolutely identical maps displayed. Then tried out 150%: No change between 100% and 150%. Then, as you hinted at, zoomed out and in again: Now it looks like it may be 150%. Tried out 200 and 300 again: Now there was a difference.
At last, tried 400%: Different to 300%, but muuuuch bigger.
Now I noticed the percentages shown in the top bar. At base resolution (no magnify), it showed "200%". Ok, probably a result of the DPI calculation, whatever. With magnify to 300%, it showed "500%" (which is 2.5x=250% magnification). At 400%, it showed "1000%" (which is 5x=500%).
No it struck me: The problem here is, I think, that my map doesn't have linear zoom levels, the highest levels are "1:50000", "1:25000", and "1:10000". I assume that when I'm in the "1:10000" level, that messes with your calculation, as you expect the lower level to have half the resolution (1:20000) and calculate the level to be used for magnification and the enlargement of tiles based on that - which has to fail.
With a Google map download done by Locus, I don't have those severe discrepancies, but there's also no difference between 250% and 300%, for example.
Also, when I zoom in more than the highest zoom level (one or two additional taps on "(+)"), I'll still get to a point where Magnify has no effect.

So in summary:

The algorithm seems to break down when the map's zoom levels are not 1:2
Magnifications between full 100% steps are sometimes a problem*
Magnifying when already magnified in highest zoom level doesn't work
Sometimes magnification is not applied directly, only after another zoom in/out

* I think it would be no loss to get rid of the 25% steps, and also all 50% steps after 200%, but at least 150% should work.

Hope this helps.

PS: Good news: Didn't have any blank screens anymore

T-mo · « **Reply #185 on:** June 15, 2019, 11:40:23 »

Hello Menion,

Locus Pro 3.38.4: https://drive.google.com/file/d/1RJWHloh9xr4udLfdUrPFxeo0tNw5B49H/view?usp=sharing (~54MB, 2:03min)

1st: raster map, my special one with Z13 + Z16 only

2nd: vector OAM V4, Germany South ML + Elevate theme

let's concentrate on the raster map

I guess you manage it the way that the DPI-awareness (optimise map resolution) defines a certain %-zoom-view, here my minimum-%zoom is always 150% (if I use magnify (not shown in the video) this value changes to 150%*magnification). I don't understand this hard-limit if I am at lowest Z-level (13) and want to change %-zoom to a lower %-value than 150%, not possible currently?! Scaling the last-available-Z-level should always be without any limitations in my opionon - Z13 should be zoomable down to some-% and Z16 should be zoomable up to infinty (1px/Screen) I guess this is more a mistake than intended..
maybe this explains the white no-view-available zoom-transitions from Z16-150% in direction to Z13. Values lower than 150% seem not to be possible, available..
changing the std-values-%-zoom is in my opinion a bit irritating as I often orientate to Z-levels and 100%/ 50%/150%/200%..often used zoom-values of mankind, not sort-of-strange values. Maybe it's better to stick to those values and leave some zooming-calculation under the hood, like this is already the case I guess.

john_percy · « **Reply #186 on:** June 16, 2019, 01:18:34 »

Fresh installation on new phone, UK locale, TTS language is set as Czech. Can you not use system settings?

Sent from my moto g(6) plus using Tapatalk

Henk van der Spek · « **Reply #187 on:** June 16, 2019, 09:49:57 »

Same here after update. Quite funny.

balloni55 · « **Reply #188 on:** June 17, 2019, 14:06:18 »

if the distance between map cursor and target becomes too small depending on the zoom level, the values are no longer displayed.
If I remember correctly, in the past the values were displayed on the other side of the map cursor in this case.

Menion · « **Reply #189 on:** June 17, 2019, 20:06:20 »

Sorry for a delay in my responses. We never had so much support to do and with Michal, we do it almost non-stop :/.

@slarti76
I reacted mainly on the previous post from @tapio: https://forum.locusmap.eu/index.php?topic=6579.msg55898#msg55898

Anyway thanks for your long post. Seems I'll really have to write some blog post on this topic and explain it a little bit. What happens to you is perfectly correct and expected behavior. At least I wrote it like this. I'm aware it needs a minor tweak to make it work as you expect so I'll try to improve it till next version and you will see.

@Tom
so I've downloaded more than 3.000 HGT files and ... issue simulated

@T-mo
scaling of the lowest level will be improved in next version, I already noticed this as well and agree. Anyway optimal way of displaying zoom level is not yet done. I'll have to think about it little more, but old zoom value are from my point of view useful for "geeks", but average user lives in the world of directly visible scale (like "this line" is 300 metres) or in older system of paper maps (1:25k, 1:50k etc.).

@john_percy, @Henk van der Spek
the interesting problem mainly because the Czech language has no priority in the app, all is made in English only. Was then possible for you to change it and use the correct language?

@balloni55
hmm, it is possible. I made some improvements because very often, the text was shrunk or weirdly modified. Now app check available space more precisely and if there is not enough space, the text is not drawn. In this case, you still see distance at the top

john_percy · « **Reply #190 on:** June 17, 2019, 20:15:40 »

@menion: I changed the TTS language to English in Locus which then gave me a weird US computer voice, and I then had to change it to UK English in Android settings. I didn't investigate further but I wouldn't have been satisfied with the weird US voice even if I was American.

Sent from my moto g(6) plus using Tapatalk

Menion · « **Reply #191 on:** June 17, 2019, 20:20:22 »

And you previously had US English in your device?

There were no changes regards languages in Locus Map except one serious change in app distribution: Locus Map now uses so-called "app bundle". The result is that when you install the app from Google Play, Google Play prepare specially for you smallest possible APK file optimized to your device with only single language bundled in the app: the language of your device. Maybe it has some side-effects here ...

balloni55 · « **Reply #192 on:** June 17, 2019, 20:45:45 »

Quote

In this case, you still see distance at the top

i know, but my values are twice as big and that's important to see it clearly in sunlight.
On the opposite side of the map curser there is enough space to display the values.

Menion · « **Reply #193 on:** June 17, 2019, 22:42:39 »

I was worried you will write it

Henk van der Spek · « **Reply #194 on:** June 17, 2019, 22:58:07 »

Quote from: menion on June 17, 2019, 20:06:20

@john_percy, @Henk van der Spek
the interesting problem mainly because the Czech language has no priority in the app, all is made in English only. Was then possible for you to change it and use the correct language?

After the update to 3.38.4 and following first start, Locus spoke Czech (in navigation). My device is standard on Dutch.
I then switched the language setting in Locus to Dutch and then the voice sounded like American with a heavy Dutch accent or vice-versa.
I think I then restarted Locus (but maybe even my phone) and everything was normal then.