
On 03-05-11 20:01, Marko Mäkelä wrote:
On Tue, May 03, 2011 at 05:48:55PM +0200, Lambertus wrote: I assume that GC means garbage collection. Which JVM are you using? An educated guess is that the memory runs out and a "full garbage collection" cycle is started as a last resort.
Ok, "Garbage Collection" sounds reasonable, but I gave Java 7.5 GB heap space while it used only a few hundred megabytes. I've got no idea why it would run out of memory. java version "1.6.0_24" Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
- Is input from stdin still functional/supported for splitter? I am not sure. I am using pbf output.
Yeah, I'm slow in moving to pbf, but is OSM XML really not functional/supported anymore? Splitter seems to accept the XML in the first phase without complaints. It's only in the step where it starts to write-out the tiles that is starts to complain. It would be better if Splitter rejects the input if it can't handle it properly later on?
Why not use
osmosis --rb world.osm.pbf ... --wb filtered-world.osm.pbf
and
... splitter.jar filtered-world.osm.pbf
Well I wanted to run multiple processes at the same time to utilize the quadcore CPU better and reduce processing time (but, then I shouldn't have used bz2 XML in the first place). Ok, I'll try this next.
I am not sure if the --cache option still works. It was sort of superceded or made unnecessary by the Protobuf input format support.
Oh, if it's not working anymore then I assume it will ignore the option. Or is this too simple thinking? Thanks for the response Marko. I'll start a new run using Osmosis pbf output.