Ok, that means we cannot use the common planet dumps for this and a separate step (geographical sorting) is needed which maybe eats up the advantage to skip the tile splitter step. Just keep the idea in mind and give it a try when the geographical sorting is available.
I designed the format to support that feature, but I have no idea when, or if, I'll have time to program it. One advantage is that the sorting process only has to be done once.
I've got a question though, why can't mkgmap generate different areas in parallel? It seems like it should be possible and it would make it a lot faster to render maps.
mkgmap already works in parallel if you specifiy multiple osm files which are usually generated by the tile splitter (see parameter --max-jobs). The advantage of my idea would be to skip the tile splitter step.
Are you sure? If I try it on a quad-core hyperthreading CPU, I only see about 2-3 cores used and 5 idle. (Invoked with '-c template.args and --max-jobs=10') There's also this code in MapMaker.java: /** * Load up from the file. It is not necessary for the map reader to completely * read the whole file in at once, it could pull in map-features as needed. */ private LoadableMapDataSource loadFromFile(CommandArgs args, String name) throws FileNotFoundException, FormatException { LoadableMapDataSource src; // work around non-reentrancy of GType priority stuff // by serialising the map reading synchronized(MapMaker.class) { src = MapReader.createMapReader(name); src.config(args.getProperties()); log.info("Started loading " + name); src.load(name); log.info("Finished loading " + name); } return src; }