[mkgmap-dev] Unit tests in trunk fail

Sun Jan 5 16:50:05 GMT 2014

Hi Gerd,

> 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?

I don't think so. The test depends on the element order no matter if it 
uses lines or points. So the same problem might occur if it uses points.

>
> 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?

I will have a detailed look on it later.
Maybe there is still a bug in the RoadMerger with merging of oneway 
roads. As far as I have understood the patch normalizes the oneway 
tagging before RoadMerger is started. Of course this makes it easier and 
is therefore a good thing :-)

WanMil

>
> 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
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>