Active Topics
-
The N900 is now 15 years old! (7)
to Nokia N900 by Danct12 - 1 day, 13 hrs ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 2 days, 8 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 4 days, 17 hrs ago - more...
| The Following 7 Users Say Thank You to MartinK For This Useful Post: | ||
 |
|
2018-09-18
, 05:28
|
|
Posts: 6,447 |
Thanked: 20,981 times |
Joined on Sep 2012
@ UK
|
#562
|
WhoGo/Pure already accepts the "geo:X.xxx, Y.yyy" format. Am I missing something?
__________________
Русский военный корабль, иди нахуй!
Русский военный корабль, иди нахуй!
|
|
2018-09-18
, 08:40
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#563
|
Originally Posted by MartinK
So, in ideal world, you would have given a string and the server would have figured out using NLP whether its geo coordinates or address, for example. And, as a response, would give you POI and, if user was lucky, a POI data for something nearby. Sounds useful, but would be difficult to do at this stage:
Base on modRana user feedback I recently got an idea (or possibly even RFE) - would it make sense if the OSM Scout Server Location search API could also parse geographic coordinates ?
The general uses case is users with a geographic coordinate pair string they have copy pasted from another app or read and typed from paper and want to show it on the map and possibly do other app specific things with it (save to a POI database, use it as target for routing, etc.)
The API already does NLP based address parsing so I guess also checking if the query contains coordinates would be possible. For example, something like:
49.2, 16.616667
geo:49.2, 16.616667
49°12′0″ N, 16°37′0″ E
UTM: 5450947 617771 33U
If it matches such a format a single POI with the given coordinates would be returned. I guess an actual POI search should be done as well by default even if the query matches a coordinate pair - there could be places called after geographic coordinates.
This feature could be also combined by the POI type (I'm sorry that regular POI type support in modRana is taking so long :P) to tell OSM Scout Server with a special POI type ("coordinate_entry" ?) to only parse the query for coordinates, so applications could implement coordinate-search/entry/matching-only-views that would never trigger regular POI searches.
Having this done by OSM Scout Server would have the benefit of shared code that can be used by all applications that query the OSM Scout Server API instead of every application implementing this separately & differently. It also makes the API more similar to online POI search engines that usually can search for coordinates.
So, does this sound sane/useful ? Also, I would not be surprised if there already were some libraries from parsing coordinates from plain text like there is libpostal for address parsing.
* libpostal is not maintained, the last time I looked. so, we are not going to get it as an extension of libpostal. I will not be able to extend it that way in any reasonable timeframe
In some aspects, you could get the similar properties by using already available functionality of the server if you parse the coordinates in the client. Namely, you could search for "Any" type of POI in the guide search.
| The Following 3 Users Say Thank You to rinigus For This Useful Post: | ||
|
|
2018-09-18
, 09:10
|
|
Posts: 1,548 |
Thanked: 7,510 times |
Joined on Apr 2010
@ Czech Republic
|
#564
|
Originally Posted by rinigus
I don't think it needs to be nearby - the user could reasonably supply any coordinate, not necessarily something that is close to current position. It could be some interesting landmark they want to see or some point in a place they want to go in the future.
So, in ideal world, you would have given a string and the server would have figured out using NLP whether its geo coordinates or address, for example. And, as a response, would give you POI and, if user was lucky, a POI data for something nearby.
The idea is not to match the coordinates to an existing POI from the database - it's simply to parse the coordinates string.
Originally Posted by rinigus
That was actually meant just as an example - I just meant a server side code shared by all OSM Scout API users, not necessarily putting the parsing into libpostal itself.
Sounds useful, but would be difficult to do at this stage:
* libpostal is not maintained, the last time I looked. so, we are not going to get it as an extension of libpostal. I will not be able to extend it that way in any reasonable timeframe
Originally Posted by rinigus
Yes, I can certainly add some code in modRana that turns strings into coordinate pairs (likely something regexp based), but that can actually be far from trivial if it should be robust and accept many types of input (and possibly advanced types of coordinate input such Geohash, etc.). So some sort of shared rhather than application specific code sounds like a good idea to me.
In some aspects, you could get the similar properties by using already available functionality of the server if you parse the coordinates in the client. Namely, you could search for "Any" type of POI in the guide search.
On the other hand there might need to be something client side anyway, even as a fallback, otherwise modRana coordinate input would only work when OSM Scout Server is installed, which still needs to be done manually on Sailfish OS (eq. it's not yet possible to pull it in as dependency at modRana install time).
So I guess an alternative solution could possibly be done - to at least share the (Python) coordinate parsing code between different navigation apps (apparently Pure Maps already has some coordinate parsing support, I can start with that). This should be quite simple as the code should be a rather self-contained input-output function. If wrapped by a simple Python script I can imagine non-Python applications making use of this code as well, by calling it as an utility.
__________________
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)
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 4 Users Say Thank You to MartinK For This Useful Post: | ||
|
|
2018-09-18
, 10:04
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#565
|
Originally Posted by MartinK
Sounds reasonable - it makes sense to share as much as we can across the clients. Also, there are probably many users who prefer online services and not having the server on device.
So I guess an alternative solution could possibly be done - to at least share the (Python) coordinate parsing code between different navigation apps (apparently Pure Maps already has some coordinate parsing support, I can start with that). This should be quite simple as the code should be a rather self-contained input-output function. If wrapped by a simple Python script I can imagine non-Python applications making use of this code as well, by calling it as an utility.
| The Following 4 Users Say Thank You to rinigus For This Useful Post: | ||
|
|
2018-10-15
, 15:48
|
|
Posts: 728 |
Thanked: 1,217 times |
Joined on Oct 2011
|
#566
|
Hi, folks,
I'm not sure if this has been posted before, so apologies if it's been discussed already. osmscout-server comes linked to the SFOS provided libboost_filesystem 1.51.0 - this is ok. However, SFOS 3 may come with libboost_filesystem 1.66.0, so osmscout-server would fail to start.
SFOS 3 is still not even available for beta (it isn't even version 3 yet), but I wanted to give you a headstart - just bear in mind that a) the library _may_ change; b) 1.66.0 _may_ be the version, or it could be another one.
hack note: it works if I ln -s 1.66.0 to 1.51.0
Gabriel
I'm not sure if this has been posted before, so apologies if it's been discussed already. osmscout-server comes linked to the SFOS provided libboost_filesystem 1.51.0 - this is ok. However, SFOS 3 may come with libboost_filesystem 1.66.0, so osmscout-server would fail to start.
SFOS 3 is still not even available for beta (it isn't even version 3 yet), but I wanted to give you a headstart - just bear in mind that a) the library _may_ change; b) 1.66.0 _may_ be the version, or it could be another one.
hack note: it works if I ln -s 1.66.0 to 1.51.0
Gabriel
| The Following 9 Users Say Thank You to ggabriel For This Useful Post: | ||
|
|
2018-10-15
, 20:17
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#567
|
Originally Posted by ggabriel
As a redundancy from Jolla Harbour days, we still have all libs shipped with the application. Along with them, boost libs. So, I would expect it to be fine. Thanks for heads up, though! Let's see whether OBS will start complaining when the SDK latest will be switched.
Hi, folks,
I'm not sure if this has been posted before, so apologies if it's been discussed already. osmscout-server comes linked to the SFOS provided libboost_filesystem 1.51.0 - this is ok. However, SFOS 3 may come with libboost_filesystem 1.66.0, so osmscout-server would fail to start.
SFOS 3 is still not even available for beta (it isn't even version 3 yet), but I wanted to give you a headstart - just bear in mind that a) the library _may_ change; b) 1.66.0 _may_ be the version, or it could be another one.
hack note: it works if I ln -s 1.66.0 to 1.51.0
Gabriel
| The Following 7 Users Say Thank You to rinigus For This Useful Post: | ||
|
|
2018-10-16
, 07:13
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#568
|
Re boost: does your hack link -mt or plain version of boost library? Maybe plain version is missing due to some new dependency that was introduced recently (valhalla?)
|
|
2018-10-16
, 09:00
|
|
Posts: 728 |
Thanked: 1,217 times |
Joined on Oct 2011
|
#569
|
Originally Posted by rinigus
Just the plan version (not mt). Basically, I ldd'd the binary and ln'd the only lib that was "not found".
Re boost: does your hack link -mt or plain version of boost library? Maybe plain version is missing due to some new dependency that was introduced recently (valhalla?)
| The Following 4 Users Say Thank You to ggabriel For This Useful Post: | ||
|
|
2018-10-16
, 09:01
|
|
Posts: 728 |
Thanked: 1,217 times |
Joined on Oct 2011
|
#570
|
Originally Posted by rinigus
You mean in /usr/share/harbour-osmscout-server/lib/ ? The lib that couldn't be referenced (libboost_filesystem) is not there, but I can see the -mt version.
As a redundancy from Jolla Harbour days, we still have all libs shipped with the application. Along with them, boost libs. So, I would expect it to be fine. Thanks for heads up, though! Let's see whether OBS will start complaining when the SDK latest will be switched.
| The Following 4 Users Say Thank You to ggabriel For This Useful Post: | ||
 |
| Tags |
| geocoder, linux, offline maps, router, sailfish os, tiles |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 13:45.
The general uses case is users with a geographic coordinate pair string they have copy pasted from another app or read and typed from paper and want to show it on the map and possibly do other app specific things with it (save to a POI database, use it as target for routing, etc.)
The API already does NLP based address parsing so I guess also checking if the query contains coordinates would be possible. For example, something like:
49.2, 16.616667
geo:49.2, 16.616667
49°12′0″ N, 16°37′0″ E
UTM: 5450947 617771 33U
If it matches such a format a single POI with the given coordinates would be returned. I guess an actual POI search should be done as well by default even if the query matches a coordinate pair - there could be places called after geographic coordinates.
This feature could be also combined by the POI type (I'm sorry that regular POI type support in modRana is taking so long :P) to tell OSM Scout Server with a special POI type ("coordinate_entry" ?) to only parse the query for coordinates, so applications could implement coordinate-search/entry/matching-only-views that would never trigger regular POI searches.
Having this done by OSM Scout Server would have the benefit of shared code that can be used by all applications that query the OSM Scout Server API instead of every application implementing this separately & differently. It also makes the API more similar to online POI search engines that usually can search for coordinates.
So, does this sound sane/useful ? Also, I would not be surprised if there already were some libraries from parsing coordinates from plain text like there is libpostal for address parsing.
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)