Notices

Liberapay died, something to do with their banking provider.
The odd thing about it is that they send me an email that they cannot continue to operate any longer, however on their website there is no mention about it.

I want to talk on libosmscount, seems not updated in the server, I would like to know the reason?. Also the name of the osmscountserver is too big, is out of layout of safish names.
thanks

bad news, i hope liberapay still keep going

They are working on it, as I can see from Github issues. Patience is all what's needed at this stage

Re libosmscout: I decided to maintain only the backends which I think are the best and which I am using personally. I believe that, without personal usage, I cannot monitor nor fix the issues occurring with the backends.

In december 2017, I asked for help in maintaining libosmscout in the corresponding developer list and most probably notified here as well. So far, nobody has stepped up and worked on upgrading the backend interface to the newer versions of libosmscout.

I have reorganized the code and import scripts to make libosmscout part independent from others - so all should be ready for its update if someone is interested. However, note that OSM Scout by Karry is progressing nicely and maybe the users of this backend should look into that application. Don't know the current status regarding routing and search though.

Re name OSM Scout Server: yes, its long. And there are historical reasons for that. However, rebranding is significant work and there should be initiative / reason for it (github and transifex repo, pointers at openrepos, docs, aggregation lists and such would have to be changed). And this work will have to be done instead of the development.

For the record, In my efforts (at the moment rather slow due to summer) to package OSM Scout Server to Fedora I plan to skip the libosmscout based backend, at least for the first packaging round.

I agree, while we got into an interesting situation by simple historic development, it's not really causing any actual issues AFAIK that would warrant a complicated rebranding exercise.

What's wrong with the name? OK, it's not very obvious and it took me a while to figure out that this is something I need but now I quite like it.

New version is out: 1.10.1

Starting from this version, I changed the license from LGPL3 to GPL3. I think it applies better, since the server is a regular application and there is no reason to use LGPL in this case.

For users, the main new feature is search along the route. Its been my intention to implement it from the beginning, just was postponing it from 0.1 till now. So, starting from 1.10.x, you can find all upcoming fuel stations, cafes and such in a specified distance from route. Works quite well - for a route of 900 km, it finds all cafes in 7 seconds on onyx. Corresponding PR has been submitted for WhoGo Maps. For modRana, I'll be happy to help and consult when @MartinK will find the time to deal with it (its mainly limited by my knowledge of modRana source).

To implement the search, I have added POST request support by the server. This allows the clients to push the data, such as route path, using JSON object in POST body. All the details are documented in accompanying README, sections https://github.com/rinigus/osmscout-....md#url-schema and https://github.com/rinigus/osmscout-...ition-or-route .

Finally, we have Italian translation coming up by @Watchmaker - thank you! Also, all other translations have been updated to their latest version, as for yesterday.

I have concluded most of my summer related vacation activities and should thus be able to concentrate on modRana development yet again (and I've actually used it quite a bit while vacationing, even spotting a bug or two).

We can certainly "cook something up" with this new feature & I'm standing by to provide any help needed with modRana development, including documenting unclear stuff & fixing/improving weird API.

The first thing that comes to my mind for "search along route" is searching along the currently active route (if any). I'm sure there are more advanced options, but this seems like possibly a good start.

This could be implemented as a search screen similar to the screens currently used for location/local/Wikipedia search, possibly with some additional options:
- search origin (route start/current position on route (if any))
- search distance (full route, next N km; pending any OSM Scout Server limitations)

It's a bit unclear where to put these settings, as there are currently none for the existing search pages. WhoGo maps handles this by a page that triggers the search and switches the the results, which still seems a bit cumbersome to me & prevents easily returning to existing result listings. So a settings page for search-around-route easily accessible via a menu seems like a better match to me, it can easily accessed when needed but does not need to be traversed every time.

The could be the GUI part at a glance, but how does modRana actually request and return search results ?

The search interface is exposed to QML via the Qt5 GUI module (modules/gui_modules/gui_qt5/gui_qt5.py) and a search id string is used to differentiate what to search for. The Search class has a hardcoded list of functions to call for various search id strings.

In general the GUI asynchrously request a search and then gets a signal once search results are available.

All the search functions are currently provided by the (not well named in retrospective) onlineServices module (modules/mod_onlineServices/mod_onlineServices.py), even offline search calls handled by OSM Scout Server (hey, it goes over localhost, that's basically a network :P).

You may notice all the functions have the Async suffix - that's because they are asynchronous & the caller is supposed to supply a callback that will be called once results for the search query are available. The signature for the asynchronous local search function looks like this:

def localSearchAsync(self, term, callback, around=None, maxResults=32, sensor='false'):

There is the term to search for, the callback to call once results are available and some additional options (where to center the search, how many results to request, etc.).

If there are more providers available for the given search category, the *Async function decides which one to use and instantiates the asynchornous online/offline provider in a thread, returning the (unique) thread name, which can be in some cases useful to wait for the query to finish via the modRana ThreadManager interface.

As I don't thing we have any other suitable provider of search-along-route, the *Async function can be very simple, just always calling the OSM Scout Server provided search-along-route offline provider.

The offline providers live in modules/mod_onlineServices/offline_providers.py and inherit from the POIProvider class. The general idea is to implement a synchronous "search()" method and the POIProvider takes care of the the rest, including running the method in a thread and passing any arguments the *Async function passes to the searchAsync() function of the provider to the search() function.

To summarize, it could look like this:

1) QML GUI page requests search along route
2) Python Qt 5 GUI module resolves search function & registers a callback
3) onlineServices function searchAlongRoadAsync() instantiates the provider & feeds it data
4) the offline provider executes the query in its search() function, feeding OSM Scout Server the needed data & waits for reply
5) callback in the Qt 5 GUI module is called with results (including possible errors)
6) the QML GUI is notified about the results via Python -> QML signal & displays the results

That should be more or less it at a glance, please let me know if anything is unclear or even if you think the interface is bad and could be improved in some way.

Took longer than expected to reply, but I became rather stretched with the recent developments. Let's see if it was such a good idea to get into the client GUI software in full. But that I will know somewhat later, when the setting up and fixes are done. Anyway, I would expect to have even less time to code for modRana specifically.

I have implemented the search along the route for WhoGo using the current road only. So, its active only if there is a road available. As for limitations, OSM Scout Server searches the full road with the search optionally from some position. Imagine driving along road and looking for upcoming gas stations. So, some options are needed to be specified.

To me, it looks like an additional Search on modRana Search screen, next to Local and Wikipedia. As for options, you would probably want to add some options for Local search as well, to get support for specifying type and name in OSM Scout Server options. Probably also distance from current location or road. There are not that many options, so, screen can be shared with the results, but still some.