[mkgmap-dev] Binary format update

Thu Sep 16 22:37:33 BST 2010

>
> 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;
	}