[mkgmap-dev] mkgmap ToDo list

Tue Apr 29 18:35:25 BST 2014

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 at na1400.info
>> To: mkgmap-dev at lists.mkgmap.org.uk
>> 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 at na1400.info
>> > > To: mkgmap-dev at lists.mkgmap.org.uk
>> > > 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 at lists.mkgmap.org.uk
>> > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> > >
>> > > _______________________________________________
>> > > mkgmap-dev mailing list
>> > > mkgmap-dev at lists.mkgmap.org.uk
>> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> >
>> >
>> > _______________________________________________
>> > mkgmap-dev mailing list
>> > mkgmap-dev at lists.mkgmap.org.uk
>> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> >
>> 
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev