Opened 9 years ago

Closed 7 years ago

Last modified 7 years ago

#859 closed enhancement/feature request (fixed)

Search for POI by name

Reported by: aaaapublic Owned by: cp15
Priority: major Milestone: version 0.6.0
Component: core Version: git master
Severity: Keywords: POI search name
Cc:

Description

I've been trying Navit for Android 0.5.0 4281 for the past few days, using maps downloaded directly by Navit or from Navit Planet Extractor. Most things work fine, but the search feature has me quite frustrated.

Imagine me as a tourist to a unfamiliar country and relying on Navit to find POIs (and subsequently route to it). To require me to search for a place or street by Country->Town->Street is not practical since it would need me to have fairly intimate knowledge of the region. As a tourist, I would not have such information of a new place.

To ask that I add is_in tags is also not practical, since the POI search would not be functional till I get a newly created map a few days later. And this is also beyond the capability of the average non-technical user.

But what I do know is the name of the POI. For example, if I'm looking for the Sydney Opera House, I would not know which suburb or street it is in ( most tourists don't ). The only thing I have to go on is the name of the POI.

So I want to request for a feature that allows a search by NAME of the POI, perhaps a substring search. The search should start from the location where I am, then list the results by distance. The distance of search should increase incrementally each time I click on a "More results" button. This is how commercial GPS devices work ( eg, Garmin ). It's effective, user friendly, and always finds the results since everyone knows the names of places they want to visit.

My email is aaaapublic@… if any clarifications are needed.

Attachments (13)

poi_filter.diff (10.6 KB) - added by tryagain 9 years ago.
Try this patch for gui_internal. There's a new lamp button added to POI dialog. By pressing it you can search POI by its type name (as defined in item_def.h) and by the name attached to the POI (if any). Everithing on the map is considered a POI so you can find not just points but also lines and polygons - streets, parkings marked as polygons etc. For now I don't care and use first point of polygon found to calculate distance to it.
poi_filter_with_address_search.diff (26.9 KB) - added by tryagain 9 years ago.
It chages maptool so pathced Navit will be most usable when used with a map made with patched maptool. Older versions of navit may crash in housenumber search when used with patched map. POI filtering is working as before but also a bunch of POIs became availiable for regular POI search. POI items mapped as polygons are recognized for POI search now. Buildings mapped as polygons are included into address search. Note: http://trac.navit-project.org/ticket/794 is NOT resolved by this patch.
poi_filter_with_address_search2.diff (28.2 KB) - added by tryagain 9 years ago.
Didn't thought it would be that easy. Address search is added to POI search. Put your finger on the city, go to POI filter, enter address (sub)strings and press letter button. Do not use too much address info (city name, country name), it will be availiable for search only if tagged in OSM _and_ got imported into Navit binary map. Search exaample for Bristol, GB: "6 warw roa".
poi_filter_with_address_search3.diff (29.3 KB) - added by tryagain 9 years ago.
Support for support/glib added (for now, fake function added). Fixed garbage in editor when you press Enter in POI filter dialog. Sorry, didn't yet found way to fire default action on Enter press.
poi_filter_with_address_search3.2.diff (29.3 KB) - added by tryagain 9 years ago.
Fixes error in fake function.
poi_filter_with_address_search4.diff (31.7 KB) - added by tryagain.myopenid.com 9 years ago.
Fixes filter string corruption when "get more items" button is pressed. Removes from search list duplicate info given by poly_building and house_number items.
gui_search.svg (58.0 KB) - added by number6 9 years ago.
Suggested icon (magnifying glass) for search, instead of lightbulb
maptool-way2poi2.diff (26.8 KB) - added by tryagain 9 years ago.
POI icons (and housenumbers) are placed on polygone area centroids (mass center). Cases when lines are being used instead of polygones and when centroid is outside of poly are not taken care yet.
maptool-way2poi3.diff (32.4 KB) - added by tryagain 9 years ago.
Suggestions from http://irclogs.navit.ie/%23navit-2011-07-03.log and sigfpe crash when polygone area <1 should be fixed.
poi-inside.diff (3.0 KB) - added by tryagain 9 years ago.
Now POI icons and text labels are inside poly or on its border. Should I try moving them from the border sligtly inside polygon?
poi-inside.2.diff (3.2 KB) - added by tryagain 9 years ago.
updated
maptool-line-poly-2poi.diff (9.1 KB) - added by tryagain 9 years ago.
poi_filter_unicode.diff (993 bytes) - added by tryagain 9 years ago.
Improved algorithm to use case- and accent- insensetive strings comparison. Unfortunately, it won't currently give any change for WinCE and any other platform using built-in copy of glib.

Download all attachments as: .zip

Change History (36)

comment:1 Changed 9 years ago by aaaapublic

Noticed my email provider part of my email address got stripped off. It's gmail.

comment:2 Changed 9 years ago by aaaapublic

Actually, I've been thinking that the current POI feature (Main Menu->Action->World->POIs) could fulfill this if it allowed filtering by name substring and distance instead of only by category icons.

In fact, this will solve 2 problems :

  1. It will allow me to find my POI by name, and
  2. It will also allow me to find my POIs by categories that are not currently in the category icon list. Eg, I could search for "bus_stop" and it will list all nearby bus stops without needing a bus stop icon ( which is currently missing ).

comment:3 Changed 9 years ago by tryagain

I'm working on a patch for POI filtering. I think that for object NAME I will use several attributes merged together. First will be object type, second its name. So if you have a bus stop named "Academy" you will be able to find it by type, by name or both.

Do you have any idea on what other OSM attributes should be used to form object NAME?

comment:4 Changed 9 years ago by aaaapublic

Awesome ! The filtering patch would be great ! My Garmin GPS allows searches by POI name, type, address, cities, intersections and recently found. But I use search by POI name and type exclusively, so I think these 2 should be enough.

Changed 9 years ago by tryagain

Try this patch for gui_internal. There's a new lamp button added to POI dialog. By pressing it you can search POI by its type name (as defined in item_def.h) and by the name attached to the POI (if any). Everithing on the map is considered a POI so you can find not just points but also lines and polygons - streets, parkings marked as polygons etc. For now I don't care and use first point of polygon found to calculate distance to it.

Changed 9 years ago by tryagain

It chages maptool so pathced Navit will be most usable when used with a map made with patched maptool. Older versions of navit may crash in housenumber search when used with patched map. POI filtering is working as before but also a bunch of POIs became availiable for regular POI search. POI items mapped as polygons are recognized for POI search now. Buildings mapped as polygons are included into address search. Note: http://trac.navit-project.org/ticket/794 is NOT resolved by this patch.

Changed 9 years ago by tryagain

Didn't thought it would be that easy. Address search is added to POI search. Put your finger on the city, go to POI filter, enter address (sub)strings and press letter button. Do not use too much address info (city name, country name), it will be availiable for search only if tagged in OSM _and_ got imported into Navit binary map. Search exaample for Bristol, GB: "6 warw roa".

comment:5 follow-up: Changed 9 years ago by aaaapublic

thanks. The description of the enhancement sounds great, but I'm not able to test it. I downloaded version navit-svn-4530.apk but it does not seem to have the fixes you added in. I'm eager to try it as I have a trip coming up on Friday and I'll like to use this POI search feature.

comment:6 in reply to: ↑ 5 Changed 9 years ago by tryagain

Replying to aaaapublic: Enhancement will be in production only after testing by Navit team. Now you can test it only if you have building environment for your platform. When the patch will be merged into svn, a note will be put here.

Changed 9 years ago by tryagain

Support for support/glib added (for now, fake function added). Fixed garbage in editor when you press Enter in POI filter dialog. Sorry, didn't yet found way to fire default action on Enter press.

Changed 9 years ago by tryagain

Fixes error in fake function.

Changed 9 years ago by tryagain.myopenid.com

Fixes filter string corruption when "get more items" button is pressed. Removes from search list duplicate info given by poly_building and house_number items.

Changed 9 years ago by number6

Suggested icon (magnifying glass) for search, instead of lightbulb

comment:7 Changed 9 years ago by cp15

Applied in svn4564+svn4565 with exception of the maptool change. That needs a rework so points are added as actual points to the map

comment:8 Changed 9 years ago by cp15

  • Resolution set to fixed
  • Status changed from new to closed

Changed 9 years ago by tryagain

POI icons (and housenumbers) are placed on polygone area centroids (mass center). Cases when lines are being used instead of polygones and when centroid is outside of poly are not taken care yet.

comment:9 Changed 9 years ago by tryagain

  • Resolution fixed deleted
  • Status changed from closed to reopened

Changed 9 years ago by tryagain

Suggestions from http://irclogs.navit.ie/%23navit-2011-07-03.log and sigfpe crash when polygone area <1 should be fixed.

Changed 9 years ago by tryagain

Now POI icons and text labels are inside poly or on its border. Should I try moving them from the border sligtly inside polygon?

Changed 9 years ago by tryagain

updated

Changed 9 years ago by tryagain

comment:12 follow-up: Changed 9 years ago by aaaapublic

At last, the build is available on SVN and I eagerly downloaded it and gave it a spin. Wow, what a difference this makes in the usability of Navit. I can now search for POIs easily and quickly. Thanks !!!

A small suggestion would be to increase the search distance to a distance that is, say, 150% (or any suitable factor) of the current search distance ( rounded up to the nearest 10km). Eg, if the current search distance is 30, the next distance would be 50km ( ie, 30*1.5 = 45, rounded up to 50). The next search distance would therefore be 80km, etc.

This would allow progressively more expansive search. I think this would be reasonable, since if I'm repeatedly hitting the "set search distance to xx km" option, it probably means the POI I'm looking for is far away.

It is not unreasonable for a traveller to search for a POI in the next town or city, which could be a few hundred km away. For example, when I was in Melbourne, I needed to search for Mornington and Philip Island, which was about 1-2 hours drive away. Increasing the search just 10km at a time is too tedious.

An alternative is to allow different increments ( 10km, 30km, 50km, 100km).

Nevertheless, great job on the search feature. I love it ! Thanks again !

comment:13 in reply to: ↑ 12 Changed 9 years ago by korrosa

Replying to aaaapublic:

[snip]

An alternative is to allow different increments ( 10km, 30km, 50km, 100km).

This sort of thing would also be my preferred option:

Set search to: X1 X2 X3 X4 X5 X6

Where:

X1 = current + 10
X2 = current + 20
X3 = current + 40
X3 = current + 60
X4 = current + 90
X5 = current + 120
X6 = current + 160

...or something like that?

Nevertheless, great job on the search feature. I love it ! Thanks again !

Absolutely!

comment:14 Changed 9 years ago by tryagain

I dislike idea making percentage increments. When you multiply search distance by 2 you'll get search area multiplication by 4. Processing time will be multiplied by 4 too, if number of POIs per square kilometer is constant on the search area. That can become quite annoying on low resource devices, especially if search area border will get into some big city.

I feel alternative idea with different increments to be more predictable and useable. Why press 20->30->50->80 when you know you want 100km search distance?

BTW if you want to search in another town why you do not find that town by Town Search at first and then do a local POI search?

And please don't abuse this feature: it's not designed to work with distances more than 1000km. I'm quite sure you will not note any errors even after that distance but I warned you ;)

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

comment:15 Changed 9 years ago by aaaapublic

I'm fine with either percentage increments or just the option of greater search distances.

The only reason why I don't search for towns first, is that Navit's( and OSM's) definition of "town" is not exactly the same as that of the average Joe. For example, if I'm looking for Sydney, I'll just search for Sydney. But try that in Navit and you'll come up empty. This was why I requested for the POI search feature in the first place.

Another reason is that some POIs ( eg, National Parks or landscape features ) are literally in the middle of nowhere, hundreds of miles away from the nearest town. The town search feature won't work then. The only way to find it is to go to the approximate area, and search in ever-increasing distance till it shows up.

Speaking as a regular user of GPSr units while walking around strange cities and driving on unfamiliar roads, I can definitely see myself searching for POIs for 100, 200, or even 400km away (which is what I do on my Garmin). But I doubt I'll be searching for POIs more than 1000km away. To me, the GPS should support distances that I can drive comfortably in a day, which differs from person to person. For me, it's about 600-700km.

With the search feature, Navit's usability is approaching that of commercial units. I've been mucking around with the navit.xml file and bookmark.txt files to make it even better. I've been using Navit in place of my Garmin, and it's certainly a viable replacement even at this point.

Last edited 9 years ago by aaaapublic (previous) (diff)

comment:16 Changed 9 years ago by korrosa

Feature added in http://navit.svn.sourceforge.net/navit/?rev=4626&view=rev

The search distances increment by 10, 50 and 100km.

i.e. Initially the search distance is set to 10km, so the next options are 20, 60 and 110km. If choosing 60km, the next options would be 70, 110 and 160km and so on.

Thanks tryagain!

comment:17 follow-up: Changed 9 years ago by aaaapublic

Navit for Android Build 4631 hangs when selecting any of the pre-defined POI filters. I had to kill it with a task manager. I switched to the previous build 4629 and it (predefined POI filters) is working fine.

comment:18 in reply to: ↑ 17 ; follow-up: Changed 9 years ago by korrosa

Replying to aaaapublic:

Navit for Android Build 4631 hangs when selecting any of the pre-defined POI filters. I had to kill it with a task manager. I switched to the previous build 4629 and it (predefined POI filters) is working fine.

Judging by the revision numbers provided, I'm gonna guess the problem is this: http://navit.svn.sourceforge.net/navit/?rev=4630&view=rev

Note: this issue has been reported by 2 independent users, both on Android.

Last edited 9 years ago by korrosa (previous) (diff)

comment:19 in reply to: ↑ 18 Changed 9 years ago by tryagain

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

Navit for Android Build 4631 hangs when selecting any of the pre-defined POI filters. I had to kill it with a task manager. I switched to the previous build 4629 and it (predefined POI filters) is working fine.

Judging by the revision numbers provided, I'm gonna guess the problem is this: http://navit.svn.sourceforge.net/navit/?rev=4630&view=rev

Should have been fixed in http://navit.svn.sourceforge.net/navit/?rev=4632&view=rev. Please test it as I'm unable to reproduce that.

comment:20 Changed 9 years ago by aaaapublic

Tested it on 4634. Seems to be working fine now.

Changed 9 years ago by tryagain

Improved algorithm to use case- and accent- insensetive strings comparison. Unfortunately, it won't currently give any change for WinCE and any other platform using built-in copy of glib.

comment:21 Changed 7 years ago by usul

  • Component changed from port/android to core
  • Milestone set to version 0.6.0

I consider this as a request to freeform POI name search.

Will be focused on next major release, as heavy related to usability.

comment:22 Changed 7 years ago by tryagain

  • Resolution set to fixed
  • Status changed from reopened to closed

Actually I would consider this ticket to be closed with r5296. Press the looking glass icon in POI dialogue, enter your query and get results. The search now does the comparison exactly the same way as Town\Street search does.

Please reopen if you feel we still have something to be done on the subject.

comment:23 Changed 7 years ago by usul

Thanks for that tryagain :) #thumbsup

Note: See TracTickets for help on using tickets.