<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">You can also save your country.o5m
files from one use to the next and then use osmupdate to update
them. This way you don't have to download from Geofabrik and
convert from pbf to o5m.<br>
<br>
El 07/05/14 11:59, Gerd Petermann escribió:<br>
</div>
<blockquote cite="mid:DUB112-W7238C887201428F9AB53779E4E0@phx.gbl"
type="cite">
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
<div dir="ltr">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>
<div>
<hr id="stopSpelling">Date: Wed, 7 May 2014 11:37:58 +0200<br>
From: <a class="moz-txt-link-abbreviated" href="mailto:extremecarver@gmail.com">extremecarver@gmail.com</a><br>
To: <a class="moz-txt-link-abbreviated" href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a><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 hand it over to splitter...<br>
Actually I also let splitter output pbf... Maybe I could
change that in future to 05m..<br>
<div class="ecxmoz-cite-prefix">On 07.05.2014 11:36, Gerd
Petermann wrote:<br>
</div>
<blockquote
cite="mid:DUB112-W144294AF4FCD19988D46539E4E0@phx.gbl">
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">Hi Felix,<br>
<br>
well, nowadays splitter performance mostly depends on I/O
if you use 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 creation of the NOD file.<br>
<br>
Gerd<br>
<br>
<br>
<div>
<hr id="ecxstopSpelling">Date: Wed, 7 May 2014 11:29:10
+0200<br>
From: <a moz-do-not-send="true"
class="ecxmoz-txt-link-abbreviated"
href="mailto:extremecarver@gmail.com">extremecarver@gmail.com</a><br>
To: <a moz-do-not-send="true"
class="ecxmoz-txt-link-abbreviated"
href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a><br>
Subject: Re: [mkgmap-dev] splitter r325: improved split
algo and new option<br>
<br>
Well - I'll update all my maps on Thursday again, to
recheck. Maybe it has to do with increasing-maxnodes?
Though I thought the higher the max-nodes, the faster...<br>
And I only meant splitter. I upgraded mkgmap at the same
time (now integrating performance branch changes) - so
mkgmap by itself got faster (though it depends on the
country - seems like well mapped countries profit a lot
more (e.g. Austria like 30% time off), than countries
where few continue commands will be in action cause
their mapping is basic like Asia).<br>
<br>
I'm not using any pre-split files or cached files of any
sort either...<br>
<div class="ecxmoz-cite-prefix">On 07.05.2014 06:49,
Gerd Petermann wrote:<br>
</div>
<blockquote
cite="mid:DUB112-W46EB8056828BFF004A1CD09E4E0@phx.gbl">
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">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 time.<br>
(I've executed both programs two times to make sure
that disk caches <br>
are not causing big differences)<br>
<br>
Or did you mean the combination of splitter + mkgmap
to process e.g. Asia?<br>
<br>
Gerd<br>
<br>
<div>
<hr id="ecxstopSpelling">Date: Tue, 6 May 2014
18:22:00 +0200<br>
From: <a moz-do-not-send="true"
class="ecxmoz-txt-link-abbreviated"
href="mailto:extremecarver@gmail.com">extremecarver@gmail.com</a><br>
To: <a moz-do-not-send="true"
class="ecxmoz-txt-link-abbreviated"
href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a><br>
Subject: Re: [mkgmap-dev] splitter r325: improved
split algo and new option<br>
<br>
Seems to be much better now. I don't think I can
increase the max-nodes value though, but for most
maps the new algo creates less tiles for the same
max-nodes value (e.g. Austria from 43 down to 35
for me, with the smallest tile now around 5MB
instead of 2.8, and the biggest 12MB instead of
11MB, for Asia I simultaneously increased
max-nodes from 800k to 900k- so I'm down from 624
tiles to 493.... and size from 970KB-16MB to now
). So it still seems to depend on the country, but
it's already a lot better...<br>
It's a bit slower (about 10% more time) <br>
<br>
<div class="ecxmoz-cite-prefix">On 06.05.2014
13:56, Gerd Petermann wrote:<br>
</div>
<blockquote
cite="mid:DUB112-W111F5858AD65083970BEE389E4F0@phx.gbl">
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">Hi all,<br>
<br>
I've applied num-tiles-v1.patch and improved
the split algo, see<br>
<a moz-do-not-send="true"
href="http://gis.19327.n5.nabble.com/mkgmap-ToDo-list-tp5803388p5805165.html"
target="_blank">http://gis.19327.n5.nabble.com/mkgmap-ToDo-list-tp5803388p5805165.html</a><br>
<br>
<br>
It is now less likely that splitter creates
tiles with a low number of <br>
nodes, it is more likely that all tiles have
nearly the same 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 between <br>
spltter and mkgmap.<br>
<br>
<br>
<br>
Gerd<br>
</div>
<br>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>