<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 WanMil,<br><br>yes, looks better, and now I understand that the finalizer test depends on the order <br>of ways. Maybe it would be better to use points for these tests?<br><br>Please review also the attached patch. I think it allows to simplify the oneway<br>handling in RoadMerger. Do you have an idea why it changes the <br>number of merged roads?<br><br>With my additional patch I see this additional merge message:<br>Road 5066755 and road 26338423 are mergeable with angle 108.93699330523285<br><br>Gerd<br><br><div>Date: Sun, 5 Jan 2014 15:53:28 +0100<br>From: wmgcnfg@web.de<br>To: mkgmap-dev@lists.mkgmap.org.uk<br>Subject: Re: [mkgmap-dev] Unit tests in trunk fail<br><br><pre>Hi Gerd,<br> <br>attached patch also contains fixes to the junit tests.<br>The performance is at least the same using the patch.<br> <br>If you don't oppose the patch I want to commit it.<br> <br>WanMil<br> <br>> Hi Gerd,<br>><br>> the SimpleTest also randomly fails because the number of resulting lines<br>> is sometimes different.<br>><br>> You are right that the roadmerger does not change the number of lines in<br>> roundabouts. But there are other ways similar to roundabouts:<br>> <a href="http://www.openstreetmap.org/?mlat=51.25946&mlon=6.74760&zoom=17#map=19/51.25990/6.74788" target="_blank">http://www.openstreetmap.org/?mlat=51.25946&mlon=6.74760&zoom=17#map=19/51.25990/6.74788</a><br>><br>> I guess such ways are responsible for different number of lines.<br>><br>> Anyhow I have found a quite easy way to make the RoadMerger stable.<br>> When creating the list of roads I copy all start and end points to a<br>> list. This list is stable. Step by step I go through this list to find<br>> merge candidates. No matter if we allow to merge ways to a closed way<br>> this procedure is stable.<br>> Sorting at the end is still required because the roads are copied from<br>> the IdentityHashMap to the resulting list and this is not stable.<br>><br>> Attached patch also contains the creation of a debugging file at the end<br>> of the RoadMerger.merge procedure. The output contains informations<br>> about the roads which makes it easy to compare two runs of mkgmap.<br>><br>> Please give it a check if that solves your problem. I will have a look<br>> on the tests and if the performance is still acceptable using the patch.<br>><br>> WanMil<br>><br>>> Hi WanMil,<br>>><br>>> it's a unit test regarding the style finalizer section which fails and I<br>>> don't know why.<br>>><br>>> reg. RoadMerger:<br>>> it makes no sense to create closed ways because we would split them<br>>> again later in StyledConverter.<br>>> I don't understand the idea about roundabouts.<br>>> If one is divided into 4 parts you can do 2 merges without closing it,<br>>> no matter which<br>>> parts you connect first, and you should always get 2 remaining parts.<br>>> Assumes part a,b,c and d:<br>>> a+b and c+d or<br>>> a+b and a_b + c or<br>>> b+c and d+a or<br>>> b+c and b_c + d or<br>>> b+c and a + b_c or<br>>> ...<br>>><br>>> Gerd<br>>><br>>> > Date: Sun, 5 Jan 2014 12:37:09 +0100<br>>> > From: wmgcnfg@web.de<br>>> > To: mkgmap-dev@lists.mkgmap.org.uk<br>>> > Subject: Re: [mkgmap-dev] Unit tests in trunk fail<br>>> ><br>>> > Hi Gerd,<br>>> ><br>>> > I think I found the problem:<br>>> ><br>>> > // check if merging would create a closed way - which should not<br>>> > // be done (why? WanMil)<br>>> > if (cStart == cOtherEnd) {<br>>> > return false;<br>>> > }<br>>> ><br>>> > The RoadMerger avoids to create closed roads. In case the roads are<br>>> not<br>>> > merged in exactly the same order this is the reason for different<br>>> merge<br>>> > results due to roundabouts. In case a roundabout is divided in<br>>> multiple<br>>> > ways the number of merged ways is random.<br>>> ><br>>> > At the moment I have no time to check that more in detail but I think<br>>> > the code listed above can be removed.<br>>> ><br>>> > WanMil<br>>> ><br>>> > > Hi WanMil,<br>>> > ><br>>> > > please have a look, I don't fully understand why.<br>>> > ><br>>> > > Gerd<br>>> > ><br>>> > ><br>>> > > _______________________________________________<br>>> > > mkgmap-dev mailing list<br>>> > > mkgmap-dev@lists.mkgmap.org.uk<br>>> > > <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" target="_blank">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>>> > ><br>>> ><br>>> > _______________________________________________<br>>> > mkgmap-dev mailing list<br>>> > mkgmap-dev@lists.mkgmap.org.uk<br>>> > <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" target="_blank">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>>><br>>><br>>> _______________________________________________<br>>> mkgmap-dev mailing list<br>>> mkgmap-dev@lists.mkgmap.org.uk<br>>> <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" target="_blank">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>>><br>><br>><br>><br>> _______________________________________________<br>> mkgmap-dev mailing list<br>> mkgmap-dev@lists.mkgmap.org.uk<br>> <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" target="_blank">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>><br> <br></pre><br>_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</div> </div></body>
</html>