Searching POI by name - very slow

 

On Nuvi 765t, whenever I need to find a POI (a regular one), if I search by categories, the results come up almost instantly. But if I try to search by name, it always takes an unbelievably long time, sometimes 10 minutes and more - even when it eventually returns the very POI's that are not far away, and would be among the first ones if searched by category.

I recall I saw couple of times this problem mentioned in reviews etc., as common Garmin problem; wondering, is this everybody's experience? can something be done about it? if they have a database of POI's, is the concept of indexing by name in addition to indexing by category, such a novel thing?

Populating the list

Probably the software is waiting until the search will fill out the screen, or comes to and end, before presenting it to you on the screen.

--
NUVI40 Kingsport TN

Same

Same on my 1490T.

NUVI40

perpster wrote:

Same on my 1490T.

Same on my NUVI40. I've noticed that the screen will not show results unless the screen is full or the search is at an end.

--
NUVI40 Kingsport TN

indexing.

I don't know how the built-in POI's are stored internally in the Garmin map data, but my guess is that the slow name search has something to do with the way the data is indexed. The index is probably optimized for searching by location rather than name.

--
Alan - Android Auto, DriveLuxe 51LMT-S, DriveLuxe 50LMTHD, Nuvi 3597LMTHD, Oregon 550T, Nuvi 855, Nuvi 755T, Lowrance Endura Sierra, Bosch Nyon

Yes

alandb wrote:

I don't know how the built-in POI's are stored internally in the Garmin map data, but my guess is that the slow name search has something to do with the way the data is indexed. The index is probably optimized for searching by location rather than name.

You are right. Didn't think of that. To test this, type only a few letters in the search screen. It will bring back entries with the letter combination anywhere in the name. This shows me that the name is probably not indexed by the name.

--
NUVI40 Kingsport TN

Any database allows many

Any database allows many indexes on the same table, and it's pretty much standard practice. Nothing prevents from having one index by the category, another by name, third by phone number, .....

Normalize the database

vrapp wrote:

Any database allows many indexes on the same table, and it's pretty much standard practice. Nothing prevents from having one index by the category, another by name, third by phone number, .....

Yes, but the more you have, the slower the updates and the larger the footprint. A well normalized database will only have indices on the important fields.

--
NUVI40 Kingsport TN

I guess, the name _is_

I guess, the name _is_ important... even more than the category; and the updates are not everyday operation expected to be fast. But anyway, it probably does not matter what we think here, what matters is how it's really implemented in Garmin.

Heh

vrapp wrote:

I guess, the name _is_ important... even more than the category; and the updates are not everyday operation expected to be fast. But anyway, it probably does not matter what we think here, what matters is how it's really implemented in Garmin.

True, very true. That IS the issue!

--
NUVI40 Kingsport TN

I think if they implemented

I think if they implemented it so that results were displayed -as soon as they were found- instead of after the complete search results list is built it would help to dispel the perception that the search takes a long time. We know that all kinds of work is going on in the background while the "hour glass" is spinning: this has to be the case to get the "instant" list display we see at the end. If Garmin would just display the list as it builds it would help with our "impatience factor".

--
"Primum Non Nocere" 2595LMT Clear Channel and Navteq Traffic