Notices

for me offline it is much better that online,Both have advantages and disadvantages!!!
what about REroute in PoorMaps @otsaloma There is possibility to fix it?

Rerouting is planned, yes, and possible, in time.

perfect! @otsaloma

Just in case this is the code modRana uses to check if the current route is being followed:

https://github.com/M4rtinK/modrana/b..._turnByTurn.py

If should be fairly efficient as it works fine even on the N900 for fairly long roads. Feel free to (re)use.

This is announcement for a new release: 0.6.0

This release introduces libpostal (https://github.com/openvenues/libpostal ) based geocoder that is expected to significantly improve the search functionality of the server. To my knowledge, its the first time that libpostal has been used on mobile. For background and the requirements, see earlier post http://talk.maemo.org/showpost.php?p...5&postcount=65

In addition to libpostal-based geocoding, the server is compiled with the newer libosmscout version that addresses few drawing issues, to name the few changes. Also, Swedish and Spanish translations have been updated.

This release should be considered as a "technology preview" with the distribution of the required databases and simplification of selections planned to be addressed in future.

The new search functionality is disabled by default. To enable, you would first need to get few databases in addition to the regular libosmscout map databases. For distribution, I am using mega.nz for now:

http://tiny.cc/geocodernlpdata

I may have to update the corresponding link on mega from time to time, to get decryption in sync.

The required databases are listed below with the file location at the distributed folder:

* libpostal language parser: postal/postal-global.tar.bz2

* libpostal country-specific database: postal/countries/<SELECT THE NEEDED ONES>

* geocoder database: geocoder/<SELECT THE NEEDED ONES>

Country-specific databases are generated in accordance with http://download.geofabrik.de/ distribution. Exceptions were:

* Russia was added as a part of Europe;
* Kosovo is missing since I could not find any records from this country in libpostal training set.

Some countries are joined with the others. For example, Ireland and Northern Ireland are joined. In this exceptional case, I had to join Ireland and UK records to provide libpostal country-specific database.

All the archives (tar.bz2 or .bz2) have to be extracted before use. I suggest to download them to PC, extract and then move to the device.

As soon as you have all databases on device, enable new geocoder by

* Go to menu Geocoder

* Select "Use geocoder-nlp"

* Select location of libpostal language parser (extracted postal-global.tar.bz2)

* Select libpostal country-specific database (extracted postal/countries/AA.tar.bz2, for example)

* Select geocoder database (for example AAland.sqlite)

* Select the languages that you want to use for parsing. Don't leave "All languages selected", that may lead to too large memory requirements! At present, select languages used in OSM map for that region.

* Accept new settings and enjoy

Searches (while using search in Poor Maps) and routing-related searches would run then via new geocoder.

As every intelligence, AI of libpostal does make mistakes. To help you out in these cases, the server logs how was the search partitioned (house number, street, ...). As an additional parser, I added a primitive parser that constructs hierarchy by taking your input and splitting it into parts assuming that parts are split by comma. So, in these cases, use the following notation "house number, street, city, ..." (i.e. move from inner to outer admin region). To use primitive parser, enable it in Geocoder options. Primitive parser shows hierarchy with h-number ids in logs.

For map application developers: I have introduced a new version of search results available via v2, see https://github.com/rinigus/osmscout-...arch-version-2 . In addition to search results, it adds information on how the search string was parsed. As far as I have seen, something similar is expected or already done by Mapzen to give the feedback on libpostal parsing.

I have just released a new update: 0.6.1

This is a work of the translators who updated the Swedish and Spanish translations - thank you @carmenfdezb and @eson57!

Please note that this version uses exactly the same libosmscout library as 0.6.0. Due to the changes in libosmscout, there is a bug that can cause server crash when you use older maps with the border style (https://github.com/rinigus/osmscout-server/issues/61). @Karry has found the cause and its fixed upstream. However, since it would require generation of new maps, I decided that such rather rare case (use of borders style) does not require the update of underlying library. This update is planned for future major release.

Together with others, I have been working on improving import into libosmscout databases. We are testing one patch right now that should make location hierarchies more accurate on imports. As soon as its ready, I am planning to regenerate geocoder-nlp world databases (sqlite).

I am curious if anyone has tried geocoder-nlp/libpostal search functionality in 0.6.x? If you did, how where the results? So far there has been no feedback on this.

I did a quick test with the new libpostal/geocoder stuff, here are my thougts so far:


Search results are a lot more usefull, putting in <Street> <Number>, <ZIP-Code> <City> gives the correct result almost 100% of the time, without libpostal it often would find anything but the Address that was searched for

Time for an address search seems to depend a lot on the "comonness" of the street name:
- searching for an address with "Parkstraße", which is a very common street name in Germany, takes several Minutes to complete, even when full ZIP-Code and City is given
- In contrast a search with an unique (or uncommon) street name yields a result in under 5 seconds.
I don't know how the search code works, but it seems to me it searches for the Street Name first, maybe it would be more efficient to first search City / ZIP-Code and then the Street (just a wild guess, I have not looked at the code so far)

Since I just played around with the new functionality a bit, thats it for my first impressions. All tests where done on a JollaC with all the data on the SD-Card

Thank you very much for the profiling and an example!

I will use your case for optimization of the search. It does search first for the city (or county) and then moves over to within searches, but I should probably change SQL query slightly to apply these refinements earlier. I should be able to make it faster

Unfortunately, ZIP codes are not used in the search. So, there is no point in entering them. I don't know yet how to apply ZIP codes and it has been rather low priority for now. I may look into it a bit later (or anyone interested can look into implementing zip code searches as well).

Thanks again, its quite helpful to get your feedback!

@rinigus
access to http://tiny.cc is blocked in Russia :-(

@seiichiro0185, I made a new SQLite database that should speedup the searches. On OPX, the search time for Parkstraße 5 frankfurt dropped from 20+s to 1-2s. There is an additional index in the database for that which made it bigger. I will look into how to reduce the size of it.

Please test whether it works for you. Using the same server code, just get the new database from "testing/europe" subfolder in mega.nz share.

@XOleg, that's really strange. Current link is
https://mega.nz/#F!8EsxXRTT!arad2NJ9rEhpXXn-YXsF8w , but maybe mega.nz is blocked as well. I will work on database distribution soon and maybe we can find servers that are possible to connect to from Russia. Although, I cannot really check it out from here.