<html>
<head>
</head>
<body class='hmmessage'><div dir='ltr'>
<div dir="ltr">
<div dir="ltr">
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
<div dir="ltr">Hi all,<br><br>the last months brought a lot of improvements, but there is still a lot to do:<br>Before summer I only plan to improve readability/stability and maybe performance of code:<ol><ol><li>use one internal representation for vehicles (mkgmap:car, mkgmap:bicycle,...)<br>and only translate it to the img format when writing</li><li>Create a new class that combines a converted Way, the reference to the GType,<br>and fields required for the creation of MapRoad objects.<br>I think ConvertedWay is a good name for this. This should be used <br>in StyledConverter, WrongAngleFixer, and RoadMerger.</li><li>The RuleIndex might be a lot faster if we search for keys first and in a 2nd step for values.<br>This would avoid millions of temporary StringBuilder objects.<br></li></ol></ol><br>Other ideas that should not be forgotton:<br><ul><li>improve handling of motor_vehicle=* and vehicle=* in default style <br>(WanMil and Mario Hantschke are working on that)<br></li><li>manage drive-on-left/drive-on-right in resources\LocatorConfig.xml</li><li>detect sharp angles at road junctions and either change the heading values or <br>add small arcs</li><li>conditional includes in style files and/or if else statements<br></li><li>error handling : set non-zero return code if the map (or at least one tile) is not usable</li><li>improve reader for polish input data: correct handling of mulitple DATAx lines <br></li><li>rewrite MapSplitter so that overlaps are kept small. This should improve rendering speed <br>in the devices. <br></li><li>rewrite classes that hold information about map objects, esp. shapes. Idea:<br><ul><li>store information about outer way and holes as lists of points, similar to mp-relations</li><li>implement methods that return the simplified object for a given resolution. <br>If the area enclosed by the outer line is not visible at resolution x, ignore the object.<br>If a hole is not visible at resolution x, ignore it. <br>If both are visible, connect the simplified outer and inner lines so that holes are<br>displayed in the map. This should all be doable without complex area operations.</li></ul><ul><li>merge shapes before splitting the map into sub areas</li><li>optimize wrong angles in shapes with the same algo that is used for lines<br></li></ul>Expected result: fewer and less distorted shapes, smaller img file.<br></li></ul><br>The order of the 2nd list represents my assumption regarding complexity, not importance. I think the last 3 (bold) points<br>can only be done together, but I'd like to be proven wrong.<br><br>Is something important missing?<br><br>@Steve: Maybe we should keep this list somewhere at <a href="http://www.mkgmap.org.uk/" target="_blank">http://www.mkgmap.org.uk/</a> and try to maintain it?<br><br>Gerd<br><br></div>
</div>
</div>
</div></body>
</html>