A modern map item with support for stylesheets, vectordata and rasterdata

The map part (there is also the routing and geocoding part, but usually people want maps) of the QtLocation module is in a bad state, both from a functional point of view but also from an architectural point of view.

Functional Problems:

• QtLocation supports only rastermaps through slippy map tilenames (https://wiki.openstreetmap.org/wiki/Slippy_map_tilenames) out of the box. This is slightly useful for satellite pictures but is trivial to recreate (we did so during hackathon in 3D) for application developers, so Qt is adding no real value to them.
• MapItems are implemented as an afterthought to the map and complex operations are done in every frame to adjust the item to the map. Therefore mapItems look "alien" and also perform bad.
• Explicit caching and offline useage is not supported.
• High quality maps can be achieved by providing plugins, e.g. the maplibre-native plugin. However, the value that QtLocation provides in comparison to using these libraries directly is virtually zero. In fact, I would argue that using maplibre-native directly is better and easier than building the QtLocation plugin, see the example on https://github.com/maplibre/maplibre-native-qt. Using the library directly also allows to use the "native" method to draw map items (with much better performance than QtLocation) and to have access to styles through the maplibre API. However, this solution is not ideal either because of issues with graphics backends and integration into Qt.

Architectural Problems:

• Plugin-based architecture: We have a very complicated codebase to theoretically support many backends, but in practice only one is really supported. This adds a huge overload without any upside. Also, most map providers switched to the support of standards, especially the mapbox standard has become broadly accepted. The layer where abstraction happens shifted towards the data/style formatting.
• Because we want to support different plugins, we cannot offer access to the map and its features (e.g. to styling or map elements like streets) because this is different for all plugins. There was an API intended to overcome this but it is cumbersome and complicated. By supporting the common subset of all plugins, we support very little.
• A part of the features are outside this architecture, e.g. mapitems. Therefore they are not really integrated into the map but drawn on top. They look out of place.
• We break Qt principles: Qt choose the layer at which we want to take over from the operating system very carefully: Qt wants to do the drawing itself. This principle fits very well into the mapping ecosystem where we could draw the data from 3rd parties with out own tools. However, we try to offload drawing the data, although we have nearly all the infrastructure to do it ourself, as our proof of concept shows.
• Variable backends or data provider would mean to support a flexible format like the mapbox standard (https://docs.mapbox.com/api/maps/vector-tiles/) and allowing to use variable data sources there.

Suggested solution:

The suggested solution would be a QuickItem that implements a modern standard like mapbox and exposes it to C++ and/or QML. This is a baseline implementation of a MapItem that is required in any case, independent of the direction and business area we choose to focus on.

• The styling is very well described by the mapbox style specification (https://docs.mapbox.com/style-spec/reference/). We can use the Mapbox spec as a starting point and be compatible to a wide range of existing styles. There is also a wide range of services and tools to create these styles. We can further limit the style-spec to exclude some features (as done for mapbox-native or maplibre-native) and focus on a subset that we want to support.
• Data is usually accepted in the form of vector tiles (https://github.com/mapbox/vector-tile-spec) or raster data. Most data provider (Mapbox, Maptiler, ESRI, Here) provide these formats so we are immediately compatible with them. 
• The basic API should match the mapbox API and include modifying the viewpoint, the modifications of current styles, the addition of data, the interaction (taps on elements, etc) with map elements and the addition of QuickItems in the coordinate system of the map (so moving with pans and zooms of the map). Beyond mapbox we can allow these items to be much more powerful.

We should focus on a 2D map at the start but we can use the data gathering and stylesheet parsing/interpreting to provide a similar item that implements a 3D map with Quick3D.