This is to announce the release of OSM Scout Server on Ubuntu Touch. The packaging was done by Jonatan Hatakeyama Zeidler and his testing. Thank toy and it was fun to bring the server to UT with his help!

In short, this is an application that provides data for map clients, such as Pure Maps. When used together, you can navigate, search, and browse maps offline. See user's guide at https://rinigus.github.io/osmscout-server/en/ for details of operation and setup.

In addition, please follow the instructions on package description page at OpenStore.

At the moment of release, there are few limitations which I hope UT community will resolve and send PRs with the fixes:

• translations are built using qmake feature which is not available for Qt 5.9. If you want the server to use available translations, please send PR with qmake pro file fixes for UT.
• you cannot select location of the maps folder as we don't have implementation for FileDialog that we could use in UT.

At present, you have to use default location, close the server, move it to the location you want and make symbolic link from the default to the new location. Not very user-friendly. To fix it, FileDialog for UT platform has to be written and submitted for inclusion. I hope someone can step up and do that.

Finally, you have to have to run the server as an app right now. On Sailfish, we use systemd socket activation which allows users to configure the server to autostart on demand. Sounds like you will move to systemd at some point, so we can work on it when it is available.

Enjoy!

Version 1.26.1 is out.

This version has a major rewrite of navigation and follow me modes. Its remaining part of the implementation along the lines discussed this summer with Sailfish users. We have now navigation start/pause and clear road buttons accessible on map view. Clicking on manoeuvrers button, you get to combined navigation/manoeuvrers page. Speed is shown now on the top right (shows up only when you get the gps fix), next to other current manoeuvrer info (suggested by @popanz). We do have now current speed and speed limit on opposite corners of the screen, but I didn't find a better place for speed limit, unfortunately as top right is busy already.

Its intentional that you cannot open menus and start searching while you navigate. If you wish to do it, pause the navigation and, after you finish search or some other activity, start it again.

Translations have been updated, thanks to all translators!

And finally, thanks to @jonnius for UBPorts packaging!

New release is out - 1.25.0

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 (Sailfish) 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.

PS: There is a know issue with the release - geocoder function is broken. Fix is coming up

@dobey thanks! OK, that's way easier then. Kirigami would be better, since it has few features that make it more convenient to use on mobile, when compared to my QtControls implementation.

So, I will have to adopt the code to Qt 5.9, if any changes are needed at all. After that I'll ping over here and maybe someone can help with click packaging.

Pure Maps uses QMapboxGL Native library, the separate QML plugin - both would probably need to be packaged. I don't know whether you have pyotherside and Nemo DBus QML plugins available already. In addition, it uses Mimic or Flite for voice prompts.

How is the application expected to keep display on in UBPorts? That will probably need to be adopted as well

released.

Hi!

Thank you for the interest!

Pure Maps works on Qt 5.6 as well (Sailfish) with the current lowest required API as specified in https://github.com/rinigus/pure-maps/blob/master/qml/README.md.

Pure Maps and OSM Scout Server (latter is offline maps provider required for offline maps) follow the same basic principle: most of the code is cross-platform and written in QML that is understood by all platforms where its ported to. Platform specific implementation is described by a number of QML items (example at https://github.com/rinigus/pure-maps/tree/master/qml/platform.qtcontrols). For porting to UBPorts, we would need to create qml/platform.ubports and fill it with the the similar items that should provide native look and feel.

Pure Maps and OSM Scout Server are available for testing on regular Linux PC via flatpaks: https://flathub.org/apps/details/io.github.rinigus.PureMaps and https://flathub.org/apps/details/io.github.rinigus.OSMScoutServer
Latter is needed for offline maps, but you could start testing with Pure Maps only and just keep online profile.

Coming back to porting: the most efficient way would be to get someone interested in writing UBPorts platform code. I'll be happy to assist and help as much as I could and as fast as possible.

Hi,

I am a developer working on Sailfish and an author of OSM Scout Server: https://rinigus.github.io/osmscout-server/en/ . I would like to describe the solution that I have been working on to get offline maps on Sailfish.

OSM Scout Server is a server that can be activated by systemd socket activation and QML app. It provides map tiles (Mapnik raster tiles and vector in MapboxGL format), allows to search for locations and POIs, and provides routing data. The app part allows you to download, update, and delete maps as well as change the settings and check server's logs. In addition to the code, I try to import the Planet once in 2 months and we have two servers distributing these maps in relevant format.

For offline operation, you just need the server and a map GUI client running on the same device. For example, uNav can contact a specified port at localhost and get the data. On Sailfish, we have Poor Maps and modRana as the main clients. Recently, I also wrote an unofficial QML plugin for MapboxGL to get OpenGL accelerated maps (https://github.com/rinigus/mapbox-gl-qml). This works very well and we have already sports application ported to it, Poor Maps GL version and its developed continuation https://github.com/otsaloma/whogo-maps already. Since you probably have newer Qt, you may as well use QtLocation Mapbox GL plugin for developing the client.

Porting the server should be relatively simple. It has Qt C++ and QML mix with Silica components. So, QML part has to be translated, but it shouldn't be much work. The server can be used with CLI only as well, but I haven't worked on the map managing switches too much and mainly use it for debugging on Linux PC. To compile it, you would have to package or use packages for various backends. See https://build.merproject.org/project/show/home:rinigus:maps for a list. I suspect it will be way easier on Ubuntu than it was for me - many packages are probably there already or easily available from PPAs.

Porting the clients or writing new is not too hard either. I would recommend using Mapbox GL for maps - its just easier to get all POIs and maps are fast as well.

We have phones that have as little as 1GB RAM working with such solution. However, devices with 1GB have not been successful running MapboxGL widget, so they use slower raster map rendering.

When we get OSM Scout Server ported over to UT, Pure Maps will be able to use the map data from that server for offline operation. This includes search, navigation, and map matching, in addition to MapboxGL map tiles.

Plan is to do it soon, but I will depend on packagers. On my side, I will use the same GUI abstraction as we have for Pure Maps for UBPorts support. On the server side abstraction is ready, I have to just add and test UT platform code.

OK, we can replace qmlscene with my qmlrunner for a bit more functionality. I can also adapt qmlrunner for our needs if it helps.

From quick scan of the docs, UBPorts have their own icons, units, and other style elements. So, it would make sense to create separate ubports style which is mainly copy of kirigami, but then use few elements from ubports API. Rather minimal work.

From earlier description of click packaging, it sounds a bit similar to flatpak. As it creates its own folder, icons will be located in some fixed location. That would make loading them trivial. As mentioned above, I presume that I can also add my own QML modules (in my case, Mapbox GL QML plugin https://github.com/rinigus/mapbox-gl-qml), latest Kirigami (Pure Maps has few features in convergent design that depend on it), Nemo DBus.

Now I would like to get someone who would like to package Pure Maps and test it. I can make all adaptations on Pure Maps side, add UBPorts "platform" and help with making it work. But I don't have a device with UBPorts on it nor expertise in click format. Feel free to send me direct email (as listed in AUTHORS.md of Pure Maps) if you want to help.

I would expect that it will take us few days to make it work (time assuming that we have 1-2 hours per day and taking into account that delays will be induced by differences in time zones and free time allocations). So, nothing major is expected.

Wait a bit. we are fixing few last issues and getting ready for release

@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!