<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>maybe also look at <br><a href="https://wiki.openstreetmap.org/wiki/Mkgmap/help/splitter" target="_blank">https://wiki.openstreetmap.org/wiki/Mkgmap/help/splitter#Tuning</a><br><br>(the page needs some updates, but that part is correct)<br><br>Gerd<br><br><div>> Date: Thu, 8 May 2014 09:31:28 +0200<br>> From: osm@na1400.info<br>> To: mkgmap-dev@lists.mkgmap.org.uk<br>> Subject: Re: [mkgmap-dev] splitter r325: improved split algo and new option<br>> <br>> Thanks Gerd! This is valuable information for those of us processing <br>> large areas of the planet.<br>> <br>> Unfortunately there is no additional speedup for me because I already <br>> use o5m because of osmupdate (to keep a local planet copy up-to-date).<br>> <br>> On 07/05/2014 11:59, Gerd Petermann wrote:<br>> > Hi Felix,<br>> ><br>> > try o5m for both input and output, it is much faster.<br>> > The command<br>> > osmcovert --drop-version europe-latest.osm.pbf -o=europe.o5m<br>> > runs quite fast (~70 seconds on my machine),<br>> > the o5m file is ~2.430 MB, the pbf file has 2.104 MB.<br>> ><br>> > Splitter is much faster reading from o5m when<br>> > the keep-complete option is in use.<br>> > (210 secs for the o5m, 441 for pbf)<br>> ><br>> > With --output=pbf both are slower, and mkgmap is also much slower.<br>> ><br>> > All times with I/O on one normal hard disk. Even better results if you have<br>> > two different disks for reading and writing.<br>> ><br>> > Gerd<br>> ><br>> > ------------------------------------------------------------------------<br>> > Date: Wed, 7 May 2014 11:37:58 +0200<br>> > From: extremecarver@gmail.com<br>> > To: mkgmap-dev@lists.mkgmap.org.uk<br>> > Subject: Re: [mkgmap-dev] splitter r325: improved split algo and new option<br>> ><br>> > Well I still use pbf and not o5m.<br>> > First pbf is smaller..<br>> > Second - Geofabrik only offers pbf - that's why I stayed with it.<br>> ><br>> > I don't think I can cut a lot of time by first converting to 05m, then<br>> > hand it over to splitter...<br>> > Actually I also let splitter output pbf... Maybe I could change that in<br>> > future to 05m..<br>> > On 07.05.2014 11:36, Gerd Petermann wrote:<br>> ><br>> > Hi Felix,<br>> ><br>> > well, nowadays splitter performance mostly depends on I/O if you use<br>> > o5m format<br>> > for input and output and give enough heap.<br>> ><br>> > Reg. mkgmap performance improvements: yes, that's what I expected.<br>> > In short, the branch improved the evaluation of tags and the<br>> > creation of the NOD file.<br>> ><br>> > Gerd<br>> ><br>> ><br>> > ------------------------------------------------------------------------<br>> > Date: Wed, 7 May 2014 11:29:10 +0200<br>> > From: extremecarver@gmail.com <mailto:extremecarver@gmail.com><br>> > To: mkgmap-dev@lists.mkgmap.org.uk<br>> > <mailto:mkgmap-dev@lists.mkgmap.org.uk><br>> > Subject: Re: [mkgmap-dev] splitter r325: improved split algo and new<br>> > option<br>> ><br>> > Well - I'll update all my maps on Thursday again, to recheck. Maybe<br>> > it has to do with increasing-maxnodes? Though I thought the higher<br>> > the max-nodes, the faster...<br>> > And I only meant splitter. I upgraded mkgmap at the same time (now<br>> > integrating performance branch changes) - so mkgmap by itself got<br>> > faster (though it depends on the country - seems like well mapped<br>> > countries profit a lot more (e.g. Austria like 30% time off), than<br>> > countries where few continue commands will be in action cause their<br>> > mapping is basic like Asia).<br>> ><br>> > I'm not using any pre-split files or cached files of any sort either...<br>> > On 07.05.2014 06:49, Gerd Petermann wrote:<br>> ><br>> > Hi Felix,<br>> ><br>> > reg. speed: I can't reproduce that. I compared a split of Germany,<br>> > both versions (r321 and r325) are more or less running the same<br>> > time.<br>> > (I've executed both programs two times to make sure that disk<br>> > caches<br>> > are not causing big differences)<br>> ><br>> > Or did you mean the combination of splitter + mkgmap to process<br>> > e.g. Asia?<br>> ><br>> > Gerd<br>> ><br>> > ------------------------------------------------------------------------<br>> > Date: Tue, 6 May 2014 18:22:00 +0200<br>> > From: extremecarver@gmail.com <mailto:extremecarver@gmail.com><br>> > To: mkgmap-dev@lists.mkgmap.org.uk<br>> > <mailto:mkgmap-dev@lists.mkgmap.org.uk><br>> > Subject: Re: [mkgmap-dev] splitter r325: improved split algo and<br>> > new option<br>> ><br>> > Seems to be much better now. I don't think I can increase the<br>> > max-nodes value though, but for most maps the new algo creates<br>> > less tiles for the same max-nodes value (e.g. Austria from 43<br>> > down to 35 for me, with the smallest tile now around 5MB instead<br>> > of 2.8, and the biggest 12MB instead of 11MB, for Asia I<br>> > simultaneously increased max-nodes from 800k to 900k- so I'm<br>> > down from 624 tiles to 493.... and size from 970KB-16MB to now<br>> > ). So it still seems to depend on the country, but it's already<br>> > a lot better...<br>> > It's a bit slower (about 10% more time)<br>> ><br>> > On 06.05.2014 13:56, Gerd Petermann wrote:<br>> ><br>> > Hi all,<br>> ><br>> > I've applied num-tiles-v1.patch and improved the split<br>> > algo, see<br>> > http://gis.19327.n5.nabble.com/mkgmap-ToDo-list-tp5803388p5805165.html<br>> ><br>> ><br>> > It is now less likely that splitter creates tiles with a low<br>> > number of<br>> > nodes, it is more likely that all tiles have nearly the same<br>> > number of nodes,<br>> > and typically you will see fewer tiles.<br>> > Maybe this also means that you can increase the max-nodes value.<br>> ><br>> > I hope this also reduces the need for complex interactions<br>> > between<br>> > spltter and mkgmap.<br>> ><br>> ><br>> ><br>> > Gerd<br>> ><br>> ><br>> > _______________________________________________<br>> > mkgmap-dev mailing list<br>> > mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><br>> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> ><br>> ><br>> > --<br>> > keep on biking and discovering new trails<br>> ><br>> > Felix<br>> > openmtbmap.org &www.velomap.org <http://www.velomap.org><br>> ><br>> ><br>> > _______________________________________________ mkgmap-dev<br>> > mailing list mkgmap-dev@lists.mkgmap.org.uk<br>> > <mailto:mkgmap-dev@lists.mkgmap.org.uk><br>> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> ><br>> ><br>> > _______________________________________________<br>> > mkgmap-dev mailing list<br>> > mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><br>> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> ><br>> ><br>> > --<br>> > keep on biking and discovering new trails<br>> ><br>> > Felix<br>> > openmtbmap.org &www.velomap.org <http://www.velomap.org><br>> ><br>> ><br>> > _______________________________________________ mkgmap-dev mailing<br>> > list mkgmap-dev@lists.mkgmap.org.uk<br>> > <mailto:mkgmap-dev@lists.mkgmap.org.uk><br>> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> ><br>> ><br>> > _______________________________________________<br>> > mkgmap-dev mailing list<br>> > mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><br>> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> ><br>> ><br>> > --<br>> > keep on biking and discovering new trails<br>> ><br>> > Felix<br>> > openmtbmap.org &www.velomap.org <http://www.velomap.org><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>> ><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>> _______________________________________________<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>