How to develop a map application in 2023?

EDIT: HERE Maps plugin started to work again. Qt Map component is still an option.
The various questions are still valid though, if someone does the migration exercise until I do :slight_smile:

After the osm plugin in 2021, it seems that it’s now HERE that stopped its support for the good old QML Map object.
Last week, my application stopped to show HERE tiles, and when I tried to connect to my HERE account, it simply told me that… I didn’t have one? Seems that they silently cleaned up a lot of things :man_shrugging:
I’ve tried to recreate one HERE account to get API keys, but the problem is elsewhere, map tiles just don’t load anymore.

I guess the best solution is to go with Mapbox through @rinigus’s Mapbox GL bindings, right?
But are there any tutorial out there to help porting an app for someone that didn’t follow actively QML development in the past years?

  1. How to install properly the bidings on the Sailfish IDE?
    I’ve managed more or less by downloading the rpms from OpenRepos and do:
$ scp -P 2223 -i ~/SailfishOS/vmshare/ssh/private_keys/sdk qmapboxgl-1.6.0git2-1.2.1.jolla_.i486.rpm
$ scp -P 2223 -i ~/SailfishOS/vmshare/ssh/private_keys/sdk qmapboxgl-1.6.0git2-1.2.1.jolla_.i486.rpm
$ ssh -p 2223 -i ~/SailfishOS/vmshare/ssh/private_keys/sdk root@localhost
# rpm -U qmapboxgl-1.6.0git2-1.2.1.jolla_.i486.rpm
# rpm -U mapboxgl-qml-1.7.7-1.2.2.jolla_.i486.rpm

I can then compile and run apps on the emulator, but the IDE still shows “QML module not found (MapboxMap)”. Not a blocker, but not very user friendly.

  1. How to migrate from MapQuickItem?
    My app currently displays programatically a lot of QML objects on the map with that. With MapboxMap, I’ve managed to display a single position circle by copying the example here, but is there an easier way to display markers/QML objects, text, etc…?
  2. How to make the map light? The MapboxMap is very heavy by default, because there are much more details that on PureMaps. How to configure that? What are the best defaults for a light map app?

Thanks in advance :smiling_face:


Re tutorial: No, there isn’t much written. There is API of QML bindings (GitHub - rinigus/mapbox-gl-qml: Unofficial Mapbox GL Native bindings for Qt QML) and small demo (mapbox-gl-qml/main.qml at master · rinigus/mapbox-gl-qml · GitHub). Not sure how up-to-date the demo is. In this respect, Pure Maps is a good source for usage examples.

Re binding in IDE: Never used them as Pure Maps runs on desktop - no need to develop using SFOS IDE. However, I expect that you could add Chum repo and install via that. Do you have Mapbox QML set as a dependency?

Re migration: no idea. API is different and based on drawing objects inside the map. However, it is possible to put components on top and then glue them to the location on a map. See trackLocation in API and its use in example at mapbox-gl-qml/main.qml at master · rinigus/mapbox-gl-qml · GitHub. We used it in WhoGo Maps days, but later switched to inserting POIs into the map instead. I would recommend to read Style Specification | Mapbox GL JS | Mapbox to get inner workings of the map styles and how to add new elements there. Examples on that page are also nice, but its somewhat different API.

Re light map: choose some other map style. See Light Map Style | Mapbox and there are other similar simpler styles by other providers.


Thank you for your answer

Those are definitely all good pointers, but it’s really missing a good tutorial that would save hours/days of reading for beginners. I don’t know if Nokia docs were that good, or if my (searching) skills decreased in the past decade (most likely both), but I know that it will take me so much time to gather all the information that my app could stay broken for a while :frowning:

But I’ll post here my findings when (if) I have some!

The problem is kind of resolved for now. HERE tiles started to download again after a bit more than a week. Let’s say they have done a big maintenance on their side (that deleted my account along the way :man_shrugging: )

I’ll still try to look into migrating at some point, but hopefully it’s good for 2023.

1 Like

It looks like this:

is being tracked. I’ve taken a crack at building but it’s the whole of QTs location stack and I just didn’t have time. If the qt osm geoservices plugin get’s fixed, it’ll make it possible to do OSM maps stuff (in QML alone) which takes one quite far (just not on SFOS, sigh).

1 Like

Biggest problem with HERE is that they no longer allow app_id/app_code way of authorization for new accounts, new accounts are forced into either oauth2 or pure apikey, here plugin cannot be tricked into here.app_code = “&apiKey=(real key here)”, no idea how hard it would be to update the here plugin to accept apiKey instead of code/id pair (or if it’s even legal based on the qt license hell), but the end url just needs ‘?app_code=xyz&app_id=xyz’ changed to ‘?apiKey=xyz’ and we should have a working here plugin for that glorious 1k free tiles and easy qml access

EDIT: looks like it’s been done before: stackoverflow/update-HERE-Qt5.9.patch at master · eyllanesc/stackoverflow · GitHub
(ok, this is from app_id/token to apiKey but pretty much the same thing)
And according to Qt Qml Map with HERE plugin how to correctly authenticate using here.token - Stack Overflow the url is a little bit different too I guess vs


Whaaatt?! You are right!
If I use my newly created appId/apiKey, tiles don’t download.

If I put back my old appId/apiKey (linked to… my vanished account)… It works :thinking:
What the hell?! Where did those accounts go? (I’ve recreated one with the same email address)
I’m not so sure it will be good for the whole 2023 now :sweat_smile:

Nice findings! It should be backportable to Sailfish then :crossed_fingers:

1 Like

Question could be in the license of backported code. Not sure if it will be already under GPLv3 that Jolla is avoiding. As a result, it could either be incorporated into the base system or not.


Looks like getAuthenticationString needs two lines commented out (say app id part) then authenticationString += “?app_code=”; changed to apiKey=. And the conditon of checking if appid is provided removed, of course that would break old workflow uses, wonder if changed plugin like this can be renamed as herenew plugin and shipped separately to not break any base packages, just add new to plugin name in your app and change code/id to apikey and we can have mapping in 2023

1 Like