[mkgmap-dev] mkgmap ToDo list

Tue Apr 29 19:30:27 BST 2014

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