<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>it took a while to analyse many special cases, but today I've committed r2839.<br><br>Compared to trunk you should see:<br>- better routing results because bearing values are calculated using the high precision <br>values of coordinates.<br>- fewer optical errors caused by rounding, e.g. ugly roundabouts or havy zig-zagging <br>lines in the img when OSM data shows an almost straight line<br>- smaller img file size because many obsolete points are removed<br>- slightly higher peak memory usage, else not much difference in throughput<br><br>Wrong angles are corrected by either moving the displayed points a little bit or<br>by removing them. In some cases, points are merged as in the old <br>short-arc-removal process, but with improvements:<br>- if a way has only two points, the algo tries to keep that way in favor to<br>a wrong angle in the img (else routing would be changed in favor to optic)<br>- very close exit points on a roundabout are kept if possible (to avoid wrong<br>"leave roundabout at"&nbsp; messages<br><br>Up to now the changes are calculated for routable ways. In a second step,<br>non-routable ways (not shapes) sharing modified points are modified as well.<br>This is useful for those users who create styles for biking.<br><br>The code needs a bit of review, but I think the result is very good now.<br><br>Next on my todo list:<br>1) Change the implementation of the --link-pois-to-ways feature. Current <br>implementation is too complex. Maybe it doesn't work at all now.<br>@WanMil: Or do you already work on it?<br>2) Implement the merge-shape feature.<br><br>Gerd<br>                                               </div></body>
</html>