Notices


Reply
Thread Tools
Community Council | Posts: 4,432 | Thanked: 11,052 times | Joined on May 2012 @ Southerrn Finland
#511
Originally Posted by carlosgonz View Post
me too, liberapay is rejecting accept Amex card, then i am looking to diferent label to truly support mr-rinigus
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.
 

The Following 4 Users Say Thank You to juiceme For This Useful Post:
carlosgonz's Avatar
Posts: 63 | Thanked: 170 times | Joined on Jul 2018 @ .
#512
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
__________________
novena + talos ll + GNU_debian os
nokia n900 + nokia n9 + jolla 1 + jolla c + xperia x sf
ti chronos + lg d asteroid + samsung w3 tizen
 

The Following 2 Users Say Thank You to carlosgonz For This Useful Post:
carlosgonz's Avatar
Posts: 63 | Thanked: 170 times | Joined on Jul 2018 @ .
#513
Originally Posted by juiceme View Post
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.
bad news, i hope liberapay still keep going
__________________
novena + talos ll + GNU_debian os
nokia n900 + nokia n9 + jolla 1 + jolla c + xperia x sf
ti chronos + lg d asteroid + samsung w3 tizen
 

The Following 2 Users Say Thank You to carlosgonz For This Useful Post:
Posts: 627 | Thanked: 3,257 times | Joined on Aug 2016 @ Estonia
#514
Originally Posted by carlosgonz View Post
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
 

The Following 4 Users Say Thank You to rinigus For This Useful Post:
Posts: 627 | Thanked: 3,257 times | Joined on Aug 2016 @ Estonia
#515
Originally Posted by carlosgonz View Post
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
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.
 

The Following 3 Users Say Thank You to rinigus For This Useful Post:
Posts: 1,491 | Thanked: 7,139 times | Joined on Apr 2010 @ Czech Republic
#516
Originally Posted by rinigus View Post
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.
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.

Originally Posted by rinigus View Post
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.
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.
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
 

The Following 5 Users Say Thank You to MartinK For This Useful Post:
pichlo's Avatar
Posts: 5,533 | Thanked: 17,227 times | Joined on Sep 2012 @ UK
#517
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.
__________________
In particle accelerators atoms are indeed not only touching each others. But banging together in a massive explosive orgasm.
-- nieldk in a TMO post
 

The Following 4 Users Say Thank You to pichlo For This Useful Post:
Posts: 627 | Thanked: 3,257 times | Joined on Aug 2016 @ Estonia
#518
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.
 

The Following 17 Users Say Thank You to rinigus For This Useful Post:
Posts: 1,491 | Thanked: 7,139 times | Joined on Apr 2010 @ Czech Republic
#519
Originally Posted by rinigus View Post
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).
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.
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
 

The Following 11 Users Say Thank You to MartinK For This Useful Post:
Posts: 627 | Thanked: 3,257 times | Joined on Aug 2016 @ Estonia
#520
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.

Originally Posted by MartinK View Post
...

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.
...
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.
 

The Following 3 Users Say Thank You to rinigus For This Useful Post:
Reply

Tags
geocoder, linux, offline maps, router, sailfish os, tiles

Thread Tools

 
Forum Jump


All times are GMT. The time now is 12:18.