Replace Tangram with Maplibre

[westnordost]

by @Helium314 and me.

This PR is the same as Helium314#516 only that it merges to vanilla StreetComplete.

Visible differences to Tangram-ES

• improved style, e.g. private roads, rails and paths look better now, some issues with the old style were solved and bridges / tunnels render more correct now
• can zoom in much further
• quest dots are clustered on low zoom
• no 3D building except in the buildings overlay. (They don't look so good with MapLibre)
• icons in building overlay have no white outline anymore (technical limitation)
• color of icons in places and things overlay adapts to day/night mode
• color of text in overlays adapt to day/night mode
• animation on selecting (quest) pin
• (better) animation on selecting elements in an overlay
• improved memory consumption
• location accuracy circle doesn't get blurry when it is large
• (of course, no tangram bugs. For example those flickering quest pins when zooming back out, that was horrible)
• (... anything more?)

Blocked by

• Missing data for single tiles when using GeoJsonSource maplibre/maplibre-native#2410 successfully worked-around
• (Crash with android-v11.0.0-pre4 (Samsung Galaxy S4 Mini, LineageOS 16.0, Android 9) maplibre/maplibre-native#2206)

Known bugs

• location pointer pin sometimes points to the wrong direction, caused by
  MapProjection::pixelForLatLng returns wrong values when camera has tilt maplibre/maplibre-native#2255
• sometimes crashes in the background (i.e. not noticed by user), caused by
  Crash on Android while in background maplibre/maplibre-native#2432
• steps dashes and private-dashes look a bit funny while zooming, caused by
  Awkward animation of dashes at certain zoom levels maplibre/maplibre-native#2433

Remarks

• displaying overlay and quests in the currently visible map section is implemented manually. Could potentially be removed when CustomGeometrySourceOptions.withClip always enabled? maplibre/maplibre-native#2262 is fixed
• location dot, accuracy circle and view direction has been implemented manually because MapLibre's own LocationComponent didn't look good and felt jerky. If that changes in the future, the own rendering could be replaced

[westnordost]

Is MapLibre still trying to download more glyphs when offline? (It should appear in the log)
Because now, I would say, it shouldn't, because it should recognize that the glyphs should not be considered stale at least for 12 hours.

[Helium314]

I was unable to reproduce it until I noticed the problem was actually switching to the places overlay, which also seems to require glyphs that are not pre-downloaded.

Is there a way to make sure that overlay texts only use glyphs that are already downloaded together with tiles? Or maybe MapLibre should use some fallback instead of (whatever causes this bug)?

[westnordost]

Hmm... perhaps it is possible to have all the font glyphs locally already. As long as one doesn't go wild with different fonts and font weights, it is not that much in terms of file size.

Not sure how to refer to them in the style JSON though.

They can be downloaded here: https://github.com/kylebarron/openmaptiles-fonts/tree/master/fonts

(Otherwise, ) does MapLibre download them as files into the app cache directory, or again into some database? If the former, it should be possible to download them all beforehand manually (like we did with tangram tiles).

Edit: Could try with asset://..., apparently it works for sprites, maybe it does work for glyphs, too.

[Helium314]

Edit: Could try with asset://..., apparently it works for sprites, maybe it does work for glyphs, too.

This works nicely, I wasn't able to reproduce the bug so far when having glyphs in assets!

---

One more issue I noticed: Sometimes switching between overlays takes a second or so. When I select an element of the old overlay before the new map features are set, I can e.g. set the address of a waste bin. It should be better for most users due to faster phone and non-debug version, but still should not happen.
Perhaps we should clear the overlay before doing the switch, or give each feature some overlay property that is checked on selecting the feature.

[westnordost]

This works nicely, I wasn't able to reproduce the bug so far when having glyphs in assets!

Hm!

🎉?

Is this the workaround we have been looking for all this time?

(Is it possible to also specify the streetcomplete.json itself to sit in the assets folder? Currently for offline download, we have to have this remote duplicate of the streetcomplete.json)

---

Regarding the issue: Well, sounds like that would make sense. (The first, if it doesn't work, the second)

[Helium314]

Is this the workaround we have been looking for all this time?

Really looks like it is. So I'll put the fonts to assets.

Is it possible to also specify the streetcomplete.json itself to sit in the assets folder?

Unable to parse resourceUrl asset://map_theme/streetcomplete.json

[westnordost]

Is this the workaround we have been looking for all this time?

Really looks like it is. So I'll put the fonts to assets.

But then I have to change the remove streetcomplete.json, too. I hope that works with the offline downloader

[Helium314]

I vaguely remember the remote json only needs the same tile URL as the local one to work properly.

[Helium314]

Btw the glyph folder names are a little weird, e.g. Roboto Bold,Noto Bold. MapLibre appears to require it due to "text-font": ["Roboto Bold", "Noto Bold"] in the json.
Open Sans Regular,Arial Unicode MS Regular is accessed for address and places overlays only. This appears to be some default. We could try switching to Roboto/Noto here, then the Open Sans Regular,Arial Unicode MS Regular might not be necessary any more.

[westnordost]

Yeah, or just one font, so that we don't need to keep around font fallbacks. After all, we do keep the fonts ourselves, no need for fallbacks.

[Helium314]

We could try switching to Roboto/Noto here

Current state (Open Sans Regular) on the left, Roboto Regular on the right:

I think switching to Roboto is fine, also for increased consistency e.g. with street names (different style of g).

Yeah, or just one font, so that we don't need to keep around font fallbacks. After all, we do keep the fonts ourselves, no need for fallbacks.

So I'll just use Roboto Bold and Roboto Regular and remove the Noto names.
Also will set overlay text font to Roboto Regular and remove Open Sans regular folder.

[Helium314]

So I guess it's time for a little more testing now, and then... I'm not sure that maplibre/maplibre-native#2206 will eventually get fixed. Maybe we should merge this regardless?

[westnordost]

You had to write this because MapLibre uses some font by default?

[Helium314]

Yes, the default is Open Sans Regular and Arial Unicode MS Regular

[westnordost]

Yes, let's do it.

[westnordost]

And I'll document our findings in the respective tickets.

[Helium314]

I did a "live test" and noticed a few minor visual glitches. Will open issues, or do PRs/commits depending on fixes I find. (but first I'll probably spend 2 days or so on merging this into SCEE)

[westnordost]

One thing that just came to my mind with all this offline region gehampel, are we maybe massively producing overlapping offline regions by just downloading and hence producing massive amounts of (unused / doubly used) cached map tiles? E.g. just when opening the app, the app will already download two regions (small rectangle around the user, then big rectangle around the user).

Since offline regions seemed to have never been thought through completely (maplibre/maplibre-native#2724), maybe there are issues with overlapping and managing (many) offline regions, too.

[Helium314]

As far as I remember from looking through the offline database, tiles are downloaded only once. Tiles and regions are linked in some db table, and a single tile may belong to more than one offline region.

Thus I think overlapping offline regions are not an issue. The small-rectangle region will be useless in the db, but only occupy very little space (download url, some dates, which tiles belong to this region).

[westnordost]

Phew! Thank you for checking!

[Coehill]

Thank you to the developers for all of your efforts on making this available on iOS! StreetComplete is an invaluable tool and we will all benefit from more people able to map with it.