Notices

So looks like the tests have been somehow at fault, as they are compiled against libpostal in some ultra weird manner. So for now I've hard-disabled them (dropped their compilation from the makefile) and the build finally runs to the end. This should be good for now, later one for the actual package review something more robust (possibly including reporting the issue upstream) might be needed. I'll open a PR for the libpostal packaging soon, just have to cleanup my changes a bit.

Anyway, as far as I can tell this concludes the missing dependencies & I can finally start packaging OSM Scout Server itself.

Sounds great! Please note that I haven't tested any 'make install' on desktop Linux. The path for directories is coded in pro-file and I was waiting till you get here and help me to fix it. So, if you know what's the common way to specify paths then please do so and send PRs

New release is out: 1.7.1. With the 1.7.0, followed by 1.7.1, I focused on geocoder enhancements.

New geocoder supports aliases when you search for data using guide search (Nearby). Aliases, as suggested by @palbr (thank you!), are pulled from https://wiki.openstreetmap.org/wiki/...pecial_Phrases with the used ones listed at https://rinigus.github.io/osmscout-server/tags/ . The list is also available as an API call, via poi_types URL, allowing us later to extend WhoGo Maps and modRana to automatically provide it to the users (if the client developers will approve it). Tag aliases are also used when returning the search results to identify objects in a localized manner.

Geocoder now imports and allows you to search for POIs without names (playground, ATM, toilets, ...), Again, suggested by @palbr. This is done for guide (nearby) search. When using guide search, its also possible to separate search by name or type when looking for POI (at least one has to be specified). Released WhoGo Maps already supports it, modRana is under development. Corresponding map update has been released and available if you check for updates in map manager. Note that only geocoder-nlp maps were updated this time.

As reported by @legacychimera247, some villages were missing in the search. This is fixed now, but it looks like I have inserted these missing villages into a bit high level in the hierarchy. This will be fixed in near future.

Many more types are now imported and supported by geocoder. Let me know if something important is missing.

The latest version of translations has been also pulled into the package. Thank you to all the translators doing great job!

Hello,
I am deeply in love to osm!
But yhis darling does not allow to use sdcard .
I created a directory to sdxard ( devel-su) gave rights and osm stopped nagging "no rights" but then there is open database error.

( there is / nemo/ Maps.OSM) I also tried to copy that but again even after givin rights to/ run/nemo I have a problem , not able to create...)

running sailfish X

I do not think it has something to do with X or Jolla C (which I am using).
Why using devel-su (root) at all?
Just create any directory as normal user (nemo) and assign this directory within settings of OSM. Done.

My own strategy (inherited back from older setups with other mapping software) :

OSM server set to use : /home/nemo/Maps/OSM

/home/nemo/Maps is a symlink that point to /run/media/nemo/SDCard/Maps

/run/media/nemo/SDCard is a SDXC card reformatted to a linux partition (BTRFS in my case, but will work as well with EXT4 or F2FS).

/run/media/nemo/SDCard/Maps and /run/media/nemo/SDCard/Maps/OSM
are owned by nemo:nemo,
access rights 0775 (rwxrwxr-x)

works flawlessly.

New maps are out and available for download.

It looks like the last time I uploaded older Mapbox GL tiles. This time, all the data should be up to date, about 1-2 weeks old extract from OSM Planet.pbf.

New version is out - 1.8.0

This version is linked directly to Valhalla via its C++ API. As a result, OSM Scout Server provides Valhalla's exported functionality in its own process. Earlier, the server had to start Valhalla separately and work as a proxy between map clients and Valhalla. Now, this extra HTTP connection is skipped.

For end users, such integration means that, after upgrading to 1.8.0, OSM Scout Server Module: Route can be uninstalled. Its not used anymore.

For map client developers, there are lots of exciting features exported, in addition to routing. Some of them are:

* map matching - for just-in-time snapping position to the road/path network; for exporting recorded GPX as a set of navigation instructions.

* time-distance matrix calculation between set of locations.

* finding optimized route between set of locations (so the order and route are optimized).

* isochrone - for example, where can I get in 30 minutes by car from here? see example at https://cdn-images-1.medium.com/max/...Lqn7HoMo_8.png

Corresponding section in README: https://github.com/rinigus/osmscout-...other-services .

Note that while elevation service is exported as well, I don't distribute the data for it. I will look into it, but it sounded like it takes 1.2TB for a planet - bit excessive for mobile. If they find the way to reduce the data requirements, would be great way to get elevation-aware routing and its visualization.

For packagers (@MartinK), the server doesn't need anymore prime_server, zmq. I was made aware of this Valhalla C++ API few days ago (heard about it earlier when they started working on it in 2017, but didn't check the progress). I made a new packaging for Valhalla (https://github.com/rinigus/pkg-valhalla-lite) that is preferred for the compilation of the server. This packaging and the full Valhalla packaging (https://github.com/rinigus/pkg-valhalla) scripts were also modified to use cmake, as they switched the build system.

As always, the translators have updated the translations. I will try to remember to release point releases 1.8.x this time and get translations up-to-date. Sorry for delays.

I have added car styles for Mapbox GL maps. These are right now just increasing the priority of the gas stations, parking spaces, and such. Later we can maybe polish it further, feel free to think on how to improve them

I am planning to work on map matching and exploring it with the map client. Very rough POC has been done and my phone is able to map match almost in real time already with the current API (you can see the location moving as you are, but with the direction found using map matching). So, the early results are promising, but there is still much to do.

Quick notice: WhoGo Maps (and probably Poor Maps) check whether routing module is installed when they list available routers. So, keep the routing module on device until corresponding change is done in WhoGo Maps: https://github.com/otsaloma/whogo-maps/pull/45

New release is out: 1.9.0

This release brings OSM Scout Server to D-Bus and makes it very simple to use map matching functionality in QML apps.

Via D-Bus, the server allows now to establish a session with it by the external application and receive current street name, speed limit and the speed assumed by the routing engine for cars.

For QML, I made a QML type that can utilize this functionality: https://github.com/rinigus/positions...mapmatched-qml . It is expected to be a drop in replacement for PositionSource in the code of the application. When map matching mode is requested, it will establish a contact with OSM Scout Server, wake it up via systemd if users have that feature enabled, and will start providing map matched coordinates and other data. To simplify publishing, I would suggest to copy PositionSourceMapMatched.qml into the source tree of the application and include it. Example usage is shown in https://github.com/rinigus/positions...ample/main.qml

PositionSourceMapMatched also simplifies app development by providing facilities for testing in the absence of GPS signal and timing information. See description in README and example.

As with regards to timing, when measured on 1+X (onyx) during ~20 min drive, it takes on average <40ms per single call from QML to map matching service via D-Bus, for processing its response, until the position and associated data are updated. The longest call over that test was <100ms.

The current DBus API can be extended to include other functionality of the server, if there is interest.

In addition, map matching support can be extended further to include other data provided by Valhalla. One example use is to utilize map matching to follow navigation progress. Valhalla's edges all have global IDs and one can just check the progress along the edge, the current edge, and the expected edge on the basis of expected route. While making navigation instructions processing efficient, that would make processing Valhalla's specific.