[mkgmap-dev] FW: Splitter defaulting on Japan
From Gerd Petermann gpetermann_muenchen at hotmail.com on Sat May 31 07:58:27 BST 2014
Hi Felix, reg. Antarctica : It doesn't crash with the options that you use for japan. Do you use different options for this area? Gerd Date: Sat, 31 May 2014 08:48:19 +0200 From: extremecarver at gmail.com To: mkgmap-dev at lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] FW: Splitter defaulting on Japan well - anything is better than the current crash. Maybe just a rerun with "safe" options added? Please also look on Antarctica extract by geofabrik. I didn't find time yet to test it again why it crashed... Or is search-limit that option what I am looking for? I so far didn't know about this new switch at all... On 31.05.2014 08:33, Gerd Petermann wrote: Hi Felix, it seems that the default --search-limit is too low for japan with sea data. With --search-limit=5000000 I see a very good split after ~30 seconds: 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 For many other input files, this will just increase run time a lot. I am not very happy with this option. I think I will replace it with something more useful like --wanted-fill-ratio=90 which means try to find a solution where the least populated tile has 90% of max-nodes. The problem is that some areas do not allow such a good result, so I am still looking for good criteria to stop the search, maybe I'll use the overall search time in seconds: --max-search-time=60 would use the best result found after 60 seconds. Any other ideas? Gerd From: gpetermann_muenchen at hotmail.com To: mkgmap-dev at lists.mkgmap.org.uk Date: Sat, 31 May 2014 08:21:43 +0200 Subject: [mkgmap-dev] FW: Splitter defaulting on Japan From: gpetermann_muenchen at hotmail.com To: extremecarver at gmail.com Subject: RE: [mkgmap-dev] Splitter defaulting on Japan Date: Sat, 31 May 2014 08:17:31 +0200 Hi Felix, thanks for reporting. I can reproduce the problem. It disappears when you remove the --precomp-sea option. I'll try to find out why. > Where is the log saved? Do I need to provide it? Splitter not fully up This message is printed to stderr for the case that you pipe stdout to a file like this: java -jar splitter .... > splitter.log Gerd > Date: Sat, 31 May 2014 05:33:06 +0200 > From: extremecarver at gmail.com > To: mkgmap-dev at lists.mkgmap.org.uk > Subject: [mkgmap-dev] Splitter defaulting on Japan > > Failed to calculate areas. See log for details. > > Where is the log saved? Do I need to provide it? Splitter not fully up > to date - see compiled date (svn update just before)... > I'll retry with up to date splitter still... > > c:\OpenMTBMap\maps>java -Xmx9600m -jar c:\openmtbmap\splitter.jar > --precomp-sea=c:\openmtbmap\maps\sea.zip --max-nodes=1200000 > --output=pbf "--keep-complete" --max-areas=255 > --geonames-file=cities5000 --description=japan --mapid=65590000 c:\OpenMTBMa > p\osmpbf_geofabrik\japan.o5m > Splitter version unknown compiled 2014-05-28T18:16:29+0200 > boundary-tags=use-exclude-list > cache= > description=japan > geonames-file=cities5000 > keep-complete=true > mapid=65590000 > max-areas=255 > max-nodes=1200000 > max-threads=8 (auto) > mixed=false > no-trim=false > num-tiles= > output=pbf > output-dir= > overlap=auto > polygon-desc-file= > polygon-file= > precomp-sea=c:\openmtbmap\maps\sea.zip > problem-file= > problem-report= > resolution=13 > search-limit=1000000 > split-file= > status-freq=120 > stop-after=dist > write-kml= > Elapsed time: 0s Memory: Current 184MB (2MB used, 182MB free) Max 8533MB > Time started: Sat May 31 02:40:37 CEST 2014 > Map is being split for resolution 13: > - area boundaries are aligned to 0x800 map units (0.0439453125 degrees) > - areas are multiples of 0x800 map units wide and high > Processing c:\OpenMTBMap\osmpbf_geofabrik\japan.o5m > Bounding box 122.56070000000001 20.08228 154.4709 45.80245 > 10'000'000 nodes processed... id=752184948 > 20'000'000 nodes processed... id=922482748 > 30'000'000 nodes processed... id=1233696234 > 40'000'000 nodes processed... id=1315824764 > 50'000'000 nodes processed... id=1421002430 > 60'000'000 nodes processed... id=1497506798 > 70'000'000 nodes processed... id=1751094845 > 80'000'000 nodes processed... id=2040104150 > 90'000'000 nodes processed... id=2350328457 > in 1 file > Time: Sat May 31 02:41:01 CEST 2014 > Counting nodes of precompiled sea data ... > Bounding box 144.84375 19.6875 145.546875 20.390625 > Bounding box 135.703124999 20.390625 136.406249999 21.09375 > Bounding box 144.84375 20.390625 145.546875 21.09375 > Bounding box 122.34375000000001 23.90625 123.04687499900001 24.609375 > > > ........ > cut away here... > ....... > Bounding box 142.734375 45.703125 143.4375 46.40625 > Bounding box 143.4375 45.703125 144.140625 46.40625 > Bounding box 149.0625 45.703125 149.765625 46.40625 > Bounding box 149.765625 45.703125 150.46875 46.40625 > Bounding box 150.46875 45.703125 151.171875 46.40625 > Added 835594 nodes from precompiled sea data. > Precompiled sea data pass took 1797 ms > Exact map coverage is (20.08227825164795,122.56068706512451) to > (45.80243110656738,154.47088479995728) > Rounded map coverage is (20.0390625,122.51953125) to > (45.8349609375,154.51171875) > Splitting nodes into areas containing a maximum of 1'200'000 nodes each... > Highest node count in a single grid element is 205'139 > Trying to find nice split for (20.0390625,122.51953125) to > (45.8349609375,154.51171875) with 98'482'055 nodes > searching for split with min-nodes 12000, learned 0 good partial solutions > Split was not yet succesfull. Trying to remove large empty areas... > Trying again with 1 trimmed partition(s), also allowing big empty parts. > Solving partition (23.818359375,122.6953125) to > (45.8349609375,153.0615234375) with 98'482'055 nodes > Trying to find nice split for (23.818359375,122.6953125) to > (45.8349609375,153.0615234375) with 98'482'055 nodes > searching for split with min-nodes 12000, learned 0 good partial solutions > Warning: No solution found for partition (23.818359375,122.6953125) to > (45.8349609375,153.0615234375) with 98'482'055 nodes > Final solution has 0 tile(s). The smallest node count is > 9223372036854775807 (0 %), the worst aspect ratio is near -1.0 > Failed to calculate areas. See log for details. > Failed to calculate areas. > Sorry. Cannot split the file without creating huge, almost empty, tiles. > Please specify a bounding polygon with the --polygon-file parameter. > Time finished: Sat May 31 02:41:04 CEST 2014 > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev at lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev at lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev at lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev at lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20140531/bd2adab7/attachment-0001.html>
- Previous message: [mkgmap-dev] FW: Splitter defaulting on Japan
- Next message: [mkgmap-dev] FW: Splitter defaulting on Japan
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list