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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev