Notices

Here is another suggestion for technical and practical discussion.

Running Pure Maps with disabling suspend mode will keep the screen alway on. Thats okay for car navigation where you can plug your charger into the phone to keep the battery up and running. However it would be a good idea to blank the screen to save juice and just listen to audio prompts from the speaker.

The scenario is e.g. having your bluetooth earplugs fitted and riding on your bike. If you have no phone bracket mounted or find it distracting watching on your display (it's better nowaydays to keep an eye on the vehicles around you than to look on your phone) the phone consumes an unnecessary amount of valuable energy.

The current situation is that if I turn off the screen by closing the magnetic cover or push the on/off button the kernel will suspend any running process so Pure Maps will go into deep sleep updating only position and routing once the phone is woken up from suspend.

Now thats keepalive is official approved by Jolla what about periodic background processing option supplied by Nemo keepalive (https://git.merproject.org/mer-core/nemo-keepalive)? Would this prevent deep sleep if screen has been turned off, but allows Pure Maps to update current position just in time to re-route and play voice prompts?

Could we just make a request to both API's and use whichever one returns results?

Re suspend modes: This is planned, as a part of https://github.com/rinigus/pure-maps/issues/63 . I will have to look specifically gow to implement it. As far as I remember, keepalive periodic activity was designed for something that allows to let the phone sleep and wake it up. But the frequency is up to once a minute, I think.

Re HERE APIs: maybe we can ask the both of them. Its not very clear how their app is doing it, but it sometimes can return also POI type when you start searching in their field. So, maybe it does combine the both APIs in autocomplete mode.

I would start with the clear separation (geocoder and nearby separate) and later think whether we can combine it more systematically for all providers.

Hmm, one could make two API calls and then try to combine the results, right.

Sure, we can just make two calls. Question is if it will be advantageous to combine on Pure Maps level or on each plugin level.

Not sure I will be able to implement these two calls very soon, but it maybe better solution in longer term. Although, for now, maybe we can combine it on HERE plugin level and then I can deal with separation later.

I agree it seems to be easier for this to be implemented in the plugin as it would not requite changing anything in the main program.

But I haven't used the POI API yet so it's not entirely clear if or how the results of both API calls can be combined.
Will have to do some more testing I guess.

I had a quick look into POI API and it does have some interesting aspects. For example, it supports autocomplete and looks for names as well as types while you type (if I figured it right). Which is a good idea and may help me with unifying search and nearby functionality. I will just have to think how to use it properly and hook it into the main logic.

So, after sleeping on it, I would suggest to have geocoder API as it is and POI separate, for HERE as well. For POI, it should be API that is restricted to current plugin hooks - aka no autocomplete as for now. When it all lands in master, I will look into how to add autocomplete and unify the search with nearby functionality. It may require few iterations, but I think we will get there and without temporary hacks.

New release is out - 1.25.0, followed by 1.25.1 and 1.25.2

This release is mainly about fixing smaller annoyances. As usual, though, big thanks to translators for the updates.

This release brings optional DBus activation, based on xXSparkeyy's work (thank you!). Currently its not used to ensure that the environment is controllable by local environment variables simplifying the debugging on all the supported platforms. For Sailfish users, though, geo handler has been fixed with xXSparkeyy's help. I expect that all these calls by SpritRadar should work as expected. At least they did work over here.

Attribution button has been redesigned as it was not clear that the button is interactive. That should make data source acknowledgments clear.

Search engines are now taking into account your location for location bias. This is currently supported by online providers, for offline operation its in TODO list of OSM Scout Server.

For QtControls and Kirigami, fallback icons loading has been improved (although not yet for PostmarketOS) and clipboard support was added. For UBPorts, and other non-Silica platforms, navigation icons have been reduced making them more suitable.

Some other smaller bugs were fixed as well.

While Sailfish release is out, builds for Flatpak and UBports should be on their way.

PS: Just have hit a bug with geocoder. Bugfix release prepared

PPS: Bugfix release made with geocoder call fixed and translations updated

PPPS: And one more bug fixed (autocomplete call of osmscout server) in 1.25.2. Bad day

Is the drawing of the roads specified in the downloaded maps or by PureMaps (PM)? [in vector tiles, I assume jpg tiles are immutable]

Can it be over-ridden by PM?

e.g. can the normal drawing of a minor road, be replaced by a fat black line at all scales?

Why?

When zoomed out, minor roads are either drawn with fine grey lines, or simply not rendered at all. In rural areas this leaves the map completely useless, as the roads between here and there are invisible.

On the map below, viewing Raglan and Awakino on the map at once to find the coast route, the roads between them have totally disappeared.

https://wego.here.com/?map=-38.34409...6527,10,normal

This the same map drawn by competent humans:

http://www.topomap.co.nz/NZTopoMap?v...74.889984&z=10

For vector style maps, data and style applied to it are separate objects. With some reservations, as whether vector tile database includes all info at certain level. As such, it is possible to make your own style and load data from Mapbox or OSM Scout Server. OSM Scout Server style is at https://github.com/rinigus/mapbox-gl-styles, for Mapbox ones look them up as a developer. PRs are welcome, I don't expect to have time to work on styles in any time soon.