
Hi all, I stumbled over a problem in mkgmap when I build a map with my bikeroute style (an overlay-map to highlight bicycle routes) I get a non-functional map for bigger areas. There is no error message during the build process, just the resulting map file is faulty. When I remove some tiles the map is OK. It seems to be related to the size of the map, not the data itself. I composed a sample that produces a good and a bad map. Unfortunately the files are rather big. The smallest example I could build is ~600MB. I will provide a link to the example once the upload has finished. <http://gis.19327.n8.nabble.com/file/t339543/BAD.bmp> <http://gis.19327.n8.nabble.com/file/t339543/GOOD.bmp> The faulty map get displayed in the Garmin's map list as "Map data (c) OpenStreetmap" while the good map get displayed correctly as "Bikeroute" When I remove one tile from the build the map is OK. It does not matter which one I remove. So there is no error in one single tile. It has to be a more complex problem. Ciao, Franco -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

Hi Franco, there is a limit for maximum number of tiles, that GPS can process. It depends on device, I think it could be like 2000 or 4000 tiles. Is your map that big? -- Best regards, Andrzej

now hrer's the link to the data: test_cases.tar.gz <https://www.dropbox.com/s/lkqknpl6fi5ot3a/test_cases.tar.gz?dl=0> No, the map is not that big at all, some 200 tiles. I build several maps from the same tiles, and only two of them have issues. One that is drawing the administrative boundaries as an overlay, and the cycleroute-highlights. as the boundaries layer is bigger in size I chose the bikeroute for the example. -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

a resulting bad map : bad_gmapsupp.img <http://files.mkgmap.org.uk/download/420/bad_gmapsupp.img> Just one tile less - no problem - good_gmapsupp.img <http://files.mkgmap.org.uk/download/421/good_gmapsupp.img> -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

Hi Franco, there are 2 weird things in your maps. First is a subfile SRT, which doesn't belong to any tile or index. It is present in both files, bad and good img. It is probably ignored by GPS. Maybe mkgmap writes SRT even if MDR is not present? Second distinction is that bad img is missing MPS subfile, which is kind of directory with names of combined img. This could be the reason for different name in GPS, but I think the map should still work correctly. Again, maybe there is some kind of limit of tiles, that mkgmap remembers, when creating MPS subfile? So IMHO the problem is with combining your map into single gmapsupp.img. You could install map for BaseCamp and then use MapInstall for creating combined map. -- Best regards, Andrzej

Hi Franco
a resulting bad map : bad_gmapsupp.img <http://files.mkgmap.org.uk/download/420/bad_gmapsupp.img>
Just one tile less - no problem - good_gmapsupp.img <http://files.mkgmap.org.uk/download/421/good_gmapsupp.img>
Thanks for providing this useful test case. This is a bug in the recent code used to calculate the best block size to use. It is missing a constraint on the block size to restrict the number of blocks in the directory file. The attached patch fixes this and I'll commit this today. Thanks ..Steve

Hi Steve and Andrzej, now it works as intended again. Thanks for the fix :-) Ciao, Franco -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

Hi Steve, what about SRT subfile? I think SRT is only a part of an MDR (or a part of a tile). It is associated to MDR by its name. See code in GmapsuppBuilder.java: if (createIndex) { MdrBuilder mdrBuilder = addMdrFile(familyId, info.getSort()); mdrBuilder.onMapEnd(info); } addSrtFile(familyId, info); Maybe it should be like that: if (createIndex) { MdrBuilder mdrBuilder = addMdrFile(familyId, info.getSort()); addSrtFile(familyId, info); mdrBuilder.onMapEnd(info); } -- Best regards, Andrzej

Hi Andrzej The SRT determines the sort order of names in the MDR and also within the IMG file. So it seems to me that one is always required. I assumed that the MDR file was just a convenient place to put it. When you create a gmapsupp from a map with a MDR, there is only a single SRT file which must apply to the MDR and also to the individual IMG files. I recently noticed that some Garmin maps have the SRT file repeated for every IMG file within the gmapsupp.img as well as a copy for the MDR. But I don't know, perhaps when there is no MDR the SRT does not get picked up. Only experiment can show what is needed. Cheers, Steve
what about SRT subfile? I think SRT is only a part of an MDR (or a part of a tile). It is associated to MDR by its name. See code in GmapsuppBuilder.java:
if (createIndex) { MdrBuilder mdrBuilder = addMdrFile(familyId, info.getSort()); mdrBuilder.onMapEnd(info); } addSrtFile(familyId, info);
Maybe it should be like that: if (createIndex) { MdrBuilder mdrBuilder = addMdrFile(familyId, info.getSort()); addSrtFile(familyId, info); mdrBuilder.onMapEnd(info); }

Hi Steve, I observe the same - on Garmin's maps each tile gets SRT and MDR get its own SRT too. My general assumption is that GPS sorts subfiles by name, so 12345678.SRT is used only for 12345678.LBL. If there is 00001234.MDR then it can use only 00001234.SRT. If there is xxxx.SRT that doesn't fit any LBL or MDR then it is probably ignored. -- Best regards, Andrzej
participants (3)
-
Andrzej Popowski
-
franco_bez
-
Steve Ratcliffe