logo separator

[mkgmap-dev] FW: Splitter defaulting on Japan

From Felix Hartmann extremecarver at gmail.com on Sat May 31 15:06:44 BST 2014

newest splitter didn't crash on it anymore... I think the crash was on 
version 396-403... dunno which version I actually used.
So that's fine..
On 31.05.2014 10:28, Gerd Petermann wrote:
> Hi Felix,
>
> okay, please try r409.
> See  also
> http://www.mkgmap.org.uk/websvn/revision.php?repname=splitter&rev=409
>
> 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
>     <mailto:gpetermann_muenchen at hotmail.com>
>     To: mkgmap-dev at lists.mkgmap.org.uk
>     <mailto: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
>     <mailto:gpetermann_muenchen at hotmail.com>
>     To: extremecarver at gmail.com <mailto: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 <mailto:extremecarver at gmail.com>
>     > To: mkgmap-dev at lists.mkgmap.org.uk
>     <mailto: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
>     <mailto: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
>     <mailto: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  <mailto: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/aa69c5ba/attachment-0001.html>


More information about the mkgmap-dev mailing list