Opened 11 years ago

Last modified 9 years ago

#904 new enhancement/feature request

Improve address search to improve intuitivity

Reported by: ham73tux Owned by: KaZeR
Priority: major Milestone: version 0.6.0
Component: core Version: git master
Severity: Keywords: address search


This ticket describes suggestions for an improved address search. Currently it is easy to get frustrated with the search, if you don't follow a very specific procedure (which you can't always guess right).

Addresses currently can be searched in two ways: 1) by selecting Actions and then Towns, 2) by entering a free text address after selecting "Address Search" in the menu.

This ticket addresses both methods and suggests some improvement. The ticket origins from California, US.

A typical address in the United States would look like this:

1600 Pennsylvania Ave NW
Washington, DC 20500

(Address of the White House, by the way.)

This address contains:

  • a house number
  • a street name, potentially containing some abbreviations
  • a city name
  • a state name (abbreviated)
  • a country name

That list applies most likely to any address on our planet, but the order of things differ significantly. This may be the reason why it is a bit harder to find an address in the US.

Case 1: searching an address by opening Actions and then selecting Towns

To make things easier for the user, the following things should be changed.

1) (major) If the search results in a partial recognition, display possible selections below entry field. This happens already. If the selections are ambiguous (e.g. same city name listed more than once), add information which allows the user to recognize the correct selection. Example: search for "Fremont" in the US: you will be presented with half a dozen cities from all over the US. If you select the wrong one, you never will find the street you are looking for. So "(county, state)" should be added to the city name - in our example "Fremont (Alameda, CA)" instead of just "Fremont". (Remark: Currently, if you type in the word "Fremont" completely *without* selecting from the list, you will be able to find the street you are looking for.)

2) (minor) change onscreen keyboard to resemble a real QWERTY, QWERTZ etc. keyboard. User should be able to select preference. For the beginning, use QWERTY (US English keyboard layout) and offer umlauts etc. in extra menu (to be opened using special key) or the way Apple devices do (pressing a vowel key for a half second, then select umlauts presented).

3) (minor) The font for the keys appears very small on devices with larger resolutions such as a 7 inch Archos 70 screen.

4) (minor) The "Towns" icon should be renamed to "Address", to make it a bit more intuitive.

Case 2: searching an address using the menu item "Address search" (freetext).

This feature is not mature and results in erroreous results most of the time. The author of this ticket suggests to

  • either eliminate this method entirely and replace it with the same entry method provided by the way described in Case 1,
  • or to split the free text entry into fields for country, state (if locally applicable), city, street and number. ZIP code optional.

The author would prefer the first option; it would allow the developers to concentrate on one item. Freetext offers too much room for errors.

-- end of ticket.

Attachments (1)

only_county_fix.diff (921 bytes) - added by jwernerny 11 years ago.
Patch to maptool to carry US county information from OSM to binfile

Download all attachments as: .zip

Change History (10)

comment:1 Changed 11 years ago by jwernerny

I was going to suggest the same feature as Case 1 for the same reasons.

This issue does not limit itself just to a few towns in the US. It also occurs in other countries. (A search for "Taufkirchen" in Germany is one of my favorites because of an interesting drive through the German countryside following the instructions from the rental car's GPS to someplace I had never been before that was not anywhere near where my hotel was.)

[As an aside, it looks like this might be fairly easy to add in gui_internal.c, but there isn't really enough documentation in the code for me to figure out how the code for searching and displaying results works, let alone figuring out what needs to be changed.]

comment:2 Changed 11 years ago by jwernerny

I did some more looking through the code. Navit's internal GUI will correctly display additional information for a town (e.g. county, postalcode) when displaying the results search if that information is available from the map file.

The root cause seems to be that maptool is not putting any of the additional information in the binfile map if the data comes from OSM and is for the US.

I have created a small patch to navit/maptool/osm.c that extracts the "gnis:County" extra data for a town that is found in most US OSM data. If the OSM data is converted with the patched map tool, searches for US towns show results with both the town name and county.

(example from dummy test data searching for "Fairport" in the US)

  • Fairport, Co. Monroe
  • Fairport, Co. Orange
  • Fairport, Co. Bleaver

While this is not an ideal solution, it is certainly a great improvement. [Ideally, the state would also be displayed as most places in the US are known by "Town, State," not "Town, County." I have been unsuccessful in getting the State info to display.]

The nicest thing I have found about this change is I only have to rebuild the map binfile with a modified maptool (running on my Linux or Windows PC). I don't have to rebuild the main Navit application for my n810!

The patch in in the attached "only_county_fix.diff" file.

Changed 11 years ago by jwernerny

Patch to maptool to carry US county information from OSM to binfile

comment:3 Changed 10 years ago by

jwernerny: do you happen to have a compiled windows version of your maptool you could attach here or email me?

comment:4 Changed 10 years ago by mvglasow (2)

As for Case 1 (disambiguation): it is definitely important to have some way to tell entries apart.

"Town, State" should work for most places in the US (though I'd assume there may be cases of two or more towns with the same name in the same state as well), but outside the US, things may differ.

ZIP/postal codes may also work, being designed for that kind of disambiguation, but users will not necessarily know the postal code of their destination.

I therefore suggest making disambiguation somewhat more "dynamic":

  • Include ZIP/postal codes, if possible
  • Include all areas encircled within a higher "admin_level" border (county, province, state, country)
  • Eliminate repetitions (Milano, Lombardia instead of Milano, Milano, Lombardia) - to prevent wasting pretious screen real estate on mobile devices
  • Eliminate fields which do not help with disambiguation - e.g. if all towns returned are in the same state but different counties, we need only the counties, again to save screen real estate
  • Possibly also include the distance from the current location (if you are driving to a nearby town, you will know that a place several hundreds of km away is not the one you wanted)

Also this is not only an issue with town search but also with street search. There are cases of double street names in the same town (probably resulting from longer streets being cut in two). Via Triboniano in Milan and Ozo gatvė in Vilnius are two that come to mind.

For streets, disambiguation candidates could be:

  • Parts of town (indicated by place=* tags)
  • ZIP/postal codes (again, these may not always be meaningful to the user)
  • House number ranges, where available
  • Distance from current location

comment:5 Changed 9 years ago by usul

  • Milestone changed from To be discussed - Give your opinion! to version 0.6.0

comment:6 Changed 9 years ago by ham73tux

(navit-svn 0.5.0 build 5549 + fresh set of US maps on an Android Archos 70)

Great job! The "Towns" feature now does exactly what I'd expect from a navigation device. It does now let me pick the right town out of a selection by listing the state and the county it is in. Wonderful! Case 1 is closed.

Unfortunately the menu item "Address search" still doesn't work at all. The last time I entered my home address it searched for more than one hour (really!) and then didn't find anything. So that needs either improvement or removal. Case 2 therefore remains open.

Keep up the good work! Bernhard, "ham73tux" Fremont, California, U.S.A.

comment:7 Changed 9 years ago by tryagain

Case 2 seems to work well for me. It might take too much resources as it will search every matching city for given street mask, but it works.

You may enter street name city or city streetname or separate address parts with comma.

Remember to activate partial match if needed.

comment:8 Changed 9 years ago by ham73tux

(2nd post, the first version one somehow evaporated at submit. Had to rewrite it - no fun.)

I did some experiments using the Case 2 feature this morning, both with and without the "Partial Search" flag set.

Searching for a city ("fremont") results in an almost immediate list of matches, including the one I was searching for (Fremont, Alameda County).

  • Partial search for "47131 bayside parkway, fremont" quickly resulted in a list of more or less matching records, including the address I was searching for.
  • A second identical search took about 5 minutes (way too long), apparently some resources needed for the search now had been unavailable. But the search yielded the correct address amonst a list of other hits.
  • Full search for "47131 bayside parkway, fremont" resulted in a list of 17 matching records, including the address I was searching for. However that search again took about 5 minutes. Way too long. - The list of results contained several "Fremont" and many "Parkway" hits in my city (Auto Mall Parkway, Landing Parkway, Paseo Padre Parkway etc.).
  • Partial search for "40152 mueller court, fremont" started a firework of search, but locked up after about 10 seconds. I left it going. Every few minutes there was some more search action, but mostly it just sat there. Sfter about 20+ minutes, there was a list of hits (a lot of "Court" hits, it appears) - but Navit still hang, no input possible. I had to force quit it. This behavior is reproducable.

There's definitely a resource issue. My device is an Archos 70 tablet, about three years old, running Android 2.2.1 (ok, that's a bit dusty). Available memory at time of search start was about 100 MBytes.

Part of the problem could be that the search is based on an "OR" logic. Many results don't have all keywords in them, e.g. "Parkway", but not "Bayside". "AND" logic should result in much better and also fewer matches.

So my verdict remains: Case 2 needs some polish. I'm willing to bet that other folks have similar problems.

Viele Grüße! Bernhard in Fremont, California

comment:9 Changed 9 years ago by tryagain

Yes, that's what I was talking about. Currently navit attempts to accept any ordering of search terms and does not require to use delimiters. If it hits a big town, it attempts to scan it for matching streets.

As we have no street indexes yet, it requires too much cpu and, maybe, disk throughput.

I think it was a nice idea to implement such intuitive search feature, but to make it always usable we probably have to limit its fuzziness. Step-by-step approach implemented in gui_internal is much faster as it requires user to select a city before letting to continue with the street query.

So I suggest:

  • make address part separators required
  • make address parts ordering configuable (we can probably guess it from locale, but user should be able to verify and change our choice)
  • let user choose if given matching upper level item (town) worth diving into it.


Note: See TracTickets for help on using tickets.