Great that I could finally give you what you were looking for. Sorry for not understanding earlier. It would still be awesome to have a --min-files option in Splitter. Btw, now that I'm counting, and for comparison, below the distribution of my new generic map with a much larger max-file-size and --max-nodess=1200000: 1-2MB 37 2-3MB 210 3-4MB 330 4-5MB 350 5-6MB 324 6-7MB 260 7-8MB 200 8-9MB 160 9-10MB 100 10-11MB 70 11-12MB 40 12-13MB 40 13-14MB 20 14-15MB 10 15-16MB 10 16-17MB 2 17-18MB 3 18-19MB 2 19-20MB 3 20-21MB 2 And a Europe contour map with --max-nodes=8000000 without size restriction: 7-8MB 3 8-9MB 4 9-10MB 7 10-11MB 3 11-12MB 3 12-13MB 11 13-14MB 22 14-15MB 14 15-16MB 10 16-17MB 1 On 2014-04-29 20:51, Gerd Petermann wrote:
Hi Lambertus,
okay, so that's what I meant reg. the factor 3 between largest and smallest part.
Gerd
To: mkgmap-dev@lists.mkgmap.org.uk Date: Tue, 29 Apr 2014 20:48:24 +0200 From: osm@na1400.info Subject: Re: [mkgmap-dev] mkgmap ToDo list
I don't have the number for Germany, but perhaps the world suffices?
The image size distribution of my generic map is: <2MB some 2-3MB 260 3-4MB 410 4-5MB 600 5-6MB 580 6-7MB 390 7-8MB 250
On 2014-04-29 20:37, Gerd Petermann wrote:
Hi Lambertus,
okay, if I got that right you finally get *.img files with a size near (but below) 8MB, so maybe Henning can use that script, too.
If you do that for e.g. Germany, how small is tpically the smallest *.img file ? Is it probably near 4 MB?
Gerd
To: mkgmap-dev@lists.mkgmap.org.uk Date: Tue, 29 Apr 2014 20:30:27 +0200 From: osm@na1400.info Subject: Re: [mkgmap-dev] mkgmap ToDo list
These are the direct results from Splitter. The format is o5m, both input as output. Splitter version is: r321.
For this test I split the original source with --max-nodes=8000000. Then I render the initial tiles, when the result is larger than 8MB it's subsplit again with --max-nodes=(8000000-(attempt*100000)). The initial source files are ~70MB (o5m) and after several subsplits the two *.img are < 8MB. During this process --max-nodes has been reduced to e.g. 7500000 and the source file is split up in two o5m files of about 37MB.
I can upload an example source file and it's two subsplit siblings if you want.
On 2014-04-29 19:38, GerdP wrote:
Hi Lambertus,
that's interesting. Are these the img file sizes or the osm file sizes?
Gerd
Lambertus wrote
Unfortunately I cannot confirm that. Below is a bit of logging from my script: Original: 97000020 (70551453), New: 0 (35684445), New: 1 (36852845) Original: 97000001 (74621042), New: 0 (37522992), New: 1 (37222739) Original: 97000002 (73391358), New: 0 (37679505), New: 1 (38098627) Original: 97000003 (77862567), New: 0 (39075311), New: 1 (39261197)
The original files above contain contour data, the filesize is between brackets. As you can see both resulting file are approximately the same size.
On 2014-04-29 15:39, Gerd Petermann wrote: > Hi Lambertus, > > and I guess that even after this optimization you will > see a factor 3 or higher between the largest tile and the smallest. > Can you confirm that? > > Gerd > >> Date: Tue, 29 Apr 2014 15:32:38 +0200 >> From:
osm@
>> To:
mkgmap-dev@.org
>> Subject: Re: [mkgmap-dev] mkgmap ToDo list >> >> Num-tiles=x would indeed be better for this specific need. >> >> It is my experience that it regularly takes multiple calls to > Splitter >> to get 2+ sub-tiles when you reduce the max-nodes by 100k for each >> sub-split attempt. This is what I currently do to get an optimum in >> tile-size vs total number of tiles. >> >> >> >> On 29/04/2014 15:09, Gerd Petermann wrote: >> > Hi Lambertus, >> > >> > that sounds like a possible change in splitter: >> > Instead of specifying max-nodes you may specify --num-tiles=x >> > and splitter will try to find a split that produces excactly x > tiles >> > which are not too narrow and have a node number which is not >> > too far from the average (but still aligned to a multiple of map > units >> > as now). >> > So, for your script that means you don't have to find the > max-nodes >> > value. >> > >> > I'll think about this again... >> > >> > Gerd >> > >> > > Date: Tue, 29 Apr 2014 14:59:36 +0200 >> > > From:
osm@
>> > > To:
mkgmap-dev@.org
>> > > Subject: Re: [mkgmap-dev] mkgmap ToDo list >> > > >> > > While this possibly can be solved in Splitter or Mkgmap, it > could also >> > > be solved by your build-script when you add a maximum tile size > check >> > > and re-split (with a lower number of max-nodes) until you get > two or >> > > more sub-tiles. Granted, this adds complexity to the script but > it works >> > > well for me. >> > > >> > > On 25/04/2014 21:54, Henning Scholland wrote: >> > > > Hi Gerd, >> > > > >> > > > I would like to have img-tiles which have globally nearly the > same >> > > > filesize, so that they use the space of devices like eTrex 10. >> > > > >> > > > With my actual map I use globally the same value for > max-nodes. But the >> > > > size of the img-tiles differ more then factor 2. Eg. a tile in > Germany >> > > > is between 2 and 5 mb where a tile in China is about 10 mb. If > I remove >> > > > details, this difference will increase, because in Germany > more objects >> > > > will be removed from the img-tile then in China. >> > > > >> > > > Henning >> > > > >> > > > _______________________________________________ >> > > > mkgmap-dev mailing list >> > > >
mkgmap-dev@.org
>> > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> > > >> > > _______________________________________________ >> > > mkgmap-dev mailing list >> > >
mkgmap-dev@.org
>> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> > >> > >> > _______________________________________________ >> > mkgmap-dev mailing list >> >
mkgmap-dev@.org
>> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> > >> >> _______________________________________________ >> mkgmap-dev mailing list >>
mkgmap-dev@.org
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > _______________________________________________ > mkgmap-dev mailing list >
mkgmap-dev@.org
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context:
http://gis.19327.n5.nabble.com/mkgmap-ToDo-list-tp5803388p5804588.html
Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ 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
_______________________________________________ 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev