MartinK | # 561 | 2018-09-18, 01:00 | Report

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.

pichlo | # 562 | 2018-09-18, 05:28 | Report

WhoGo/Pure already accepts the "geo:X.xxx, Y.yyy" format. Am I missing something?

rinigus | # 563 | 2018-09-18, 08:40 | Report

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.

MartinK | # 564 | 2018-09-18, 09:10 | Report

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.

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.

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.

rinigus | # 565 | 2018-09-18, 10:04 | Report

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.

ggabriel | # 566 | 2018-10-15, 15:48 | Report

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

rinigus | # 567 | 2018-10-15, 20:17 | Report

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.

rinigus | # 568 | 2018-10-16, 07:13 | Report

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?)

ggabriel | # 569 | 2018-10-16, 09:00 | Report

Just the plan version (not mt). Basically, I ldd'd the binary and ln'd the only lib that was "not found".

ggabriel | # 570 | 2018-10-16, 09:01 | Report

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.