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