<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hi Steve,<br><br>I played a little bit with display tool r435.<br>I was not able to display the label in inkSkape.<br>Is there a trick?<br><br>I noticed that my Garmin maps have a rather small<br>avg. number of elements compared to those produced <br>by mkgmap.<br>Up to now I found no simple rule reg. the area size of a sub div<br>and the contained elements.<br><br>Gerd<br><br><div>> Date: Wed, 12 Nov 2014 14:11:29 +0000<br>> From: steve@parabola.me.uk<br>> To: mkgmap-dev@lists.mkgmap.org.uk<br>> Subject: Re: [mkgmap-dev] Optimizing MapSplitter<br>> <br>> <br>> Hi Gerd<br>> <br>> As you've probably seen I've added the program to the display svn<br>> as test.svg.subdiv.Main. There is an argument '--level N' to display<br>> a different zoom level. Default is 0 (most detailed).<br>> <br>> I've found that our OSM maps seem to have a lot more elements than<br>> other maps so it is difficult to compare.<br>> In general the way we create subdivisions means that many of them<br>> are quite large and they contain many elements. There are no<br>> small divisions.<br>> <br>> <br>> <br>> > If I got it right, the redraw time is influenced by<br>> > a) how many sub divisions are overlapping a given bbox and<br>> > b) how many objects are in these sub divisions and<br>> > c) how complex the objects are (means, how much time it takes to render<br>> > them)<br>> <br>> It is also possible that the way that the divisions on different<br>> levels link together may have an effect, as it may be able to<br>> restrict the number of divisions it has to consider.<br>> <br>> ..Steve<br>> <br>> <br>> _______________________________________________<br>> mkgmap-dev mailing list<br>> mkgmap-dev@lists.mkgmap.org.uk<br>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br></div> </div></body>
</html>