<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 all,<br><br>I think I've now found a solution for most of the known problems<br>reg. address search, for details see svn log:<br><a href="http://www.mkgmap.org.uk/websvn/log.php?repname=mkgmap&amp;path=%2F&amp;rev=3587&amp;isdir=1" target="_blank"><a href="http://www.mkgmap.org.uk/websvn/log.php?repname=mkgmap&amp;isdir=1&amp;" target="_blank">http://www.mkgmap.org.uk/websvn/log.php?repname=mkgmap&amp;isdir=1&amp;</a></a><br><br>The remaining work to do is cleanup and maybe performance<br>improvements, I don't plan any more significant <br>changes in the algorithms as long as nobody complains.<br><br>If you want to try the branch with your style, please make sure <br>to understand the new special tags mkgmap:numbers=false<br>and mkgmap:execute_finalize_rules=true in combination with inc/address.<br><br>Attached is the diff between the default style in the branch and that in trunk.<br>Note that mkgmap uses by default all OSM elements with a tag addr:housenumber<br>or mkgmap:housenumber. Even if the style doesn't create any map object for the <br>element, the numbers are used, so the new tags are used to <br>make sure that the rules in inc/address are used for all of them and<br>to allow the exclusion.<br><br>A few hints:<br>The img files produced with the branch are typically larger, esp. in areas<br>where the trunk version did not work well (e.g. heavy usage of addr:place)<br><br>The throughput is a few percent slower. Main reason is the complex<br>search for nearest roads. Maybe I can find a better algorithm for this in<br>the future.<br><br>It would be great to get some feedback, esp. when you think that<br>rather good / clear OSM data is not interpreted correctly,<br>but also when you think the branch works fine ;-)<br><br>Gerd<br><br><br><br><br><br>                                               </div></body>
</html>