Cgeo: Zoom level changing when switching Google/OSM

[Lineflyer]

Describe the bug:
Some user complaints, that when they switch between Google and OSM/Offline the zoom and/or position of the map are not kept.

To Reproduce:
Steps to reproduce the behavior:

1. Have Google Map selected
2. Open a cache list
3. Map the list
4. Change map source to OSM

Actual behavior/state after performing these steps:
Shown area on OSM is significantly higher (lower zoom) than the previously shown on Google Maps

Expected behavior/state after performing these steps:
Viewport should be somewhat the same (+/-)

Version of c:geo used:
2019.11.11

Is the problem reproducible:
Yes

Additional context:
Either it is related to GoogleMapsV2 or to the recent resolution optimization implemented by @jonas-koeritz

[andrixnet]

I can confirm this. Really annoying at times.

[Lineflyer]

+many from support channel.

There seem to be quite some users frequently changing between OSM and Google which is not really usable at the moment do to the large change of zoom.

[jonas-koeritz]

I just worked on my Mapsforge Fragment and noticed that the scaling is off by the dp to px factor. Zoom levels can be mapped 1:1 between Google Maps and our MfMapView if we do this:

mapView.getModel().displayModel.setUserScaleFactor(Resources.getSystem().getDisplayMetrics().density)

This works at least for raster maps (OSM: Online), I haven't implemented offline maps in my Fragment yet but will report back once it's done.
Raster tiles do look slightly blurry on high density devices, but I am liking it better than the unreadably small before.

[jonas-koeritz]

Correction: I called that way too early in my Lifecycle, resulting in density defaulting to 1.0. Just calling setUserScaleFactor() at all (with 1.0f as factor) seems to resolve the problem for me.

[Lineflyer]

I guess it might be easy to solve. This issue is a regression after changing to GMapsV2. So I assume the gmapsv2 code is missing this.

[jonas-koeritz]

Can somebody post screenshots of the problem? Maybe I'm not facing the same
issue in my work.

Lars [e-mail] schrieb am Do., 9. Jan. 2020, 19:06:

I guess it might be easy to solve. This issue is a regression after
changing to GMapsV2. So I assume the gmapsv2 code is missing this.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cgeo/cgeo/issues/7953?email_source=notifications&email_token=ABRPLC7FFOJZDQU2FQ6444TQ45RS5A5CNFSM4JPXTKRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIRHCHI#issuecomment-572682525,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABRPLC6PCBHMFNEGDWRJKZTQ45RS5ANCNFSM4JPXTKRA
.

[Birdy2404]

Osm Offline / Mapsforge V5 (1km):

OSM Online (1km):

Google Satellit (200m):

Google Karte (200m):

Seems like 1:10 if you compare the length of the line also.

[jonas-koeritz]

That's definitely not the problem I've been facing, setUserScale() might not fix this (if all maps are at the same zoom level).

[Lineflyer]

Friendly reminder.
One of the most asked questions on support.

Quite some users seems to switch between OSM and Google frequently while on live map and complain about the zoom difference when switching.

[jonas-koeritz]

I got a hold of this problem on my device while testing a new map
implementation based on fragments instead of separate activities. I believe
that mapsforge scaling is kind of device dependent and Google Maps has some
reasonable defaults implemented. The only way I could get that to work 100%
was when I tried out Maps V3 with the mapsforge map embedded inside the
Google Maps MapView (which I didn't develop any further because maps V3 is
Beta and there were concerns about relying on a Google Library).

Lars [e-mail] schrieb am Mo., 15. Juni 2020, 01:04:

Friendly reminder.
One of the most asked questions on support.

Quite some users seems to switch between OSM and Google frequently while
on live map and complain about the zoom difference when switching.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cgeo/cgeo/issues/7953#issuecomment-643834312, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABRPLCYEHB3ZV7BH7HNVCSLRWVJQJANCNFSM4JPXTKRA
.

[geocachermgo]

Comment about use case: I normally use the offline map and occasionally switch to satellit-view to get the position in the real surrounding better.

[geocachermgo]

Remarks for me: zoomLevel modified by zoomControls?
The ScaleDrawer.java doesn't use zoomLevel but gets the positions of the displayed edges of the map.

[geocachermgo]

cgeo-master\cgeo-master\main\src\cgeo\geocaching\maps\google\v2\GoogleMapController.java

if (latSpanE6 != 0 && lonSpanE6 != 0) { // calculate zoomlevel final int distDegree = Math.max(latSpanE6, lonSpanE6); final int zoomLevel = (int) Math.floor(Math.log(360.0 * 1e6 / distDegree) / Math.log(2)); googleMap.moveCamera(CameraUpdateFactory.zoomTo(zoomLevel));

cgeo-master\cgeo-master\main\src\cgeo\geocaching\maps\google\v2\GoogleMapView.java

public class GoogleMapView extends .. {
private float zoomLevel;

geo\cgeo-master\cgeo-master\main\src\cgeo\geocaching\maps\mapsforge\v6\NewMap.java

mapView.setMapZoomLevel((byte) mapOptions.mapState.getZoomLevel());``

[geocachermgo]

Hint: There is or was a "zoomlevel +/- 3" in the files of the mapsforge-map, that (accidently) is the standard-zoom difference between Google Maps
and Mapsforge. Other cause could be the mimimum zoom level of Google maps

[geocachermgo]

Checked if the ratio is 10 or 9: Its 8:
Switched map until stable, created waypoints at the display edge:
OSM map was offline Germany
{c:geo-start}
@OSM Kartenkante Süd (W) N51 20,836 E11 25,000
@OSM Kartenkante Nord (W) N52 30,104 E11 25,000
"OSM o-u=128452.7837"
@Google Kartenkante Nord (X) N52 00,278 E11 25,000
@Google Kartenkante Süd (X) N51 51,673 E11 25,000
"Google diff =15957.4101m
OSM diff =128452.7837
Ratio=8.049726296"
{c:geo-end}

[geocachermgo]

Confirm with second set of points:
G2N N 51° 55.575' E 011° 27.000'
G2S N 51° 53.424' E 011° 27.000'
diff 3988.8721

O2N N 52° 03.095' E 011° 27.000'
O2S N 51° 45.795' E 011° 27.000'
diff 32081.5793
Ratio:8.042769609

[moving-bits]

Ratio:8.042769609

Each zoom level doubles the visible area (AFAIK), so a ratio of 8 would mean three zoom levels, which is also what I experience when switching between GMv2 and NewMap - I have to zoom out three times when switching from NewMap to GMv2 to see the same part of the map.

[geocachermgo]

If the zoom level changes by 1 when pressing the +/- button then the length changes by factor 2 and the area by 4. But I got your point now: 3 Level steps mean *8 in length. I misunderstood you meant *3 (in area or length)

[rsudev]

As I had been working on this topic already on several occasions I'd like to give some background info to ease the further analysis. The zoom level is defined in terms of the map tiles used to create the display. In Google maps V1 always tiles with 256px size were used, while mapsforge used, especially in the offline version, a tile size based on the pixel density and display size. Things might have changed with google maps V2 and the adaption of zoom levels between them (MfMapView.get/setMapZoomLevel) might no longer be necessary (for some devices?)

[geocachermgo]

main\src\cgeo\geocaching\maps\mapsforge\v6\MfMapView.java has the lines

public int getMapZoomLevel() { return getModel().mapViewPosition.getZoomLevel() + 3; }
public void setMapZoomLevel(final int zoomLevel) { getModel().mapViewPosition.setZoomLevel((byte) (zoomLevel - 3));

How do I change the files from +-3 to +-0, mark the files as not to be integrated in master, make a commit to trigger the continous integration?

[rsudev]

What do you want to achieve by that?

[geocachermgo]

I do not have a development environment and wanted to test the effect of the "3" beeing changed to "0".
Esp. if that solves the problem.

[rsudev]

Ah, ok. But in order to find out whether it really solves the problem, you would need to test on a range of Android versions, display sizes and pixel densities. BTW: Did you use an offline ore online map with mapsforge?
I can see whether I can provide a test version tomorrow.

[moving-bits]

How do I change the files from +-3 to +-0, mark the files as not to be integrated in master, make a commit to trigger the continous integration?

When you create a PR an APK will be generated automatically, which you can use for local testing. Just write "Do not merge" in the title as reminder for the team (or set the appropriate label, if possible).

BTW: Setting up your own local installation of Android Studio will make things way easier for you, if you want to dive into developing for c:geo. The software is free, and your turnaround-time from code change to seeing the effects will be reduced drastically, besides other benefits (eg.: debugging).

[geocachermgo]

Ah, ok. But in order to find out whether it really solves the problem, you would need to test on a range of Android versions, display sizes and pixel densities.

Since I'm far from understanding the SW its still more examination then solution. But if the +3 worked for all Android, displays, pixel densities and mapsforge versions maybe the +0 will to.
How is the field coverage done for cgeo?

BTW: Did you use an offline ore online map with mapsforge?

I tried both online and offline OSM they seem to behave identical.

I can see whether I can provide a test version tomorrow.

That would be really nice!

[rsudev]

@geocachermgo Took a while longer, sorry for that. The build-result of #9057 should enable you to check whether that change would work at least for you.

[geocachermgo]

The issue is almost a year old, a few days do not hurt.
Where do I find the build results? If its from the continuous integration test will not be possible since there is no key for GM included.

[bekuno]

Where do I find the build results? If its from the continuous integration test will not be possible since there is no key for GM included.

CI is correct.
All builds use the same API keys (copied from a local directory when building the apk).
Different to a developers private build. He needs own keys for his machine.

[geocachermgo]

I installed the cgeo-debug.apk from https://ci.cgeo.org/job/cgeo%20Continuous%20integration/2925/ but Google map is not working?

[Lineflyer]

Yes, thats a problem for your test. The debug.apk do not have a google maps key, therefore its "normal", that you cannot see the map. So testing in this way is not possible.

Maybe we can implement this change in the nightly and revert if required...or another dev can give it a try on his device.

[rsudev]

I cannot check it, as I don't have a gmaps v2 api key (and i am not sure if I want to give google my credit card number to get one).
Maybe we can create a new (manual) job that can build and sign an arbitrary branch from the main repo for such occasions.

[geocachermgo]

I was expecting that GM is not working with the apk from the CI, I was trying because bekuno wrote it will work.
@rsudev can you please provide a link to the build, I did not find it.
@Lineflyer thanks for support: the change is a wild guess, so I would not include it in the normal nightly.
I see that at some days there are additional nightlys eg today 9:53. How are they triggered? Is it an option to include it in an extra nightly at e.g. 0:15 so it's only there for 15 min?

[Lineflyer]

I see that at some days there are additional nightlys eg today 9:53. How are they triggered? Is it an option to include it in an extra nightly at e.g. 0:15 so it's only there for 15 min?

Those are triggered manually, In this case by myself after merging some PRs to have an earlier chance to test it.
From my point of view we can also merge it normally into the nightly. After collecting feedback we can revert it also next days..no urgency. The change is easy to revert and nightlies are alpha version, so no problem if it does not work.

[Lineflyer]

Reminder:

9057 has been merged for testing purposes.

After testing additional action is required:

1. If it works: Clean the code, leave it in for further nightly testing
2. If it does not work: Revert change

[Lineflyer]

@geocachermgo
A new nightly is ready for testing. 20200924-NB2

[Lineflyer]

Works perfect on my Galaxy S20, Android 10.

[MagpieFourtyTwo]

Huawei P30 Pro, Android 10.1 - works perfectly fine.

[Lineflyer]

PR #9061 prepared if there are positive test results.

[bekuno]

Not complete successfull.
For small area it was ok.
Then I took the are Berlin - München (top - bottom of the map).
"Google: Map" to "CyclOSM" (or another OSM map) is ok, but reverse to "Google: Map" it switch to a area with ~10km width.
(I would say it is the middle of the area before.
For a greater area (eg. Germany) the changes are greater. After the first switch the are is nearly doubled, the second switch is in the same way.

[Lineflyer]

Then I took the are Berlin - München (top - bottom of the map).
"Google: Map" to "CyclOSM" (or another OSM map) is ok, but reverse to "Google: Map" it switch to a area with ~10km width.

Cannot reproduce here. Always the same forth and back with several maps (Google, OSM Online & Offline).
What device?

[bekuno]

I was expecting that GM is not working with the apk from the CI, I was trying because @bekuno wrote it will work.

Sorry for the confusion, I was sure and could not check. :-(

Then I took the are Berlin - München (top - bottom of the map).
"Google: Map" to "CyclOSM" (or another OSM map) is ok, but reverse to "Google: Map" it switch to a area with ~10km width.

Cannot reproduce here. Always the same forth and back with several maps (Google, OSM Online & Offline).
What device?

Samsung Note 8, Android 9

[geocachermgo]

Not complete successfull.
For small area it was ok.
Then I took the are Berlin - München (top - bottom of the map).
"Google: Map" to "CyclOSM" (or another OSM map) is ok, but reverse to "Google: Map" it switch to a area with ~10km width.
(I would say it is the middle of the area before.
For a greater area (eg. Germany) the changes are greater. After the first switch the are is nearly doubled, the second switch is in the same way.

At last a little improvment. :-)
Works very well for me. 20 m to 200 km. Back and forth. gM, gm Satellit, OSM online und offline.
Device: MI 8 (dipper, Xiaomi)
Android version: 10

[Lineflyer]

Samsung Note 8, Android 9

Works fine also on my tablet with slightly different resolution in portait and landscape.
Are you sure you use the right version as your problem description sounds like the unfixed version.

[bekuno]

Samsung Note 8, Android 9

Works fine also on my tablet with slightly different resolution in portait and landscape.
Are you sure you use the right version as your problem description sounds like the unfixed version.

It shows 20200924-NB2.
Will try it tomorrow once more.

[geocachermgo]

@bekuno Any news from your testing?

@rsudev Thank you very much for the actual code change
@moving-bits Thanks for giving the hint to the zoom level +-3 change
and to Lineflyer, MagpieFourtyTwo, bekuno for support. I'm very proud that I could help to resolve this old and "high prio" issue.

[geocachermgo]

Feedback on Facebook:

[bekuno]

now tested on my regulary caching phone (also samsung note 8, android 9)
It has the same results as the dev device.

[Lineflyer]

@bekuno

Can you post screenshots please?

[bekuno]

@bekuno

Can you post screenshots please?

Yes, and before test with AS and hope te see something with a debugger session.

[Lineflyer]

Lot of users confirming the fix on multiple forums.

[Lineflyer]

@bekuno
Feel free to reopen if you can reproduce, that there is a problem left. All my tests on different devices and user feedback shows, that its fixed.

[bekuno]

I tested it with AS.
There I saw some errors in the logcat, but I could not see the reason.
I would say that it switches back to a initial windows size as on a fresh map call.
So it is probaly not a zoom error.
I will open an new issue when I have more information.