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: [email protected]
To: [email protected]
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: [email protected]
> To: [email protected]
> 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
> > [email protected]
> >http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >
>
> _______________________________________________
> mkgmap-dev mailing list
> [email protected]
>http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
