Same for me. Even indexes of maps not 'enabed' are searched and if covering the same area even displays duplicate results. Where I first copied big maps to my Oregon just because there was space enough on the 32GB SSD, now I build smaller maps and rename them if not used that (holi)day(s) Kind Regards Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: maandag 1 juni 2020 08:21 Aan: mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] Performance of POI search on the Device Hi Franco, I had the same problem with my Oregon and found out that the existence of a 2nd map triggered this. For a test I renamed the 2nd map to *.img_ and was very surprised that this solved the search problem. In my case, the 2nd map was the cycling layer TK-Europe-Bicycling from Thomas Kukuk, but I have no idea why it causes the problems. I assume there is a firmware bug in the Oregon. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von franco_bez <franco.bez@web.de> Gesendet: Montag, 1. Juni 2020 07:16 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] Performance of POI search on the Device Hi all, searching for POIs on my Oregon often is very frustrating. It virtually takes forever. Yesterday I noticed that some POI types are reasonably fast, while others are 10 times slower. I assume that this is some sort of index Problem. For example using my DACH map, built with mkgmap-r4506, map size 2.7GiB on my Oregon 750t - searching for Gas Stations takes some 5 seconds - searching for Bank/ATM takes some 50 seconds - searching for Any-/All Poi types also takes some 50 seconds for the first Elements to appear in the list. If I can trust my memory, in the past, maybe some 2 years ago, searching for Gas Stations was just as slow as any other POI type. What can I do to get the POI search fast for any POI type in the map ? I tried --make-poi-index but this didn't make any noticeable difference. Ciao, Franco -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ 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

Joris Bo wrote

Same for me. Even indexes of maps not 'enabed' are searched and if covering the same area even displays duplicate results. Where I first copied big maps to my Oregon just because there was space enough on the 32GB SSD, now I build smaller maps and rename them if not used that (holi)day(s)

Kind Regards Joris

Hi Joris, I remember having had POIs in the search list that came from disabled maps. That's why I renamed the pre-installed GARMIN maps instead of just diasbaling them. ------------- I made a few tests just now. If I enable all my routable maps for all of Europe (some 7 GiB total) the POI search still is incredibly fast, roundabout 1 second. But if I have one of my non-routable, transparent overlay maps (contourlines for instance) on the SD Card the search speed is going down significantly. I will try if this is triggerd by the "route" option and let you know. Ciao, Franco -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

I also thought that the missing index of the overlay map might cause the problem. I added an (empty) index to that map but that didn't help. Maybe it helps to add a single (invisible) named POI to each tile. If that helps it would prove that the bug is in the Oregon firmware. I don't think that contour lines are the problem. The TK-Europe-Bicycling map doesn't contain contourlines, only cycle routes as non-routable lines. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Montag, 1. Juni 2020 09:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Performance of POI search on the Device Cool! Franco My godfeeling was telling me that this contourline overlay does do something. Did not yet find time to investigate it more properly. I also always have an Europe transparent contourline overlay map on my SSD (in case of...) Probably the lines and numbers are searched without being indexed or because it are numbers, they fill up the first whatever 2.000.000 entries in the index as being sorted on top... Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens franco_bez Verzonden: maandag 1 juni 2020 09:08 Aan: mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] Performance of POI search on the Device Joris Bo wrote

Same for me. Even indexes of maps not 'enabed' are searched and if covering the same area even displays duplicate results. Where I first copied big maps to my Oregon just because there was space enough on the 32GB SSD, now I build smaller maps and rename them if not used that (holi)day(s)

Kind Regards Joris

Hi Joris, I remember having had POIs in the search list that came from disabled maps. That's why I renamed the pre-installed GARMIN maps instead of just diasbaling them. ------------- I made a few tests just now. If I enable all my routable maps for all of Europe (some 7 GiB total) the POI search still is incredibly fast, roundabout 1 second. But if I have one of my non-routable, transparent overlay maps (contourlines for instance) on the SD Card the search speed is going down significantly. I will try if this is triggerd by the "route" option and let you know. Ciao, Franco -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ 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 Franco, while experimenting I would simply use JOSM to do that. There is no need to create a map with many tiles, I think could reproduce the problem with a single tile. If you find out that this helps I can add an option to mkgmap to add at least one POI in the center of the map. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von franco_bez <franco.bez@web.de> Gesendet: Montag, 1. Juni 2020 10:16 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance of POI search on the Device Gerd Petermann wrote

I also thought that the missing index of the overlay map might cause the problem. I added an (empty) index to that map but that didn't help. Maybe it helps to add a single (invisible) named POI to each tile. If that helps it would prove that the bug is in the Oregon firmware. I don't think that contour lines are the problem. The TK-Europe-Bicycling map doesn't contain contourlines, only cycle routes as non-routable lines.

Gerd

Hi Gerd, I tried to rebuild one of my layers with the options "index" and "route". That didn't make any difference. I have used my "housenumbers" layer, it does not contain contourlines neither. How can I build a map with one POI per tile? Ciao, Franco -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Franco, okay, I'll try to code a patch for this. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von franco_bez <franco.bez@web.de> Gesendet: Montag, 1. Juni 2020 10:41 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance of POI search on the Device Hi Gerd, I'm a little lost. I don't know how to proceed with the testing. I just tried a small map of the offensive "housenumber" layer. This makes no measurable difference in POI search. When I use a large "housenumber" map (covering DACH) the effect is significant. So I assume a single tile would not be useful for testing. If I could somehow add a few POIs to my existing offensive map this would help. Ciao, Franco -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Gerd, thanks for the binary. I did a lot of testing. I do not get any difference. As soon as I have a transparent layer, like housenumbers or bundaries the POI search is slow. not matter if I have "route" and "index" in the options or not. I also tried with and without "--x-center-poi-type=0x3200". I also can not find a POI named "center of map" do I have to add an additional option? a sample layer built with the patched mkgmap: dach_boundary_gmapsupp.img <http://files.mkgmap.org.uk/download/475/dach_boundary_gmapsupp.img> Ciao, Franco Gerd Petermann wrote

Hi Franco,

here is a quick hack to add a POI in the center of a map at resolution 24. If the source contains no POI. Default type is 0x6601. You can use e.g. --x-center-poi-type=0x3200 to change the type to a bollard. The name of the POI is "center of map"

I've only tested that the POI is added to the map and to the index of POIs.

The binary is here: http://files.mkgmap.org.uk/download/474/mkgmap.jar

Gerd

-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

Hi Franco, interesting! The file created with the patched version is quite different. It contains NET and NOD sections and also a MDR (the global index). Did you try option --x-center-poi-type=0x2f01 with the patched version? Maybe the type is important and 0x6601 was a bad choice. I've checked only a few tiles, but all of them contained at least one fuel station with additional address info (city/country/phone number). Maybe that's the important thing. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von franco_bez <franco.bez@web.de> Gesendet: Montag, 1. Juni 2020 23:44 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance of POI search on the Device Hi Gerd, some more test results: I switched back to the unpatched mkgmap-r4506. Instead I added some POIs to the boundary style (all fuel stations). This helped, now POI search is still fast. this file gives no problems, includes fuel stations <http://files.mkgmap.org.uk/download/476/dach_boundary_gmapsupp.img> the previous file (see below) triggers the problem. Ciao, Franco franco_bez wrote

Hi Gerd, thanks for the binary. I did a lot of testing. I do not get any difference. As soon as I have a transparent layer, like housenumbers or bundaries the POI search is slow. not matter if I have "route" and "index" in the options or not. I also tried with and without "--x-center-poi-type=0x3200".

I also can not find a POI named "center of map" do I have to add an additional option? a sample layer built with the patched mkgmap: dach_boundary_gmapsupp.img <http://files.mkgmap.org.uk/download/475/dach_boundary_gmapsupp.img>;

Ciao, Franco

Gerd Petermann wrote

...

Hi Franco,

here is a quick hack to add a POI in the center of a map at resolution 24. If the source contains no POI. Default type is 0x6601. You can use e.g. --x-center-poi-type=0x3200 to change the type to a bollard. The name of the POI is "center of map"

I've only tested that the POI is added to the map and to the index of POIs.

The binary is here: http://files.mkgmap.org.uk/download/474/mkgmap.jar

Gerd

-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list

mkgmap-dev@.org

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Franco, I tried your two maps and the saerch with the "good" one is indeed much faster, but still also slower than the search with just one map. I tried to produce my own overlay map to reproduce the results but it never shows such a big impact. My map contains only cycle routes for Germany and the gmapsupp is much smaller. I tried different draw-priorities, different types in the map, with/without index. No more time today, I'll try other things tomorrow... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von franco_bez <franco.bez@web.de> Gesendet: Dienstag, 2. Juni 2020 11:08 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance of POI search on the Device Hi Gerd, probabally I tried the "route" and "index" options with the patched version to see if it helps. (it didn't) I just tried the default center-POI type and 0x3200 - made no difference. I can do further testing in the evening. Ciao, Franco Gerd Petermann wrote

Hi Franco,

interesting! The file created with the patched version is quite different. It contains NET and NOD sections and also a MDR (the global index). Did you try option --x-center-poi-type=0x2f01 with the patched version? Maybe the type is important and 0x6601 was a bad choice. I've checked only a few tiles, but all of them contained at least one fuel station with additional address info (city/country/phone number). Maybe that's the important thing.

Gerd

-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi all, I still try to understand why the existence of a (transparent) overlay map can slow down the search for POI. It seems the more tiles we have in the overlay the longer the delay. So, it looks like the Oregon performs a sequential search over all tiles in the overlay map. It seems to ignore a global index in that map, but, as Franco found out, it might stop earlier / work faster when the overlay map contains a few POI. My 1st assumption was that the transparent flag makes it difficult for the device to find out if the tile contains any data that may be relevant as it doesn't contain the 0x4b polygon. I tried with a semi-transparent map (0x4b polygon written and transparent flag set). Didn't improve anything. So, another idea is that the POI with address info change the content of the LBL file header because e.g. the list of countries is filled. Maybe the device checks this. Looking at this now... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von franco_bez <franco.bez@web.de> Gesendet: Dienstag, 2. Juni 2020 18:32 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance of POI search on the Device Hi Gerd, here's the bondary-layer with x-center-poi-type=0x2f01 It slows down the search to the same extent as the other poi-types do. The option does not seem to have any impact. http://files.mkgmap.org.uk/download/477/dach_boundary_gmapsupp.img <http://files.mkgmap.org.uk/download/477/dach_boundary_gmapsupp.img> Ciao, Franco -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Gerd, now this sounds at least a little promissing for overlays with little data. I assume that my contourlines overlay that additionally holds the DEM data for hill shading (europe is almost 4GB) can not be improved that way. With the other overlays I'm a little lost on how to get bigger tiles. Usually I split the data once and then build all the map flavours from the same tiles. Of course the map containing all the roads and routing information needs to have smaller tiles than the overlays. Most likely I will have to split the data with different settings for each map flavour. Or is there any way of joining several osm-tiles into one garmin-tile when creating the gmapsupp image? Ciao,  Franco Am 19.07.20 um 08:39 schrieb Gerd Petermann:

Hi all,

I still try to understand why the existence of a (transparent) overlay map can slow down the search for POI. It seems the more tiles we have in the overlay the longer the delay. So, it looks like the Oregon performs a sequential search over all tiles in the overlay map. It seems to ignore a global index in that map, but, as Franco found out, it might stop earlier / work faster when the overlay map contains a few POI.

My 1st assumption was that the transparent flag makes it difficult for the device to find out if the tile contains any data that may be relevant as it doesn't contain the 0x4b polygon. I tried with a semi-transparent map (0x4b polygon written and transparent flag set). Didn't improve anything. So, another idea is that the POI with address info change the content of the LBL file header because e.g. the list of countries is filled. Maybe the device checks this. Looking at this now...

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von franco_bez <franco.bez@web.de> Gesendet: Dienstag, 2. Juni 2020 18:32 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance of POI search on the Device

Hi Gerd,

here's the bondary-layer with x-center-poi-type=0x2f01 It slows down the search to the same extent as the other poi-types do. The option does not seem to have any impact. http://files.mkgmap.org.uk/download/477/dach_boundary_gmapsupp.img <http://files.mkgmap.org.uk/download/477/dach_boundary_gmapsupp.img> Ciao, Franco

-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Gerd, thank you so much. That did the trick. If I only have the one map file on my SD Card the POI search is incredibly fast. Now I try to identify the offending map(s) Ciao, Franco -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html