[mkgmap-dev] Split gmapsupp.img files over 4GB

Tue Jun 9 14:34:34 BST 2020

using splitter to create smaller regions - would mean you need to create
separate maps for each region - and at that time you do not know the size.
The easiest would be for mkgmap just to add up .img files upto say 3700MB -
so that there is enough space left over for the overhead of the mdr file.

Just stop adding to gmapsupX.img as soon as this limit is reached, and
continue with the next gmapsup1.img (order of .img files simply by rising
number). I think with maps this big - everyone will create the gmapsupp.img
anyhow in a second step - so the .img files already exists (not at the same
run as creating the .img files). If there could be some region sorting
automatically - that would be nice - but it's fine if it's just split up by
rising mapID. I never checked - but I think that is how MapInstall is doing
it too.

On Tue, 9 Jun 2020 at 14:34, Gerd Petermann <gpetermann_muenchen at hotmail.com>
wrote:

> Hi Felix,
>
> maybe I give it a try, but I still don't understand your problem reg. the
> script. If you already know that a single file doesn't work why don't you
> create 10 files, each being much smaller than 4GB? I thought the splitter
> option num-tiles= was implemented for this.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von
> Felix Hartmann <extremecarver at gmail.com>
> Gesendet: Dienstag, 9. Juni 2020 14:03
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Split gmapsupp.img files over 4GB
>
> Hi Gerd,
> Same result as MapInstall (Basecamp). So yes - same family Id, description
> and so on - just a different filename. gmapsup1.img; gmapsup2.img and so
> on. MapInstall does the same if you send maps over 4GB to devices that can
> support several gmapsupp.img files.
>
> It's pretty cumbersome to run a script to only include individual .img
> files up to 4GB for each run...
> Essentially making it possible to create Europe continent map in
> gmapsupp.img format (several files) or Asia continent (or even whole world
> - but I guess no one will do so - except if cutting down data very strong).
>
>
> Currently mkgmap just creates gmapsupp.img files over 4GB - they cannot be
> used by any garmin device due to FAT32 limits.
>
> On Tue, 9 Jun 2020 at 08:06, Gerd Petermann <
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com>>
> wrote:
> Hi Felix,
>
> sorry, I have no idea what the result of such a split should be. Two
> gmapsupp files with different content but equal family-id, description etc?
> Doesn't sound like a good idea to me. My understanding is that a map
> creator has to decide what part of the world should go into one gmapsupp.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>
> Gesendet: Montag, 8. Juni 2020 12:19
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] Split gmapsupp.img files over 4GB
>
> Could mkgmap automatically split gmapsupp.img over 4GB (or have an option
> to do so - but besides Oruxsmaps/locus and some other not often used tools
> - I don't know any others that can use larger gmapsupp.img files duet to
> FAT32).
>
> It would be nice if those gmapsupp.img files were somehow rastered - but
> even just according to mapid would be fine.
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>

-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20200609/41d0ce01/attachment.html>