Notices


Reply
Thread Tools
Posts: 1,548 | Thanked: 7,510 times | Joined on Apr 2010 @ Czech Republic
#561
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.
__________________
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 7 Users Say Thank You to MartinK For This Useful Post:
pichlo's Avatar
Posts: 6,445 | 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?
__________________
Русский военный корабль, иди нахуй!
 

The Following 3 Users Say Thank You to pichlo For This Useful Post:
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#563
Originally Posted by MartinK View Post
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.
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:

* 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:
Posts: 1,548 | Thanked: 7,510 times | Joined on Apr 2010 @ Czech Republic
#564
Originally Posted by rinigus View Post
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.
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.

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

Originally Posted by rinigus View Post
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.
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.

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)
 

The Following 4 Users Say Thank You to MartinK For This Useful Post:
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#565
Originally Posted by MartinK View Post
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.
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.
 

The Following 4 Users Say Thank You to rinigus For This Useful Post:
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
 

The Following 9 Users Say Thank You to ggabriel For This Useful Post:
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#567
Originally Posted by ggabriel View Post
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
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 7 Users Say Thank You to rinigus For This Useful Post:
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?)
 

The Following 3 Users Say Thank You to rinigus For This Useful Post:
Posts: 728 | Thanked: 1,217 times | Joined on Oct 2011
#569
Originally Posted by rinigus View Post
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?)
Just the plan version (not mt). Basically, I ldd'd the binary and ln'd the only lib that was "not found".
 

The Following 4 Users Say Thank You to ggabriel For This Useful Post:
Posts: 728 | Thanked: 1,217 times | Joined on Oct 2011
#570
Originally Posted by rinigus View Post
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.
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.
 

The Following 4 Users Say Thank You to ggabriel 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 16:01.