okay, regarding performance I think it makes no sense to use a small max-areas value. The rule seems to be simple: The more passes, the longer the run time.
On the other hand, it would be good to know that the results are exactly the same (same problem-list, same *.osm.gz, same areas.list). I've never tested that with planet, only
with small areas.
Date: Fri, 30 Nov 2012 19:57:47 +0100
From: osm@na1400.info
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] splitter r247
Maybe because I forgot to change the -max-areas setting the split
took a lot longer then expected. It even did not finish yet. CPU
usage is around 1 to 4% now, this doesn't look good. I've attached
the log.
The commandline I used was:
java -agentlib:hprof=cpu=samples,depth=20
-XX:-HeapDumpOnOutOfMemoryError -XX:+PrintGCTimeStamps
-XX:+PrintGCDetails -Xmx6000m -jar splitter.jar --output=xml
--keep-complete --overlap=0 --no-trim --mapid=1 --max-nodes=1500000
--max-areas=512 --write-kml=initial.kml
--geonames-file=cities15000.zip planet-latest.osm.pbf
I'll start the split again using --max-areas=2048
On 30-11-12 01:53, GerdP wrote:
>
> The results were ok, only runtime and memory usage was too
high in
> your case. r250 corrects this.
>
> If you want to provide new logs, please run this version with
java
> -agentlib:hprof=cpu=samples,depth=20
-XX:-HeapDumpOnOutOfMemoryError
> -XX:+PrintGCTimeStamps +PrintGCDetails -Xmx6000m -jar
splitter.jar
> .... --max-areas=2048
>
> This should result in max. 2 hours runtime.
>
> If you want to compare with the previous results, try also
with
> --max-areas=255
>
> Please send me the splitter log and the java.hprof .
>
> Gerd
>
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev