Notices

Your suggestion is very obscure and hardly generalizable. Traffic is inherently online and trying to hack vague data to an offline graph model would be a lot of trouble for little gain.

Hello otsaloma, thanks so much to come to clarify this.
I know you are professional in this area; Same to @rinigis. The problem is that you still do not understand my trick. I will explain more better I guess...

If we even forget about online/offline aspect, I am not aware of any data that is available on traffic conditions and covering large fractions of the world. By just monitoring your current speed and comparing it to the speed limit, I cannot make a choice of the future road since I don't have any data to base it on.

Actually, the best offline selector in this case is you - as a driver. You see traffic ahead and can decide to either stay or turn. If you turn, Valhalla will reroute accordingly. And again, you could alter your path as well.

Yeap rerouting is the solution of this too, you right. I just was thinking on funny feature, where whogo could be detect traffic by using some offline datas then whogo-maps could give an option to the driver if accept go to other way. Really Really Funny.
On my side I like offline datas. So once again thanks @Rinigus/@Otsaloma for supporting offline datas.

I have just merged Qt Quick 2 port of the server to the master branch. This allows to use the server on regular Linux with QML GUI. GUI is shaped in similar way to the GUI on SFOS, so, in theory, it should work on mobile Linux platforms as soon as they support QML QtQuick2. An obligatory screenshot is attached.

At present, there is a lot of code duplication in QML interfaces (Silica and QtQuick). Let's see, if we will get users and developer(s) on QtQuick side, I will organize it better by splitting more platform-dependent and independent code parts.

@MartinK, if you are packaging it for Fedora, maybe you could use qtquick version?

Sure, that's definitely the plan & thanks a lot for working on the QtQuick GUI!

At the moment I'm going "up" from the OSM Scout Server dependencies, and I'm currently trying to get prime_server, which is (as far as I can tell) a Valhalla dependency, to build on Fedora. I've hit some weird errors during compilation, but I'm suspecting it might have been some temporary Rawhide issue.

I'll give it another go tomorrow & will try to see if I'll get the same issues when I try the F27 and F28 mock targets.

BTW, once I manage to build the packages locally, I'll start putting them to this COPR repository:

https://fedoraproject.org/wiki/Releases/Rawhide

(COPR is basically the Fedora counterpart of OBS, with a significantly more sane and maintainable codebase than OBS has. )

@MartinK: if you have issues, check which repository was used at mine OBS project. Some dependencies were built, at least at some point, against the patched versions. It may have been to resolve SFOS case, but maybe something else.

prime_server is ZMQ-based server used in Valhalla and is needed, indeed.

As for OSM Scout Server itself, you may want to look at PRO file and suggest a better way to specify valhalla's and fonts path. Since you have more experience with packaging, I would wait for your advice on it.

New maps are out, Planet downloaded at the end of April. The main change in packaging of Valhalla. Now, I grouped the tiles somewhat differently and the planet is split into 1600 packages instead of 16000, as it was before.

The format is the same as before, so there are no incompatibilities with the current/bit older version of the server. All should work, as before.

For the end users, it would mean somewhat larger section of the Planet grabbed when downloading a country. While the neighboring territories will share the data, we end up with a bit more than we wanted to download.

For those who are involved in distribution of the maps, this suddenly makes it much easier to handle uploads/downloads. So, this change was made to make it a bit more sane syncing the servers.

Hi rinigus, How do I download larger areas? I had some older maps on my device and decided to download the new maps. But now I'm quite unsure. Before I had a package "Germany" that was nearly 7 GB. But now Germany is spitted up in different federal states and some of them are even splitted up further. All german maps together would be much more than 20 GB. And I would have to choose a lot of areas seperately. Is that by intend?

Regarding the size: remember that Rinigus has modified it so that now it can also serve vector data to application doing openGL (like WhoGo Maps, Laufhelden, etc.) and not only bitmap tiles.
That requires even more data on your sd card (see the new "Mapbox GL country-specific" data for each map).