<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 Felix,<br><br>it seems that the default --search-limit is too low for japan with sea data.<br>With --search-limit=5000000 I see a very good split after ~30 seconds:<br>Solution is nice. Can't find a better solution: 86 tile(s). The smallest node count is 1111027 (92 %), the worst aspect ratio is near 3.94<br><br>For many other input files, this will just increase run time a lot.<br><br>I am not very happy with this option. I think I will replace it<br>with something more useful like<br>--wanted-fill-ratio=90<br>which means try to find a solution where the least populated<br>tile has 90% of max-nodes.<br><br>The problem is that some areas do not allow such a good result,<br>so I am still looking for good criteria to stop the search, maybe<br>I'll use the overall search time in seconds:<br>--max-search-time=60<br>would use the best result found after 60 seconds.<br><br>Any other ideas?<br><br>Gerd<br><br><br><div><hr id="stopSpelling">From: gpetermann_muenchen@hotmail.com<br>To: mkgmap-dev@lists.mkgmap.org.uk<br>Date: Sat, 31 May 2014 08:21:43 +0200<br>Subject: [mkgmap-dev] FW:  Splitter defaulting on Japan<br><br>

<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}

.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}

--></style>
<div dir="ltr"><br><br><div><hr id="ecxstopSpelling">From: gpetermann_muenchen@hotmail.com<br>To: extremecarver@gmail.com<br>Subject: RE: [mkgmap-dev] Splitter defaulting on Japan<br>Date: Sat, 31 May 2014 08:17:31 +0200<br><br>

<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}

.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}


--></style>
<div dir="ltr">Hi Felix,<br><br>thanks for reporting. I can reproduce the problem. It disappears when<br>you remove the --precomp-sea option.<br>I'll try to find out why.<br><br>&gt; Where is the log saved? Do I need to provide it? Splitter not fully up <br>This message is printed to stderr for the case that you pipe stdout to a file like this:<br>java -jar splitter ....&nbsp;&nbsp; &gt; splitter.log<br><br>Gerd<br><br><div>&gt; Date: Sat, 31 May 2014 05:33:06 +0200<br>&gt; From: extremecarver@gmail.com<br>&gt; To: mkgmap-dev@lists.mkgmap.org.uk<br>&gt; Subject: [mkgmap-dev] Splitter defaulting on Japan<br>&gt; <br>&gt; Failed to calculate areas. See log for details.<br>&gt; <br>&gt; Where is the log saved? Do I need to provide it? Splitter not fully up <br>&gt; to date - see compiled date (svn update just before)...<br>&gt; I'll retry with up to date splitter still...<br>&gt; <br>&gt; c:\OpenMTBMap\maps&gt;java -Xmx9600m -jar c:\openmtbmap\splitter.jar <br>&gt; --precomp-sea=c:\openmtbmap\maps\sea.zip --max-nodes=1200000 <br>&gt; --output=pbf "--keep-complete" --max-areas=255 <br>&gt; --geonames-file=cities5000 --description=japan --mapid=65590000 c:\OpenMTBMa<br>&gt; p\osmpbf_geofabrik\japan.o5m<br>&gt; Splitter version unknown compiled 2014-05-28T18:16:29+0200<br>&gt; boundary-tags=use-exclude-list<br>&gt; cache=<br>&gt; description=japan<br>&gt; geonames-file=cities5000<br>&gt; keep-complete=true<br>&gt; mapid=65590000<br>&gt; max-areas=255<br>&gt; max-nodes=1200000<br>&gt; max-threads=8 (auto)<br>&gt; mixed=false<br>&gt; no-trim=false<br>&gt; num-tiles=<br>&gt; output=pbf<br>&gt; output-dir=<br>&gt; overlap=auto<br>&gt; polygon-desc-file=<br>&gt; polygon-file=<br>&gt; precomp-sea=c:\openmtbmap\maps\sea.zip<br>&gt; problem-file=<br>&gt; problem-report=<br>&gt; resolution=13<br>&gt; search-limit=1000000<br>&gt; split-file=<br>&gt; status-freq=120<br>&gt; stop-after=dist<br>&gt; write-kml=<br>&gt; Elapsed time: 0s   Memory: Current 184MB (2MB used, 182MB free) Max 8533MB<br>&gt; Time started: Sat May 31 02:40:37 CEST 2014<br>&gt; Map is being split for resolution 13:<br>&gt;   - area boundaries are aligned to 0x800 map units (0.0439453125 degrees)<br>&gt;   - areas are multiples of 0x800 map units wide and high<br>&gt; Processing c:\OpenMTBMap\osmpbf_geofabrik\japan.o5m<br>&gt; Bounding box 122.56070000000001 20.08228 154.4709 45.80245<br>&gt; 10'000'000 nodes processed... id=752184948<br>&gt; 20'000'000 nodes processed... id=922482748<br>&gt; 30'000'000 nodes processed... id=1233696234<br>&gt; 40'000'000 nodes processed... id=1315824764<br>&gt; 50'000'000 nodes processed... id=1421002430<br>&gt; 60'000'000 nodes processed... id=1497506798<br>&gt; 70'000'000 nodes processed... id=1751094845<br>&gt; 80'000'000 nodes processed... id=2040104150<br>&gt; 90'000'000 nodes processed... id=2350328457<br>&gt; in 1 file<br>&gt; Time: Sat May 31 02:41:01 CEST 2014<br>&gt; Counting nodes of precompiled sea data ...<br>&gt; Bounding box 144.84375 19.6875 145.546875 20.390625<br>&gt; Bounding box 135.703124999 20.390625 136.406249999 21.09375<br>&gt; Bounding box 144.84375 20.390625 145.546875 21.09375<br>&gt; Bounding box 122.34375000000001 23.90625 123.04687499900001 24.609375<br>&gt; <br>&gt; <br>&gt; ........<br>&gt; cut away here...<br>&gt; .......<br>&gt; Bounding box 142.734375 45.703125 143.4375 46.40625<br>&gt; Bounding box 143.4375 45.703125 144.140625 46.40625<br>&gt; Bounding box 149.0625 45.703125 149.765625 46.40625<br>&gt; Bounding box 149.765625 45.703125 150.46875 46.40625<br>&gt; Bounding box 150.46875 45.703125 151.171875 46.40625<br>&gt; Added 835594 nodes from precompiled sea data.<br>&gt; Precompiled sea data pass took 1797 ms<br>&gt; Exact map coverage is (20.08227825164795,122.56068706512451) to <br>&gt; (45.80243110656738,154.47088479995728)<br>&gt; Rounded map coverage is (20.0390625,122.51953125) to <br>&gt; (45.8349609375,154.51171875)<br>&gt; Splitting nodes into areas containing a maximum of 1'200'000 nodes each...<br>&gt; Highest node count in a single grid element is 205'139<br>&gt; Trying to find nice split for (20.0390625,122.51953125) to <br>&gt; (45.8349609375,154.51171875) with 98'482'055 nodes<br>&gt; searching for split with min-nodes 12000, learned 0 good partial solutions<br>&gt; Split was not yet succesfull. Trying to remove large empty areas...<br>&gt; Trying again with 1 trimmed partition(s), also allowing big empty parts.<br>&gt; Solving partition (23.818359375,122.6953125) to <br>&gt; (45.8349609375,153.0615234375) with 98'482'055 nodes<br>&gt; Trying to find nice split for (23.818359375,122.6953125) to <br>&gt; (45.8349609375,153.0615234375) with 98'482'055 nodes<br>&gt; searching for split with min-nodes 12000, learned 0 good partial solutions<br>&gt; Warning: No solution found for partition (23.818359375,122.6953125) to <br>&gt; (45.8349609375,153.0615234375) with 98'482'055 nodes<br>&gt; Final solution has 0 tile(s). The smallest node count is <br>&gt; 9223372036854775807 (0 %), the worst aspect ratio is near -1.0<br>&gt; Failed to calculate areas. See log for details.<br>&gt; Failed to calculate areas.<br>&gt; Sorry. Cannot split the file without creating huge, almost empty, tiles.<br>&gt; Please specify a bounding polygon with the --polygon-file parameter.<br>&gt; Time finished: Sat May 31 02:41:04 CEST 2014<br>&gt; _______________________________________________<br>&gt; mkgmap-dev mailing list<br>&gt; mkgmap-dev@lists.mkgmap.org.uk<br>&gt; http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br></div>                                               </div></div>                                               </div>
<br>_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</div>                                               </div></body>
</html>