[Unified Map] [Nightly] Some observations ...

[MagpieFourtyTwo]

Describe your problem!

Honestly, I really wanted to keep Use unified map enabled, but right now it's just unusable for me.

Issues I observed (as simple enumeration for now, cause I don't know, what is already known - can create dedicated issues once it's sorted out, which ones are really new resp. not yet in progress anyway):

• 1. Routing to a cache does not work with OSM, if routing is started from within the cache's detail page
  i. e.: select OSM as map source (no matter if special tile or Combined (offline)),
  then open any cache's detail page (NOT via map popup!) and navigate to it, using the navigation symbol in the header
  => over here map just freezes in zoom level "10.000 km"
  Strange side effect: Even though OSM freezes in a completely white area, tapping on map opens a list of waypoints ...
  As soon as I switch map to GMap, the zoom level changes to "4000 km" (which is still way to big), but the route will be displayed
  Switching back to OSM will freeze it again
  Selecting a cache from the OSM map and navigate to it via the navigation symbol in the cache's popup works - sometimes.

• 2. same applies when opening a list and then Display on map
  Edit as of 29.12.23: Map now opens with the listed caches in view,
  but opening behavior is strange (for more info see comment 1872385893)

• 3. line width and opaqueness of navigation route line differs from the previous (non unified) implementation as well as from representation in GMap: First, in bigger zoom levels (e. g. at 5 km) the routing line is way to wide, and strangely gets narrower the more I zoom in, until it finally reaches road width at zoom level of 10 m. Seems as if the width scale factor should be just the other way round; moreover it shows dots (in GMyp) resp. slices (in OSM) at it's edges, which make it hard to follow the route.

• 4. history track line is way narrower than it was before.

• 5. in GMap long tap on [+] resp. [-] opens the map context menu
  in OSM this long tap used to continue zooming in or out - but now it just does nothing until I release the button

• 6. Combined (offline) went to the bottom of the list - can this please go up again, where it was before? ;)

• 7. Although Routing from within listing (no. 1.) is working now (with 2023.12.15-NB-201195f), it takes about 3 to 5 times longer until the route is calculated resp. rendered. Sometimes (maybe after changing the route several times), it is even 15 times longer (i. e. 5 to 15 secs for a 60 km route, instead of 1 sec without Unified map).

Please let me know if there is more info needed or if one of these is worth a dedicated issue.

How to reproduce?

see above.

Actual result after these steps?

No response

Expected result after these steps?

Unified map should look and behave the same like the old one ...

Reproducible

Yes

c:geo Version

2023.12.12-NB-890ec84

System information

No response

Additional Information

No response

[MagpieFourtyTwo]

Some pics to illustrate:

Routing OSM - old vs. unified version (with corner slices):

Routing OSM - old vs. unified version (with bigger zoom and too wide routing line):

Routing OSM - unified again, with corner slices:

Routing GMap - Unified, still different, but at least usable:

[fm-sys]

Thank you so much for your very valuable feedback! For now, it's IMHO fine to collect all observations here.

2. is already known and tracked, see [unified vtm] fail to render if viewport is too large #14948.

But all other things are indeed unknown or were discovered but forgotten.

It's too late today to look into these things in detail, but we'll do so in the next few days and come back to you if we should need anything. We'll also ping you once you should give Unified Map a second chance ;)

[MagpieFourtyTwo]

It's too late today to look into these things in detail,

Didn't really expect these things to be fixed till dawn :)

[eddiemuc]

line width and opaqueness of navigation route line differs from the previous (non unified) implementation as well as from representation in GMap: First, in bigger zoom levels (e. g. at 5 km) the routing line is way to wide, and strangely gets narrower the more I zoom in, until it finally reaches road width at zoom level of 10 m. Seems as if the width scale factor should be just the other way round; moreover it shows dots (in GMyp) resp. slices (in OSM) at it's edges, which make it hard to follow the route.

I will look into this one

[moving-bits]

You guys are fantastic! I haven't even had a chance to read this issue yet, and you have already fixed quite a few things. Big kudos! 👍

[moving-bits]

Added checkboxes to the opening item.

@MagpieFourtyTwo:
When cross-checking the fixes, can you tick the checkboxes for resolved items, please - makes it easier to track which ones are still open. Thank.

[fm-sys]

I'll work on the zoom controls

Edit: PR #15012

[moving-bits]

@MagpieFourtyTwo
FYI: From what I can see from the logs, there are PR which should fix your numbers 1 (#15013), 3 (#15007), 5 (#15012) and 6 (#15011)

[eddiemuc]

@MagpieFourtyTwo FYI: From what I can see from the logs, there are PR which should fix your numbers 1 (#15013), 3 (#15007), 5 (#15012) and 6 (#15011)

number 4 might also be solved by number 3 / PR #15007
@MagpieFourtyTwo if you still have problems with wrong line widths, it would be good to know your line width settings from Appearance settings:

[MagpieFourtyTwo]

Ok - thx!
Will give it another try tomorrow or over the weekend at the latest.
@moving-bits : Checkboxes were a great idea - did not even know them. 👍

[MagpieFourtyTwo]

Current state:

• 1: Ticked as working now,
  but added 7. because routing performance is significantly worse with Unified map (at least 3 and up to 15(!) times longer)
• 2: still unchanged
• 3: Left unticked, although "Line width behavior" got better (width is ok now), but edges still produce darker regions
• 4: History track line is still nearly invisible (over here: color scheme: leftmost, color: top right, opaqueness: 39 %, width: 3)
• 5: Left unticked, cause although OSM now continues to zoom if you hold [+]/[-], there is a long time gap between first and second zooming, way longer than between the next steps (was smoother before), and although in GMap tap and hold on [+]/[-] does not open map context menu anymore, it now behaves like OSM before: a long tap does nothing until you release the button, and then it just zooms once
• 6: Ticked as working now.

[eddiemuc]

• 4: History track line is still nearly invisible (over here: color scheme: leftmost, color: top right, opaqueness: 39 %, width: 3)

A width of 3 is supposed to be very thin. Did you ever change this value manually? I have 5 as the default on a fresh installation on an emulator. We could of course discuss to make the default bigger?

[eddiemuc]

• 3: Left unticked, although "Line width behavior" got better (width is ok now), but edges still produce darker regions

That one might proove to get tricky. It seems with current settings VTM "overlays" the different segments of a semi-opaque polyline resulting in increased opaqueness when two or more segments overlay. GMap is doing this correctly. To visualize the issue I deliberately selected a very broad route width and compared Unified GMap with Unified VTM:

GMap:

VTM:

[devemux86]

Is it 1 line layer or 2 line layers overlapping?
Because the top corner is rendered without overlapping.

[eddiemuc]

Is it 1 line layer or 2 line layers overlapping? Because the top corner is rendered without overlapping.

One line. Yes, it seems strange that only one point is affected. I have to look into this one deeper

[eddiemuc]

A mean example for my reference. Polyline of:
[N 53° 32.004' · E 010° 04.190', N 53° 32.514' · E 010° 05.445', N 53° 32.247' · E 010° 05.461', N 53° 32.463' · E 010° 05.568', N 53° 32.203' · E 010° 05.650', N 53° 32.436' · E 010° 05.019']

Polyline is constructed like this:

[devemux86]

@eddiemuc please see my answer in the PR.

[eddiemuc]

@eddiemuc please see my answer in the PR.

Thanks. Seems this is a bigger thing. I will open a dedicated c:geo issue for this and copy all relevant comments from this issue into it

Update: moved to new issue #15029

[fm-sys]

• Left unticked, cause although OSM now continues to zoom if you hold [+]/[-], there is a long time gap between first and second zooming, way longer than between the next steps (was smoother before), and although in GMap tap and hold on [+]/[-] does not open map context menu anymore, it now behaves like OSM before: a long tap does nothing until you release the button, and then it just zooms once

We currently use an initial delay of 1000ms and afterwards a repeated delay of 500ms. Both values can easily adopted.

Is 500 ms fine for both values?

Can you recheck whether it really doesn't work on unified gmap? (unified gmap, as it never was working on old Google Map before)

[fm-sys]

Is 500 ms fine for both values?

Would be PR #15030

[MagpieFourtyTwo]

@fm-sys

[delay when press and hold [+]/(-]
We currently use an initial delay of 1000ms and afterwards a repeated delay of 500ms. Both values can easily adopted.
Is 500 ms fine for both values?

Sounds good to me.

recheck whether it really doesn't work on unified gmap?

Did so - and now it works. No clue why it did not work yesterday ... strange. But better this way. 🙃
Thus ticked 5. 😎 Thx!

[MagpieFourtyTwo]

@eddiemuc

[history track]
A width of 3 is supposed to be very thin. Did you ever change this value manually?

Yes, I initially reduced it to 3, so I just see it only when I really want to see it (i. e. concentrate on it).
But the issue is not about 3 being to thin, it's about being thinner in Unified map than in classic one.
And I would say, widths should be the same, no matter which map is currently active ... or am I wrong?

[eddiemuc]

@eddiemuc

[history track]
A width of 3 is supposed to be very thin. Did you ever change this value manually?

Yes, I initially reduced it to 3, so I just see it only when I really want to see it (i. e. concentrate on it). But the issue is not about 3 being to thin, it's about being thinner in Unified map than in classic one. And I would say, widths should be the same, no matter which map is currently active ... or am I wrong?

You're right of course. This might be a rounding error when calculating line widths (this which would affect thin lines more than ticker lines). I created PR #15037

[moving-bits]

@MagpieFourtyTwo

Number 2 should be fixed meanwhile

Number 4: #15066 increases line width on UnifiedMap a bit to make it more similar to the old maps

Number 7 I cannot explain yet. "Under the hood" both maps call exactly the same method 🤔

[MagpieFourtyTwo]

@moving-bits

Number 2 should be fixed meanwhile

Close, but not quite there yet. Yes, the map now opens with the listed caches in view, but how it does so, is kind of weird:

1. Opened a list with just two caches, within a distance of approx. 40 km
2. clicked Show on map
3. map page opens, but screen remains to be white (exactly as it was before this fix) ...
4. only the scale is visible ... but it starts at about 100 km zoom level and slowly decreases ...
5. until it reaches a level where all caches are in sight
6. and just now the map gets displayed

Apart from the fact that this looks kind of strange, it additionally takes almost three seconds ... way too long, esp. for such a pretty useless "animation".

Number 4: #15066 increases line width on UnifiedMap a bit to make it more similar to the old maps

Yep, looks way better now.

Number 7 I cannot explain yet. "Under the hood" both maps call exactly the same method 🤔

Nevertheless, it still happens. Esp. when you change the active route to a new target. Possibly a rendering problem? Maybe it would be a possibility to add some debug timestamps to find out the phase in which the time is lost ...?

[MagpieFourtyTwo]

Please let me know once the next test makes sense.
Because due to 2., 3. and 7. the Unified Map is still not usable for us yet.

[fm-sys]

Number 7 I cannot explain yet. "Under the hood" both maps call exactly the same method 🤔

Nevertheless, it still happens. Esp. when you change the active route to a new target. Possibly a rendering problem? Maybe it would be a possibility to add some debug timestamps to find out the phase in which the time is lost ...?

Maybe we recalculate the route several times before finally showing it?

[eddiemuc]

Please let me know once the next test makes sense. Because due to 2., 3. and 7. the Unified Map is still not usable for us yet.

I just merged PR #15114 which should fix number 3. It might make sense to retest this with next nightly.
(BTW: many many thanks for all the test effort you invest into our fixes!)

[moving-bits]

@MagpieFourtyTwo
I'm still unable to reproduce #7 so far.

What I've tried:

• open map, select a waypoint some 20 km away from current location, open waypoint and select "navigate to" icon
• open cache, select "navigate to" icon

each one in both "old map" and UnifiedMap, with some measurement added around the code line doing the actual calculation. It happens in identical times for both maps. (Although with some scatter within each map, but comparable between the two maps.)

Then I measured the times between tapping on the "navigate to" symbol in waypoint sheet until the line has been drawn, and again, I could not measure relevant differences for the amount of time until the line was drawn.

I've also cross-checked whether we recalculate an individual route multiple times, but that does not seem to be the case. It's been calculated per segment, and if you add a new item, only the new segment gets calculated.

I'm a bit out of options what to check next. Can you give a short step by step description on what you have done when you get those results?

And do you have those time differences between old maps and UnifiedMap consistently? Can you cross-check with the other map type immediately when you have encountered such a long time on UnifiedMap?

[moving-bits]

Number 7 I cannot explain yet. "Under the hood" both maps call exactly the same method 🤔

Nevertheless, it still happens. Esp. when you change the active route to a new target. Possibly a rendering problem? Maybe it would be a possibility to add some debug timestamps to find out the phase in which the time is lost ...?

This I've tried as well: A multi with 10+ stages, about 20 km in total. I've switched navigation target between the last two waypoints several times. I'd to wait about 3-5s (scatter!) until the route was recalculated, but without relevant (or even consistent) differences between the map implementations.

(All tests with an emulated Pixel 3a API 30 device.)

[moving-bits]

w/r to item 2 I've created #15122 which skips animations on zoomToBounds for OSM-based maps

[moving-bits]

So much has changed in UnifiedMap since this issue got created initially, therefore I propose to close it and create separate issues for any things that come up for current state of UnifiedMap.

[MagpieFourtyTwo]

@moving-bits

@MagpieFourtyTwo I'm still unable to reproduce #7 so far.

Sorry - haven't used UM for a while, tried it tonight in a dry run and now I couldn't reproduce it either.

Only had a single routing test to a destination about 10 km away that is not reachable by car, and it took about 5 seconds until c:geo gave up and draw a straight line. But apart from that, the routing speed was indeed about the same as without UM now.

[MagpieFourtyTwo]

Ticked 2. and 3., cause 2. appears to be fine now, and 3. behaves like what I would consider "nearly the same as w/o UM".

Therefore, although I just tested with offline OSM (cause I rarely use GM anyway), I would go with @moving-bits, i. e. close this issue, then go on with UM activated in real life from now on, and open new issues if necessary.

BTW: That hillshading isn't working with UM is already known?

[moving-bits]

thanks for cross-checking the issues.

BTW: That hillshading isn't working with UM is already known?

Yes, known and documented (see "implementation state"). Mapsforge library has a built-in hillshading support, which VTM does not. Theoratically it should be possible by adding a bitmap layer on top of the base map layer, adding the shading, but we have not found any routines for it yet.