Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#1001 closed enhancement/feature request (fixed)

List of auto-complete towns should be scrollable

Reported by: me.yahoo.com/a/t8pxanggmzrce9fscf2wgwk_ozmtbyifgarr#f3b4e Owned by: KaZeR
Priority: major Milestone:
Component: gui/internal Version: git master
Severity: Keywords: town
Cc:

Description

  • Navit version: navit-svn-4879
  • Device: Samsung Galaxy Tab P1000
  • OS: Android 2.2
  • latest map from planet extractor

Go to Menu -> Actions -> Town and select a country.

After start typing some letters in city name field, Navit will try to build an auto-complete list. The problem is that this is not scrollable. Currently, the user is only able to select one of the first items in this list. User is not able to see the rest of the list, but only the first items that fit the screen. User should be able to scroll through this list, and select any of them.

Ciprian Alexan.

Change History (12)

comment:1 Changed 7 years ago by korrosa

Note that this is similar to #352.

comment:2 follow-up: Changed 7 years ago by efessel

How about sorting the list by distance (maybe show distance next to each item), since when I type Cheshire, I get 5 results all over the country with the one I want (the closest) the third item in the list.

comment:3 in reply to: ↑ 2 ; follow-up: Changed 7 years ago by me.yahoo.com/a/t8pxanggmzrce9fscf2wgwk_ozmtbyifgarr#f3b4e

Replying to efessel:

How about sorting the list by distance (maybe show distance next to each item), since when I type Cheshire, I get 5 results all over the country with the one I want (the closest) the third item in the list.

I don't think that this is a good idea. Sorting the list by distance would make finding a town almost impossible. Complete list may need to be reviewed in order to find an entry. Alphabetical ordering is the best way to compose a list when searching is done by name.

comment:4 in reply to: ↑ 3 Changed 7 years ago by efessel

Replying to https://me.yahoo.com/a/t8pxanggmzrce9fscf2wgwk_ozmtbyifgarr#f3b4e:

Replying to efessel:

How about sorting the list by distance (maybe show distance next to each item), since when I type Cheshire, I get 5 results all over the country with the one I want (the closest) the third item in the list.

I don't think that this is a good idea. Sorting the list by distance would make finding a town almost impossible. Complete list may need to be reviewed in order to find an entry. Alphabetical ordering is the best way to compose a list when searching is done by name.

Sorting by alpha is fine. If there are 5 results for the same town, it would be nice of those 5 were sorted by distance.

comment:5 follow-up: Changed 7 years ago by tryagain

Sorting list built on the fly seems to be not a very good idea. Think what should happen if you scroll to the second page of the list and after that a new item is added to the first page.

Currently, search result lists are unsorted (besides housenumbers list) On the housenumbers list following logic is used for partial sorting:

  • housenumbers without streetname are placed at the bottom of the list;
  • housenumbers exactly matched to the expression entered are going to the top.

I can implement something like that for every search results list we have. Or do alphabetic/distance ordering, if you like it more. Vote, please.

As for scrolling, for the first time I'd add paging feature as it's done in other places of the interface. Later, if we do real scrolling, it should automagically become available through all the interface.

comment:6 in reply to: ↑ 5 Changed 7 years ago by efessel

Replying to http://wiki.navit-project.org/index.php/user:tryagain:

Sorting list built on the fly seems to be not a very good idea. Think what should happen if you scroll to the second page of the list and after that a new item is added to the first page.

Wouldn't sorting occur right after data mining, not while displaying the list?

-Search map for addresses-> returns 40 results. -Sort the 40 results by alpha/distance, send the first 10 to the display -After scroll, send next 10 to display

I'm just trying to solve this problem of "I search for the town of cheshire, I get 5 results for cheshire back, the closest one being the third result in list"

If i'm hijacking this ticket (sorry), and this has merit, i'll create a new one..

Currently, search result lists are unsorted (besides housenumbers list) On the housenumbers list following logic is used for partial sorting:

  • housenumbers without streetname are placed at the bottom of the list;
  • housenumbers exactly matched to the expression entered are going to the top.

I can implement something like that for every search results list we have. Or do alphabetic/distance ordering, if you like it more. Vote, please.

As for scrolling, for the first time I'd add paging feature as it's done in other places of the interface. Later, if we do real scrolling, it should automagically become available through all the interface.

comment:7 Changed 7 years ago by tryagain

Data mining is done on the fly. So we update list on the screen after each result is found on the map.

And results are coming in some quite random order.

You may note that results on the first page are not added all at once.

Going to commit the paging feature soon.

comment:8 Changed 7 years ago by tryagain

Committed it in http://navit.svn.sourceforge.net/viewvc/navit?view=revision&revision=4901

Not closing right now as I want some feedback on results ordering.

I think "alphabetic, then distance" ordering would really be a nice feature.

comment:9 follow-up: Changed 7 years ago by tryagain

  • Component changed from core to gui/internal
  • Resolution set to fixed
  • Status changed from new to closed

Well. Ordering results by distance seems to be questionable for me. Suppose we have four towns named Equivalent in some country.

Suppose we have all these towns listed in the results list ordered alphabetically and by distance.

So we go to the first (nearest) town of them to look the map around and see if it's the town we are looking for.

Suppose it's not. Then we go to the second town in the list. And it will appear not the town we're going to visit.

Next step would be to examine the third town. But the list ordering is changed (because we changed our position). So there's no chance to guess where the first town we looked at is placed. So we can by mistake open the first analyzed town again.

Behavior described above seems to be inconsistent and annoying. We could display some additional info to distinguish them, but it's not always available in OSM data. Displaying OSM IDs or geographical coordinates will look ugly.

So I have no idea where to go further besides adding alphabetical ordering of search results.

As alphabetical ordering is added in http://navit.svn.sourceforge.net/viewvc/navit?view=revision&revision=4911 , I feel this ticket to be closed.

Last edited 7 years ago by tryagain (previous) (diff)

comment:10 in reply to: ↑ 9 Changed 7 years ago by efessel

Replying to http://wiki.navit-project.org/index.php/user:tryagain:

Well. Ordering results by distance seems to be questionable for me. Suppose we have four towns named Equivalent in some country.

Suppose we have all these towns listed in the results list ordered alphabetically and by distance.

So we go to the first (nearest) town of them to look the map around and see if it's the town we are looking for.

Suppose it's not. Then we go to the second town in the list. And it will appear not the town we're going to visit.

Next step would be to examine the third town. But the list ordering is changed (because we changed our position). So there's no chance to guess where the first town we looked at is placed. So we can by mistake open the first analyzed town again.

You're right this could happen, but I'm pretty sure this would be very rare. Someone would have to be the same distance away from both towns (I believe this would be rare in itself), and be searching while moving for it to happen.

I know flags are displayed next to each result, how about the state or province (or zipcode?) for US/Canada?

comment:11 Changed 7 years ago by tryagain

I think we have solved the problem stated in the ticket description.

As for distance ordering. I thought it should be distance from the center of the map displayed onscreen, not from the standing point. If we count distance from standing point (as per GPS data) the list will be more consistent, sure. But what to do if we have no GPS position fixed yet? And will it be intutive to have distances measured not from the map center. There are too many questions so it's better to be discussed in a separate ticket.

Zipcode seems to be already displayed by gui_internal code if it's available in the map data. And it went out of the scope of this ticket. So I'd suggest opening another ticket with full details of your situation, referring some OSM items (towns) which have zipcode set but not displayed in the search results. Probably we have some maptool issues or even wrong OSM data rather than gui_internal issues.

comment:12 Changed 7 years ago by me.yahoo.com/a/t8pxanggmzrce9fscf2wgwk_ozmtbyifgarr#f3b4e

I can confirm that this feature was implemented. Verified on SVN version 4911

Going further, I have some more improvement suggestions about scrolling this list:

  • display page number between Prev and Next button
  • Prev button is grayed-out when first page is displayed
  • Next button is grayed-out when last page is displayed

Thanks, Ciprian Alexan.

Note: See TracTickets for help on using tickets.