What should be in the global index by default?
Hi all, I tried to find out what must be in the index and what might help but is not strictly needed. I've tested with maps created by r3931, the maps contain 4 tiles which are ~600 km away from my location. The Oregon 600 has only its "Worldwide Autoroute DEM Basemap" in a gmapbmap.img with ~ 51Mb and my test gmapsupp.img which is about ~35 MB. My findings so far: 1) Address search (or the search for roads/crossings) doesn't work without the global index 2) In MapSource , the search function is completely disabled without the global index, but POI search works without the index in MapSource on my Oregon, and both do not seem to use the index, I see no change in speed with or without the index. 3) MapSource seems to use the gobal index to build the search dialog, POI types which are not indexed are not searchable and they also don't appear when you search for "all POI". I played with options like --x-poi-excl-index=0x2800,0x2f00-0x6700 to verify this. 4) Basecamp and Oregon show the shops Planet and Netto when I search for "net" in all shops. Mapsource shows a list box which starts with names beginning with Net (Netto,Netzwerk) followed by other entries in alphabetical order (Neubad Apotheke, Neue Apotheke). I think this means that MapSource results depend on the global index while Oregon and Basecamp work as well without it. 5) I did not see any effect when using option --make-poi-index besides the increase in size. 6) Search for POI on the device is slow with and without the index, but fast when I use the option to search near a previously found place. I assume that other devices may use the index in a different way, I can only test with the Oregon. Maybe it depends on Hardware, maybe on Firmware. Does anybody know a device which shows a different behaviour than my Oregon? Gerd
Hi Gerd, there are 2 search algorithms in Garmin devices. One uses index, second search near current position and probably uses data directly in img. You can see both versions in Mapsource. Under "Find" menu there are options "Find Places", which uses index and "Find Nearest Places", which doesn't. If you start "Find Places", then you get 4 categories. I guess they could represent 4 different section of index. These are: cities, features (POIs), addresses and intersections. Under feature you find categories and subcategories. These are device specific, could be different in a GPS. I think categories are dependent on index too, since map created by mkgmap behaves differently than cgpsmapper version, even if they contain the same POIs. Search in BaseCamp is weird. I think developers got some idea to integrate multiple algorithms into single search. It took them years to get it working and it still confuses me. Search in GPS seems to work similar to Mapsource. If you search for a name, then most probably it uses index. I'm not sure about search for a category. I think outdoor GPS starts with search near current position but maybe car GPS uses index. -- Best regards, Andrzej
Hi Andrzej, thanks for the hints reg. Mapsource. I've not noticed the option "Find nearest places" (Ctrl+Shift+F). You are right, this seems to ignore the index and shows all possible catgories and the search field for strings is named "Containing" and works like that, "net" finds Planet and Netto. The normal find (Ctrl+F) depends on the index. The dialog is probably created based on data in Mdr18+Mdr19, not Mdr4. I try to get a Nüvi from my mother to find out more details. Maybe index usage also depends on the number of tiles in map. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Sonntag, 7. Mai 2017 15:54 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] What should be in the global index by default? Hi Gerd, there are 2 search algorithms in Garmin devices. One uses index, second search near current position and probably uses data directly in img. You can see both versions in Mapsource. Under "Find" menu there are options "Find Places", which uses index and "Find Nearest Places", which doesn't. If you start "Find Places", then you get 4 categories. I guess they could represent 4 different section of index. These are: cities, features (POIs), addresses and intersections. Under feature you find categories and subcategories. These are device specific, could be different in a GPS. I think categories are dependent on index too, since map created by mkgmap behaves differently than cgpsmapper version, even if they contain the same POIs. Search in BaseCamp is weird. I think developers got some idea to integrate multiple algorithms into single search. It took them years to get it working and it still confuses me. Search in GPS seems to work similar to Mapsource. If you search for a name, then most probably it uses index. I'm not sure about search for a category. I think outdoor GPS starts with search near current position but maybe car GPS uses index. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Andrzej, I've now tried with a Nüvi 2447. I did not see an effect of the index when searching for POI. I also tried with a map created with r3909 (trunk) It seems that the Garmin map "CN Europe NTU 2018.10 Central Region" contains an index which allows the device to suggest names for POI similar to the search for adresses. Means, when I search for shops it shows possible candidates while typing the name. The interesting thing is that MapSource creates nearly the same index as mkgmap when transfering a map to my Oregon, esp. the data regarding POIs looks equal. I've now also created a gmapsupp of Niedersachsen with the default style (182 MB) with r3937 and with option --index. In the address search, when I seach for a city, I can type Bux and the device jumps to the result list which correctly shows Buxtehude (which is the only match in that map) without pressing any further key. When I search for cities (as POI) I can type Bux or Buxte and nothing happens until I press the check button. When I do that for Bux it shows me Buxtehude but also many cities Buxton around the world. Those entries are from the basemap, and they appear even if disable the map. While the list is shown the display shows a rotating progress indicator which probably means that the device still scans more tiles. A search in the index would be much faster. Question is if that is a problem in the index or in the device. Does anybody see different results for similar test cases with an Oregon 600 ? If yes, maybe the problem is that the default style produces bad POI entries.. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Sonntag, 7. Mai 2017 17:20:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] What should be in the global index by default? Hi Andrzej, thanks for the hints reg. Mapsource. I've not noticed the option "Find nearest places" (Ctrl+Shift+F). You are right, this seems to ignore the index and shows all possible catgories and the search field for strings is named "Containing" and works like that, "net" finds Planet and Netto. The normal find (Ctrl+F) depends on the index. The dialog is probably created based on data in Mdr18+Mdr19, not Mdr4. I try to get a Nüvi from my mother to find out more details. Maybe index usage also depends on the number of tiles in map. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Sonntag, 7. Mai 2017 15:54 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] What should be in the global index by default? Hi Gerd, there are 2 search algorithms in Garmin devices. One uses index, second search near current position and probably uses data directly in img. You can see both versions in Mapsource. Under "Find" menu there are options "Find Places", which uses index and "Find Nearest Places", which doesn't. If you start "Find Places", then you get 4 categories. I guess they could represent 4 different section of index. These are: cities, features (POIs), addresses and intersections. Under feature you find categories and subcategories. These are device specific, could be different in a GPS. I think categories are dependent on index too, since map created by mkgmap behaves differently than cgpsmapper version, even if they contain the same POIs. Search in BaseCamp is weird. I think developers got some idea to integrate multiple algorithms into single search. It took them years to get it working and it still confuses me. Search in GPS seems to work similar to Mapsource. If you search for a name, then most probably it uses index. I'm not sure about search for a category. I think outdoor GPS starts with search near current position but maybe car GPS uses index. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I did some testing with map of Poland and nuvis 3540 and 1440. I have looked for address, cities and POIs. On 3540 I get hints for each type of search. On 1440 there are no hints. I don't know, if this indicate the use of index. Maybe 3540 is simply more capable and can access data in tiles faster. In case of address and city, nuvi shows list of results before entering a full name. I think it shows list, when there is a limited number of results. When looking for a city, names in different regions are treated as different hits, so list is longer than when searching for address. This could be a cause for different behavior. I think that index in gmapsupp doesn't contain full name, it is like 4 first characters or something. So even when using index, nuvi has to get full name from tiles. This could cause search delay and could be the reason for showing the hourglass icon. With my very limited test, I didn't spot any problems. I have tested gmapsupp.img created by mkgmap and by MapInstall. Both worked the same. MapInstall adds another type of index to gmapsupp, it has extension MD2. I don't know what it is for, maps work without it too. -- Best regards, Andrzej
Hi Andrzej, thanks for the info. I also noticed the MD2 file before and have no idea what it contains, but the name sounds to me like a short form of "MDR Version 2", so I also guessed that it is an index. It seems to contain compressed data, at least I see almost no readable strings. And yes, index in gmapsupp doesn't contain full name but lists containing the first 2 or 4 characters of names(MDR17). BTW: The search for cities (as POI) doesn't seem to search for sub strings as with the other POI types, a search for amb will not find Hamburg or Bamberg, and city POI have their own list in MDR17. I assume that older devices did not do that sub string search for POI names. In that case they probably use the index. Maybe someone with a device older than - say - 8 years can try that? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Mittwoch, 10. Mai 2017 01:56:07 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] What should be in the global index by default? Hi Gerd, I did some testing with map of Poland and nuvis 3540 and 1440. I have looked for address, cities and POIs. On 3540 I get hints for each type of search. On 1440 there are no hints. I don't know, if this indicate the use of index. Maybe 3540 is simply more capable and can access data in tiles faster. In case of address and city, nuvi shows list of results before entering a full name. I think it shows list, when there is a limited number of results. When looking for a city, names in different regions are treated as different hits, so list is longer than when searching for address. This could be a cause for different behavior. I think that index in gmapsupp doesn't contain full name, it is like 4 first characters or something. So even when using index, nuvi has to get full name from tiles. This could cause search delay and could be the reason for showing the hourglass icon. With my very limited test, I didn't spot any problems. I have tested gmapsupp.img created by mkgmap and by MapInstall. Both worked the same. MapInstall adds another type of index to gmapsupp, it has extension MD2. I don't know what it is for, maps work without it too. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (2)
-
Andrzej Popowski -
Gerd Petermann