logo separator

[mkgmap-dev] New splitter version available

From Paul news at pointdee.co.uk on Sat Aug 8 10:54:16 BST 2009

Using todays great_britain.osm from the geofabrik mirror and with
splitter-r39 I got

real    2m24.954s
user    2m10.584s
sys     0m3.760s

Using splitter-r61 I got

real    2m15.107s
user    2m3.852s
sys     0m3.748s

The previous warnings about a way being in too many areas have
disappeared and the map seemed to compile without any errors but I can't
say that I've tested it other than locally

Cheers

Paul

Chris Miller wrote:
> I've checked in some more updates to the splitter. You can either check it 
> out of Subversion and build it yourself, or download a copy from http://redyeti.net/splitter.jar.
> 
> Here's what's new/changed:
> 
> - Removed the 4 areas per way restriction. Now all ways will be split correctly 
> regardless of how many areas they are in.
> - Added a --max-areas parameter. This allows you to trade off speed against 
> memory usage.
> - Improved the logging to make it clearer what is happening, and to provide 
> feedback of progress during the split.
> - The default ant target is now 'dist'.
> - A couple of minor performance improvements.
> 
> Some further explanation of --max-areas is probably required. By default 
> this is set to 255, meaning that up to 255 areas will be processed on a single 
> pass over the XML when splitting. However if your map is going to split into 
> say 387 areas, rather than doing one pass of 255 areas and a second of 132 
> the splitter will balance the passes at 184 and 183 areas each. This is because 
> the amount of memory used by a given pass is proportional to the number of 
> areas being processed multiplied by --max-nodes, so the lower the number 
> of areas for a given pass the better. There is no performance cost associated 
> with this balancing.
> 
> As for the 4 areas per way restriction... I managed to come up with a way 
> to handle the few ways that exceed this limit with some special-case code. 
> There is a slight performance and memory cost associated with this, but with 
> the current data it is negligible. If in the futher there end up being a 
> huge number of ways covering more than 4 areas we might have to rethink how 
> this works, but for the medium term at least I think we'll be fine.
> 
> As always, please give this new version a try and let me know what you think 
> or have any problems/questions.
> 
> Chris
> 
> 
> 
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 





More information about the mkgmap-dev mailing list