Opening gmapsupp.img with Basecamp?
Hi All, I've been experimenting with Garmin BaseCamp opening gmapsupp.img files that I create. It works fine for some files (even getting the .TYP styling correct) but not for others. After a few hours of testing it seems that it'll open gmapsupp.img files created from 1-20 .osm files but not 30+ .osm files. I'm not certain yet if it's the exact number of files, or the combined size that triggers the failure. Does anyone have any experience with this? or know if there's a particular limit? Anyone been able to generate gmapsupp.img covering (say) the whole UK and get them to open with BaseCamp? I'm willing to do more troubleshooting if that'll help. Cheers, Andy Using mkgmap-r1867 Files split with splitter.jar --max-nodes=900000 java -Xmx3000M -jar ../../mkgmap-r1867/mkgmap.jar \ --family-name="OSM" \ --series-name="OSM" \ --family-id=88 \ --product-id=77 \ --gmapsupp \ --country-abbr="GBR" \ --route --net --remove-short-arcs \ --style-file=../../mkgmap-r1867/resources/styles/cyclemap \ /home/andy/uk/533300[123]*.osm.gz \ ../M0000058.TYP
On 17.03.2011 20:09, Andy Allan wrote:
Hi All,
I've been experimenting with Garmin BaseCamp opening gmapsupp.img files that I create. It works fine for some files (even getting the .TYP styling correct) but not for others. After a few hours of testing it seems that it'll open gmapsupp.img files created from 1-20 .osm files but not 30+ .osm files. I'm not certain yet if it's the exact number of files, or the combined size that triggers the failure.
Does anyone have any experience with this? or know if there's a particular limit? Anyone been able to generate gmapsupp.img covering (say) the whole UK and get them to open with BaseCamp? Have you tried if there is a difference whether the gmapsupp got created by mkgmap, sendmap or Basecamp/Mapsource?? Maybe mkgmap makes some mistakes when creating the gmapsupp, and on big files it doesn't work. Note however that in any case a map like whole UK will take quite some time to import to Basecamp (and lots of RAM). I'm willing to do more troubleshooting if that'll help.
Cheers, Andy
Using mkgmap-r1867 Files split with splitter.jar --max-nodes=900000
java -Xmx3000M -jar ../../mkgmap-r1867/mkgmap.jar \ --family-name="OSM" \ --series-name="OSM" \ --family-id=88 \ --product-id=77 \ --gmapsupp \ --country-abbr="GBR" \ --route --net --remove-short-arcs \ --style-file=../../mkgmap-r1867/resources/styles/cyclemap \ /home/andy/uk/533300[123]*.osm.gz \ ../M0000058.TYP _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi
I've been experimenting with Garmin BaseCamp opening gmapsupp.img files that I create. It works fine for some files (even getting the .TYP styling correct) but not for others. After a few hours of testing it seems that it'll open gmapsupp.img files created from 1-20 .osm files but not 30+ .osm files. I'm not certain yet if it's the exact number of files, or the combined size that triggers the failure.
Is the size of the resulting gmapsupp.img around 128M when it goes wrong? If so it could be the 'filesystem' parameters in the header, which are set to allow a size of 128M. This is ignored by devices so isn't usually a problem. ..Steve
On Sun, Mar 20, 2011 at 2:02 PM, Steve Ratcliffe <steve@parabola.me.uk> wrote:
Hi
I've been experimenting with Garmin BaseCamp opening gmapsupp.img files that I create. It works fine for some files (even getting the .TYP styling correct) but not for others. After a few hours of testing it seems that it'll open gmapsupp.img files created from 1-20 .osm files but not 30+ .osm files. I'm not certain yet if it's the exact number of files, or the combined size that triggers the failure.
Is the size of the resulting gmapsupp.img around 128M when it goes wrong?
If so it could be the 'filesystem' parameters in the header, which are set to allow a size of 128M. This is ignored by devices so isn't usually a problem.
Sorry for the delay. That's exactly the problem, it works for maps up to 128M but not higher than that. I had a little explore in the source code and found the tantalising "gives 128M will try more later" comment, and naively tried a larger number of cylinders. Tried 0x200 but that didn't work. Reading the code below that bit I realise now it might not be so easy :-) I'm happy to do some more experimentation / testing patches etc if you can give me some things to try. Cheers, Andy
Hi
Sorry for the delay. That's exactly the problem, it works for maps up to 128M but not higher than that.
I had a little explore in the source code and found the tantalising "gives 128M will try more later" comment, and naively tried a larger number of cylinders. Tried 0x200 but that didn't work. Reading the code below that bit I realise now it might not be so easy :-)
I'm happy to do some more experimentation / testing patches etc if you can give me some things to try.
Could you try the attached patch please. If it works it should take it up to 512M. If you need more than that there will have to be some experimentation to find out what is implemented. Actual devices ignore all this as far as I know. ..Steve
On Thu, Mar 31, 2011 at 6:34 PM, Steve Ratcliffe <steve@parabola.me.uk> wrote:
I'm happy to do some more experimentation / testing patches etc if you can give me some things to try.
Could you try the attached patch please. If it works it should take it up to 512M.
If you need more than that there will have to be some experimentation to find out what is implemented. Actual devices ignore all this as far as I know.
Initial testing is good - I got an image of 172M working fine. Thanks! I haven't yet tested all the way to 512M. It would be great for me if images up to 2G in total were supported. Next week I'll try Felix's suggestions of going via the mapsource installer and see if I can generate large gmapsupp.img files that big that Basecamp is happy with. That might give us some hints as to what's ultimately possible. Cheers, Andy
On Fri, Apr 1, 2011 at 2:59 PM, Andy Allan <gravitystorm@gmail.com> wrote:
On Thu, Mar 31, 2011 at 6:34 PM, Steve Ratcliffe <steve@parabola.me.uk> wrote:
I'm happy to do some more experimentation / testing patches etc if you can give me some things to try.
Could you try the attached patch please. If it works it should take it up to 512M.
If you need more than that there will have to be some experimentation to find out what is implemented. Actual devices ignore all this as far as I know.
Initial testing is good - I got an image of 172M working fine. Thanks! I haven't yet tested all the way to 512M.
It would be great for me if images up to 2G in total were supported. Next week I'll try Felix's suggestions of going via the mapsource installer and see if I can generate large gmapsupp.img files that big that Basecamp is happy with. That might give us some hints as to what's ultimately possible.
I spent a few hours on this today, but I couldn't get the nsis installer working with large files - when I ran the .exe it would crash complaining the installer was corrupt. However, I did manage to get the nsis installer running and installed a small (~121M) .exe file, and then used Basecamp to re-export that as a gmapsupp.img (~173M, about 4k bigger than the one mkgmap produced). I've spotted two interesting things about it 1) Basecamp won't re-import it the manner that it imports a gmapsupp that mkgmap produces, which is annoying. 2) The values at OFF_HEADS and OFF_CYLINDERS are different and suggest the upper limits aren't what we think What's the etiquette for reverse engineering this stuff? Is it helpful for me to post e.g. "hd gmapsupp.img | head -n 20" or is that a bad idea? Cheers, Andy
I spent a few hours on this today, but I couldn't get the nsis installer working with large files - when I ran the .exe it would crash complaining the installer was corrupt.
How large is large? i.e. how many maps, what is the size of all IMG files and what is the final size of the installer? I do fairly large maps and do not have a problem.
On Thu, Apr 7, 2011 at 9:10 PM, Nakor <nakor.osm@gmail.com> wrote:
I spent a few hours on this today, but I couldn't get the nsis installer working with large files - when I ran the .exe it would crash complaining the installer was corrupt.
How large is large? i.e. how many maps, what is the size of all IMG files and what is the final size of the installer?
I do fairly large maps and do not have a problem.
Thanks for the encouragement. I tried again and got it working - 780M installer, 293 tiles, and got basecamp to create a 1.1G gmapsupp.img file. I've been keeping the gmapsupp.img files that basecamp creates in case there's information in them that can help the reverse engineering of the HEADS and CYLINDERS and suchlike. Cheers, Andy
On 04/07/2011 04:10 PM, Nakor wrote:
I spent a few hours on this today, but I couldn't get the nsis installer working with large files - when I ran the .exe it would crash complaining the installer was corrupt.
How large is large? i.e. how many maps, what is the size of all IMG files and what is the final size of the installer?
I do fairly large maps and do not have a problem.
I tried very large and could not generate the installer. From NSIS forums, you cannot built an NSIS installer with more than 2Gb compressed data in it. Over 2Gb you need to use some NSIS plugin to pack some of the data outside the installer executable.
Hello
1) Basecamp won't re-import it the manner that it imports a gmapsupp that mkgmap produces, which is annoying. 2) The values at OFF_HEADS and OFF_CYLINDERS are different and suggest the upper limits aren't what we think
Its possible that the maximums that I found were conditional on something else. Also possible that some of the locations that are indentified as containing heads/sectors are not correct.
What's the etiquette for reverse engineering this stuff? Is it helpful for me to post e.g. "hd gmapsupp.img | head -n 20" or is that a bad
You need the file up to about 01d0, where the partition table ends, so probably head -n 30 would be needed. It would be useful to have the exact size of the gmapsupp.img file too. From your other message you appear to have a bunch of these, you can just send those the headers to me if you like. I have an example of my own, but need some more examples to really work it out. Cheers ..Steve
participants (4)
-
Andy Allan -
Felix Hartmann -
Nakor -
Steve Ratcliffe