logo separator

[mkgmap-dev] Unit tests in trunk fail

From Gerd Petermann gpetermann_muenchen at hotmail.com on Sun Jan 5 15:56:44 GMT 2014

Hi WanMil,

yes, looks better, and now I understand that the finalizer test depends on the order 
of ways. Maybe it would be better to use points for these tests?

Please review also the attached patch. I think it allows to simplify the oneway
handling in RoadMerger. Do you have an idea why it changes the 
number of merged roads?

With my additional patch I see this additional merge message:
Road 5066755 and road 26338423 are mergeable with angle 108.93699330523285

Gerd

Date: Sun, 5 Jan 2014 15:53:28 +0100
From: wmgcnfg at web.de
To: mkgmap-dev at lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Unit tests in trunk fail

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

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20140105/b99a9c2e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: deadendcheck_trunk_v5.patch
Type: application/octet-stream
Size: 12522 bytes
Desc: not available
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20140105/b99a9c2e/attachment-0001.obj>


More information about the mkgmap-dev mailing list