Generalize map implementations

From time to time there are issues about inconsistencies in the map implementation (e.g. #11847, #11571, #11585, oh damn and probably much more…). And indeed, we currently have all code parts two times, which both need to be maintained and kept in sync.

I thought, we already have issues about this topic, but I couldn’t find any…

It seems, someone had just copied all code parts back in the days instead of creating a good abstraction layer. Can someone please step into this, and do a better job than it is done currently?

Example: Two totally equal code parts which could be moved into a unified class…

Google Map (known as CGeoMap)	OSM Map (known as NewMap)

Oh, and while being on the way, also the class/package names should be changed as described in #6951

[moving-bits]

Sneak preview: I’m working on a unified map approach integrating Google Maps v2 API and Mapsforge VTM. This is intended to ultimately replace both CGeoMap and NewMap.

Benefits I’m striving for are:

• a single, unified map activity, handling all common parts
• rotatable maps in both Google Maps and Mapsforge (which VTM does support)
• way faster map drawing for Mapsforge (which VTM does support)

Currently it’s more like a pet project for me I’m working on from time to time, and I will for sure need some help along the way at some point in time. So far it’s very basic what I have right now, and it will probably take months to be completed (or maybe never be).

I’m currently able to display Google Maps, bitmap Mapsforge maps from online sources, vector maps from Mapsforge .map files. I can (mostly) switch between different types of maps, and I can pan, zoom and rotate maps.

Example for a rotated bitmap Mapsforge map from openstreetmap.org. If you rotate a map created from an offline map file, labels will adjust automatically (e. g. city names always being horizontally).

[moving-bits]

@cgeo/core: How shall we continue here?

Unifying the maps is a rather large task, which cannot be completed in a single huge step. We have a quite large PR (#12829) in line, which I haven’t merged so far in expectation of soon branching for a new release, to merge it after cutting off the new release branch. But since that hadn’t come as timely as expected (no offense meant), I’d like to propose a different proceeding here.

My proposal would be:

• Merge PR #12829 to allow for broader testing and for easier collaboration. As @eddiemuc stated above: The functionality is “hidden” (you have to set a specific settings value to make it visible), and the code base is mostly independent. (And we still have a complete beta cycle to check for any unwanted side effects.)
• Create a new project “unified map” for easier tracking of open issues, and transfer all open items of my current todo list in https://github.com/cgeo/cgeo/pull/12829#issue-1160121205 to separate issues in this new project.

If no one objects I would continue this path starting next week.