Notices

While its good to release in the Harbour, its rules should not be on our way and the releases in OpenRepos are very much appreciated as well.

In this case, as you see from the discussion above, it could be just manpower limitation on Jolla's part (in terms of not working on QtLocation). We could try to chip in as a community, if there is someone around who has knowledge and/or time to look into QtLocation 5.6 adaptation

Ok, that was a very good hint. Of course OpenRepos are fine with me. I already have an app which is released to openrepos only because of Jolla store restrictrions.
So I in my yaml file I had:
And changed it to:
But now there is an error while compiling:
Do I need to install this lib on the phone first?

Your requirements are correct. Unfortunately, as we discussed above, qt5-qtlocation >= 5.6.0 is not available yet on Sailfish. To my knowledge, no-one has compiled and (if needed) patched it. All we can do is either try to get it running ourselves or wait till Jolla gets developers on it.

I have just released a module for the OSM Scout Server via Harbour. It looks that through such modules I would be able to split the server package into parts and supply multiple executables when needed. Users would still have to run only the main executable to get full functionality of the server - OSM Scout Server.

Right now, the fonts module is released. It was done early to ensure its released before future upgrades. I am working on getting one more module out which would contain Valhalla's routing engine. At present, only these two modules are planned.

The modules will be released via Harbour and OpenRepos. Since the timing of OpenRepos is under my control, I don't have to rush them out early on that channel.

For users, that would mean installation of additional programs/apps via Harbour or OpenRepos. On server's start, the availability of the modules is checked and, if missing, installation is suggested.

I am planning to update the modules separately, as needed. I hope that this split will not create further confusion, at least not in long term.

I am planning to release a new version in few days. Among other developments, this version will have a libosmscout library updated to incorporate latest changes in the library. As a result, the new maps for libosmscout would be incompatible with the old versions of the server. The maps would be uploaded to the modRana.org probably tonight or tomorrow. So, if you depend on the maps and are planning a trip these days, be aware of possible disruption in the maps download service.

Thanks. It would be better to install the osmscout-server dependencies without icons rinigus?

There have been two main reasons for using a custom QML map component:
- lack of functionality & unconvincing performance of QtLocation
- QtLocation not being Jolla Store compatible and would thus be preventing modRana from being distributed via the Jolla store

Number one likely is less of an issue nowadays due to the ongoing work on QtLocation but it's quite a shame number two still stands after all those years and complicates application development if any mapping/navigation functionality is required.

In any case this is what modRana is using:
https://github.com/M4rtinK/modrana/b...l/PinchMap.qml
It's a QML/Javascript component for efficient display of tiled maps with overlay support. Feel free to use it if you want (it's GPLv3) but I have to note it's not fully standalone and you would likely have to also take the related modRana subsystems as well. For example map tile download and caching is done by a Python module, etc. I have tentative plans to make QML map component more standalone and more easy to reuse in other application by I haven't really got to that.

For that reason it might make sense to also take a look at the QML map component used by Foursail:
https://github.com/Maledictus/foursa...l/PinchMap.qml

It should be quite similar to the modRana PinchMap (both modRana and Frousail projects started with the old PoinchMap.qml from AGTL), a bit less advanced and possibly quite a bit more standalone.

I presume you are talking about modules, right?

It would be better if I could use normal linux-style dependencies, but there are limitations when we want to have apps in the Harbour. Another limitation is imposed by RPM (or more specifically, the way we install them).

1. If I want to publish via Harbour, I cannot have multiple executables in one package. I can add as many libraries as I want, as much data, but not executables. I maybe able to smuggle one as a zipped file and unpack on a start, but that becomes iffy from the security point of view.

Valhalla is provided as its own executable that is run by the server if needed (if user wants to choose it). In the end, this will allow me to keep Valhalla up-to-date with relatively small time demand. So, I needed to have a mechanism for delivering multiple executables.

2. If we forget about Harbour and go only through OpenRepos then I'll be able to install the modules as dependencies. However, while highly unlikely and extremely hypothetical, imagine, if someone wants to temporarily uninstall such a brilliant software as OSM Scout Server is. In this case, due to the lack of "apt-get autoremove" (or similar alternative in almost all other Linux package managers), users would be stuck with these dependencies on their devices. On my device, OSM Scout Server and its modules, take the top spot in /usr/share, then place #3 and #7. These are big packages and users should have an ability to simply remove them.

As for extra icons, I would suggest to put modules into some folder far away and not touch them unless you need to uninstall them for one reason or another.

I have just released a new version: 0.10.0

In short, this release is one of the major ones. This release has rather large amount of new features, so I'll try to address them one by one:

Search covering all databases

If you use Geocoder-NLP for search, its performed over all countries or territories that you have on device. Search is started from the map selected in GUI and later the data in other databases is considered. If you want to limit search to only one database, see Geocoder-NLP settings.

New backend: Valhalla

This is a major new functionality. I have ported Valhalla to SFOS. Valhalla is a routing engine behind Mapzen routing service. Now you could use it offline on your devices. Its fast, allows you to route between countries, and there are many other interesting features that are or could be easily made available to client programs. Main problem has been on how to distribute the datasets for Valhalla. For that, packaging the datasets and their download support had to be written as a part of the new release. Hence it took a while to implement it.

Since Valhalla is a full-blown server by itself, the communication between Valhalla and the client uses Valhalla's own protocol. Clients have to make adjustments to support it. Right now, before these changes are done in the clients, use libosmscout for routing.

Poor Maps and modRana do not support Valhalla backend yet. For Poor Maps, support is "simple" by making a copy of Mapzen Turn-by-Turn plugin and adjusting its URL + used geocoder. For modRana its probably a bit more complicated, unfortunately. Please wait for corresponding release and the new routing options in the clients.

Since its a new backend, use unsubscribe/subscribe for all the countries and territories that you update. As you did with Mapnik.

Libosmscout

The backend has been updated and new version of the maps has been uploaded to the data.modrana.org for distribution. This version should play better with OSM Scout by @Karry. But note that full compatibility is never guaranteed.

Storage of libosmscout datasets is also made optional. If yo don't use it, you can now opt out.

Modules

This release is the first one that uses modules. There are two modules: Fonts and Route. Fonts are packaged separately to avoid huge downloads on every update.

Fonts module contain Noto fonts by Google and should be able to display all possible languages, to my knowledge. It should be surely more than native SFOS fonts are supporting (rejoice people of Sri-Lanka).

Route module contains Valhalla routing engine that had to be distributed as a separate executable to allow separate updates of Valhalla and the server and to comply with Harbour rules.

Please install the modules with this release. If you don't have the module installed, a warning is displayed in the main view of the server.

Translations

There are two targets for translations now - OSM Scout Server and Valhalla. Valhalla's routing instructions come from Valhalla itself. So, the client programs have to request the corresponding language using Valhalla API. Since we are using Sailfish, ability of selecting en-US-x-pirate locale would be great to get authentic Sailfish navigation experience. I hope that Poor Maps and modRana could implement such selection .

As for translators, Valhalla's routing instructions are translated via Valhalla project. This is not done via transifex, but some other arrangement. See translations README for updated pointers (https://github.com/rinigus/osmscout-...ions/README.md)

For translators: I'll be happy to release as many point releases as needed. So, we could expect several 0.10.x releases with the updated translations.


Current state and upcoming new default

To put things into perspective: As with libpostal, to my knowledge, SFOS is the first mobile platform supporting Valhalla in offline mode. These are major libraries in the field and I do wonder, when the clients adopt Valhalla, what is the real life performance of SFOS maps vs others (Android, iPhone)...

As a part of the discussion with @otsaloma and @MartinK, it was suggested to select a sensible default backend(s) and mainly support that. I am mainly using Mapnik / Geocoder-NLP / Valhalla myself and I plan to develop and support this combination of backends. As soon as the adaptation of Valhalla by clients will be ready, its planned to make Mapnik / Geocoder-NLP / Valhalla combination as a default. Note that this combination allows you to render, search, and route between all the maps on device (if the maps are for the territories next to each other, though).

Libosmscout backend is there to stay. If you wish you could still use libosmscout, but please note that its testing would be limited. Libosmscout has a smaller datasets, which is currently its main advantage.


What's next

Before getting 1.0 out, I would like to mainly address the following.

* Helping clients to work with Valhalla backend. Poor Maps is easy on paper since it has support for the protocol already. I just don't know how to make it so that there would be minimal code duplication between OSM Scout and Mapzen routers. modRana is trickier for me - I am not familiar with its implementation of routing.

* Bugfixes. Please report bugs, I'll try to fix them as soon as I can

* Polishing. I am planning to mainly polish the experience. It should be easy for users to start using offline maps. So, if you have ideas on how to make it simple, wish to write documentation, howto guides, or just record all steps that you need to make it work on a fresh install. I am planning to make a small wizard on the first start to help with the selection of backends and settings sensible defaults.

* Night mode for Mapnik. Mainly design of the style. Default style adjustments / comments are always welcome.

* Geocoder-NLP does not support "Nearby" search requests. I am planning to implement that as well.

PS: Hopefully I haven't forgotten anything.

It's such a small change to Mapzen's online Valhalla, that I can do the Poor Maps implementation myself. And I'll probably just duplicate the code, it's fine. I'll ping you on GitHub so you can check the work. But, I'll want to do some testing too -- I'll probably have the time to do it over the weekend.