@volatius Even better location is Github issues . Replied in your thread ...

This issue was raised at https://github.com/rinigus/osmscout-server/issues/450

Turns out that the server distributed in Ubuntu Touch is using old Valhalla. The maps are generated using Valhalla 3.4 and with older Valhalla on UT, it seems to lead to such funky trajectories.

As jonnius is aware of the issue, I think the new version of the server should be on the way to UT as well.

@Keneda said in Bad routing in navigation apps when using OSM Scout Server Offline:

Did you try to untick the "act like alcoholic" box in the app ?!?

its not implemented yet, but maybe can be suggested to Valhalla developers

@dobey, thank you very much for replies!

Plan is to have only one executable that is exported into app drawer, GUI part. Or taking into account your replies, some master script starting all components.

Sounds like it is possible to have such separation on UT as well. However, at this time, it will just add some complexity without any benefit.

What is not clear what will happen on the case of GUI app shutdown. So, assuming I have a script along lines

#!/bin/sh
start dbus &
start daemon &
exec gui

and gui gets closed by the user. Will all processes started in that confined env be killed? If yes, which signal(s) will be used?

Not sure how this app suspension will work for daemon. I wonder if that will be suspended at all if we have two processes running from the same click package.

Re private dbus: OK, so we have to start that as well in our case.

So, if we have separation, we need some kind of launch script that will start:

• DBus
• daemon
• GUI

After starting DBus and daemon, that launch script can probably exec into GUI.

On closing GUI, we will probably have to shutdown the daemon as well, unless user will ask to keep it.

From this discussion, it looks like while separation into daemon + GUI makes sense in classical Linux, it does cause some pain on UT. (And I am ignoring official store requirements on SFOS.)

In principle, we can also keep separate UT branch with the current type of implementation. As most of the changes are expected in the backend libs and not the server itself, it would probably work for some time. And later revisit situation.

Alternative would be to try to move osmscout-server daemon into DEB. But that sounds not trivial in UT, as far as I can see.

I am in the process of rewriting OSM Scout Server into two separate applications:

• daemon performing actual work
• GUI allowing to adjust daemon settings, instruct on map datasets management

Such separation would allow to keep daemon running in the background all the time with minimal memory and CPU impact. When not in use, the daemon will wait for connection with it to fork into full-blown mode supporting all required operations (serving map tiles, search and routing). After idle period, it will transfer into original waiting mode with reduced impact.

This transition will allow to support Linux variants that do not ship with systemd or other init system supporting socket activation. Examples include pmOS or Flatpak packaged OSM Scout Server.

However, it raises few questions regarding UT support. Maybe someone can help me here to find replies and/or propose solutions to the issues arising from such partitioning:

• can I have multiple programs in the same click package? In this case, osmscout-server and osmscout-server-gui

• can I run multiple programs from the same click package? one GUI and one daemon, in my case

• can these programs communicate with each other via session dbus?

• does UT support dbus activation for confined apps? As if one of the click installed program (GUI) tries to access the other program in the same click (daemon)

• can user craft together init script and install it for running a service via confined daemon? Will probably come as suggested mod for users that they will have to do manually on their devices. Such as copying init script to start daemon on boot

• as far as I remember, it is impossible to communicate via dbus for confined applications installed from separate click packages. is it (still) true?

That's thanks to you for finding it out

@padu: yes, with volume bottons

@padu: forgot to reply - yes, you need mapbox api key. or use osm scout server offline for testing

@padu , can you change the volume of the instructions? this seems to be the second issue with this approach

@padu , indeed! there are too few on mobile linux side - have to get hands dirty at some point. Good luck!

Pure Maps is using QML Audio for sound. We tested SoundEffect as well on SFOS, but it had some issues with the bluetooth - will have to retest it. I don't know how to patch it to PA alert. You could see if SoundEffect will work for you (change it at https://github.com/rinigus/pure-maps/blob/master/qml/pure-maps.qml#L88) and whether it works better.

@magdesign If you are going to work on https://github.com/rinigus/pure-maps/issues/408, that would resolve most of your issue with only remaining part being isolines. But for isolines we could maybe find some better solution

@herr-b, that would solve the problem as described by @magdesign. Any developers around wishing to write it?

@magdesign That's a bit more sophisticated than usual.

In principle, it is possible, but you will have to get your hands dirty. Overall, you will have to

1. convert GPX tracks to something that the map widget can load natively (GeoJSON)
2. serve that GeoJSON via local HTTP server (python simplehttp?)
3. create new style that is using GeoJSON and serve it via the same server
4. add new map to Pure Maps as a custom map

As OSM Scout Server does not have height lines, you would have to either look how to add isolines data to these maps via your style or download tiles from opentopomap and serve via your server as well.

Not very trivial, but possible. All depends on how much time do you want to invest into it. As a nice side effect, you will learn how it works and could contribute to the map data import and style development.

@cliffcoggin: as far as I understood, there was a plan to switch to systemd on UT. When UT will support systemd, we can look into how to make it possible.

@cliffcoggin yes, it is very simple to make it open automatically with Pure Maps starting. All you have to do is to switch to Sailfish. Don't know whether your device supports Sailfish or you have to get a new one, see our ports.

To make it work, OSM Scout Server is using systemd socket activation and DBus activation. So, when Pure Maps starts and asks for tiles or some other functionality from the server, server is started in the background without any GUI. After some idle period (can be configured in the server settings), server will close itself to free RAM.

On UT, we do not have access to this functionality. It boils down to

• no systemd on UT

Even with systemd, not sure how well it work with super-aggressive suspend policy of UT and whether it will be allowed to start clickable app in daemon mode from systemd.

So, for now, if you want to stick with UT, you have to open it manually and jump through those tweaking hoops to make it work.

@cliffcoggin : I suggest that you open an issue. If it is offline, open an issue at https://github.com/rinigus/osmscout-server/issues with specific example. Try to describe in details what you have done in Pure Maps and OSM Scout Server. Don't forget to mention the platform and whether you used that UT tweak tool to keep OSM Scout Server running in the background.

If uNav will implement offline support, it will be using the same OSM Scout Server for it. So, you would be having the same issue probably.

uNav will be able to use OSM Scout Server when https://github.com/costales/unav/issues/8 is implemented.

@herr-b

Search field (the one you see when starting entering text into Near location, same in routing) links bookmarks and addresses. They both are searched while you type (assuming that provider supports it).

In many of my replies I mention provider. From the beginning, Pure Maps (with its earlier names Poor Maps and WhoGo Maps) was designed to be modular. It is easy to add new providers for search, nearby venues, and routing.

Each provider can have it's own settings that alter the action. For routing, some search only routes for cars, some do more. For nearby venues, default online provider is https://foursquare.com/. That "Best" or Most Popular comes from them.

Over offline provider - OSM Scout Server - I have some control as I am the author of it. But note that even there, routing is provided via one of the libraries - Valhalla - and the server can be considered as just an extra layer for that. For search (global and nearby), though, control is larger as it is using geocoder-nlp that I wrote. Although, it becomes question of my time and priorities among projects that I contribute to.

It's not very obvious on UT, but you can tap on "Near Current position". That will open search dialogue with bookmarks being part of it. On SFOS, we have special color coding of elements that can be tapped. This makes it clear where you could interact, not sure whether there is something similar for UT.

So, from screenshots:

1. That's correct, as we don't know location. If you tap Near, you will be able to enter location that will be used as a reference
2. Same as Near, have to tap on it.
3. Yeah, I can see that it is not super intuitive. Re Best - old formulation, most popular would be the correct one.

From comments, it's clear that some visual feedback is missing for selectable elements. Combobox is probably wrong - but I am not sure what should it be.

Also triggering of the action seems to be rather obscure. Any good design for UT? Same probably goes for routing.

Hopefully replied to your suggestions. If not, please let me know.