Hi Steve, Steve Ratcliffe wrote
As you've probably seen I've added the program to the display svn as test.svg.subdiv.Main. There is an argument '--level N' to display a different zoom level. Default is 0 (most detailed).
I've found that our OSM maps seem to have a lot more elements than other maps so it is difficult to compare. In general the way we create subdivisions means that many of them are quite large and they contain many elements. There are no small divisions.
Yes, I tried the tool on an OSM map and one from Garmin but the svg is so big and complex that it doesn't help me at this stage. Steve Ratcliffe wrote
If I got it right, the redraw time is influenced by a) how many sub divisions are overlapping a given bbox and b) how many objects are in these sub divisions and c) how complex the objects are (means, how much time it takes to render them)
It is also possible that the way that the divisions on different levels link together may have an effect, as it may be able to restrict the number of divisions it has to consider.
Possible, I don't yet understand how this is used in the device as objects may (dis-)appear at a certain level. Anyhow, I am pretty sure that it doesn't take much time to find the areas which intersect a given rectangle. My first approach to solve the problem was to cut polygons and non-routable lines when a sub div is split, but that doesn't seem to help much (maybe the roads are the reason). Or maybe I did something wrong or looked at an area which doesn't show the problem. Now I wonder if we should collect objects with large bboxes in their own sub divs. A small sub div could be useful in heavily populated areas. I think I first have to code a test routine. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Optimizing-MapSplitter-tp5823702p5824117.html Sent from the Mkgmap Development mailing list archive at Nabble.com.