Notices


Reply
Thread Tools
Posts: 226 | Thanked: 1,045 times | Joined on Dec 2014 @ Earth
#221
Originally Posted by rinigus View Post
In your case, they both match since Zgierz is within Lodzkie which is matching Lodz via substring match.
Would it be possible to order the search by the reverse size of the match.

i.e.: sort entry that match "Lodz" to a city, before those that match a region, before those that match a whole country.

Or match by the the shortness of the interval if you only do full-string matches ? (One is matching "(Antoniewska), (Lodz), Lodzkie" with only ", " between the groups, the other is matching "(Antoniewska), Grietz, (Lodz)kie" with ", Grietz, " in between the groups)


And by the way, nothing to do with the above, I like the "highway sign" display during navigation.
 

The Following 4 Users Say Thank You to DrYak For This Useful Post:
Posts: 626 | Thanked: 3,242 times | Joined on Aug 2016 @ Estonia
#222
Originally Posted by DrYak View Post
Would it be possible to order the search by the reverse size of the match.

i.e.: sort entry that match "Lodz" to a city, before those that match a region, before those that match a whole country.

Or match by the the shortness of the interval if you only do full-string matches ? (One is matching "(Antoniewska), (Lodz), Lodzkie" with only ", " between the groups, the other is matching "(Antoniewska), Grietz, (Lodz)kie" with ", Grietz, " in between the groups)


And by the way, nothing to do with the above, I like the "highway sign" display during navigation.
If I promote city over region, we'll get also pub over city. So, this will lead to the hits to the pubs called Lodz in some small villages over Poland.

Matches are done via search in hierarchy, not as a search in strings.

So, would have to be careful in changing it.
 

The Following 5 Users Say Thank You to rinigus For This Useful Post:
pichlo's Avatar
Posts: 5,530 | Thanked: 17,206 times | Joined on Sep 2012 @ UK
#223
I am still convinced that the best solution would be a nested search, like I suggested a number of times.
Country, region, town, street, house number, in that order, with separate entry fields, without an option to even start entering the next field before the previous one is fully populated.

No need to parse the address, instant search would apply at that hierarchy level only. So typing "Edin" when a town is expected would only yield "Edinburgh" but not the "Duke of Edinburgh" pub; typing "Oxf" when a street is expected would yield "Oxford Street" in the selected town (also "Oxford Circus" if the town is London ), but not hundreds of other "Oxford Street"s in other towns and definitely not Oxford the city...

DrYak's Lodz problem would automatically resolve itself at the "entering the town name" level, since you would have a small list to choose from.
__________________
In particle accelerators atoms are indeed not only touching each others. But banging together in a massive explosive orgasm.
-- nieldk in a TMO post
 

The Following 7 Users Say Thank You to pichlo For This Useful Post:
Posts: 626 | Thanked: 3,242 times | Joined on Aug 2016 @ Estonia
#224
Originally Posted by pichlo View Post
I am still convinced that the best solution would be a nested search, like I suggested a number of times.
Country, region, town, street, house number, in that order, with separate entry fields, without an option to even start entering the next field before the previous one is fully populated.

No need to parse the address, instant search would apply at that hierarchy level only. So typing "Edin" when a town is expected would only yield "Edinburgh" but not the "Duke of Edinburgh" pub; typing "Oxf" when a street is expected would yield "Oxford Street" in the selected town (also "Oxford Circus" if the town is London ), but not hundreds of other "Oxford Street"s in other towns and definitely not Oxford the city...

DrYak's Lodz problem would automatically resolve itself at the "entering the town name" level, since you would have a small list to choose from.
Indeed, this way we can resolve such ambiguity in the address. I should take it in my plans. There is a lot of work to make it possible.

On Pure Maps side, things will be relatively simple, but still some effort is needed. GUI would have to be redesigned and adjusted for such address entry. Would be great to know whether there are online services providing such way of search (where you do specify city and such).

On Geocoder-NLP side things will be way more complicated. I will have to figure out which OSM admin levels correspond to which in such form (https://wiki.openstreetmap.org/wiki/...administrative) or geocode using WOF (https://www.whosonfirst.org/). Right now we just have one layer below another, without specific meaning of it. If we also want to be able to write with the errors / skipping accents then there are more steps to be done on the top as well.

So, in short, that's not coming over tomorrow. Nor in very near future - but probably should be planned.
 

The Following 6 Users Say Thank You to rinigus For This Useful Post:
Posts: 626 | Thanked: 3,242 times | Joined on Aug 2016 @ Estonia
#225
New release is out: 1.6.0

This is a release which does not bring any new features, its a major rework on internals. In particular, I have changed the way the page stack was implemented. In addition, I reduced the number of python calls from QML by caching configuration on QML side.

The introduced changes were all over the code and, while testing has been done, its possible that I missed something. So, if you hit a bug, please file the issue or report here. I will do my best to fix all ASAP.

In addition, many translations have been updated. We are still missing translators for few languages though: FI SL HU.

In this version, I added fonts resource for the raster maps which will fix POIs not showing up when starting with these maps (HERE, HSL, OpenCycleMap, Sputnik, Thunderforest Transport).

BTW, looks like MapQuest is back for us. So, its users can start using this service again.

Now, after the version is described, there are few more subjects for discussion.

Mapbox GL QML plugin

When working with @pichlo, I have hit few times the case where Pure Maps was hanging on my device. I managed to get backtrace and it pointed to OpenSSL functions. Then I made a version of Mapbox GL plugin which added few locking functions for OpenSSL. For @pichlo, this made startup slower and did not fix bug that he was hitting. For me, though, when running SSL-locks enabled Mapbox GL resulted in not getting any hangs on Pure Maps for a week. [which doesn't prove much since the events were rare anyway]. However, if you do experience that Pure Maps fails to stop (can be observed by the issues with the start of Pure Maps later and through examining output of ps), I would suggest to try Mapbox GL QML plugin with SSL locks:

http://repo.merproject.org/obs/home:...la.armv7hl.rpm

(for i486 see the corresponding repo).

Please report your experience if you start using it. @pichlo, you may want to try again since I changed the startup sequence of Pure Maps and maybe it will not be as slow as when you tried before.

Mapbox access

Our counts for Mapbox tile downloads are so far OK, will be somewhere around 30-40K tiles per month. Which is relatively close to the border of the free tier - 50K. According to the current conditions, If we do hit over 50K, I'll have to pay for extras or get account suspended. I have contacted Mapbox and had a discussion on different ways to resolve it. Since they cannot limit me to 50K, as a solution, Mapbox suggested to ask users to register on their site and get their own access code. This is a solution that they consider as compliant with their conditions for open source projects.

In practice, I will monitor the situation and will introduce a simplish way to enter the access code in the future versions. Current code initialization is done with such extension in mind. While a bit of a pain for users, it will allow us to use the very high quality tiles (styling and updates) that they provide for free and without any cost. It will also scale with the user base.
 

The Following 2 Users Say Thank You to rinigus For This Useful Post:
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 10:19.