[mkgmap-dev] Optimizing MapSplitter

Wed Nov 12 17:39:58 GMT 2014

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.