
Hi Gerd, I've commited the changes to the merge_road branch. setHighwayCount() still need to be changed. In case the merged road has the same id as the duplicate road you have the same problem again. <<<<<<<<<<< (not counted due to same id) x>>>>>>>>>x>>>>>>>>>>>x 1 1 1 should be <<<<<<<<<<< x>>>>>>>>>x>>>>>>>>>>>x 1 2 2 I still don't understand how you want to check which node is a routing node. It's easy for the first and the last node but how to proceed with the nodes inbetween? WanMil
Hi WanMil,
thanks for the ascii graphics, I think that explains what goes wrong with Felix' style. I still don't see a need to change the setHighwayCount() method as long as we call it after the mergeRoads().
Why don't I like the usage of the highway count? Well, in some places we increment the counter for the 1st and last point of a way and the comment says // make sure the way has nodes at each end If that is really needed, I'd prefer to set a flag instead of messing up the counter.
Gerd
Date: Sun, 29 Sep 2013 13:01:17 +0200 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch
WanMil wrote
Hi Gerd,
in my opinion recalculating the highway counter after removing the short arcs should fix all problems, shouldn't it?
Don't think so. All routines that replace or add points after that must make sure that they maintain the correct highway count.
Ok, which routines perform such modifications? I couldn't find any such modifications of MapRoad instances after the StyledConverter.
WanMil wrote
I've added three changes to the patch: 1. When calculating the highway count ways with duplicate id are not considered. This avoid that all points of a duplicated way are
preserved
by all filters. I think this should be modified a bit. For the first and last point of those ways the highway count should be increased and also all points where another way is connected. I have no use case where this matters but I think it is the "correct" counting?
No, it just increases the possibility that the counter overflows.
Maybe that's true for the trunk but in the branch there are real cases where it matters.
Assume the following two ways:
x>>>>>>>>>x===========x 1 2 1
(x = Node; >> oneway line; === oneway=no; highway count below nodes)
The style might duplicate the oneway=no way into to oneway=yes ways
>>>>>>> x>>>>>>>>>x<<<<<<<<<<<x 1 2 1
The merger might merge two of the ways:
<<<<<<<<<<< x>>>>>>>>>x>>>>>>>>>>>x 1 1 1
As a result the highway count of the 2nd and 3rd node is wrong. It should be 2 instead of 1. And AFAIK this difference matters.
Maybe we should not use this counter at all. The information that it "hides" is that a point connects two or more roads. I think a better solution would be to have a method markRoutingNodes() which uses the counter and sets a bit flag in the coord instance. This routine would replace setHighwayCounts() and resetHighwayCounts().
I don't understand the advantage? I think maintaining the highway count is the same like markRoutingNodes(). How do you want to know when to call markRoutingNodes()?
WanMil wrote
2. I have added the problematic point in the error message of the MapBuilder in case a node is not a CoordNode. Just having the way id might not be enough information and the way also might have been
merged.
3. I have moved the recalculation of the highway counters after the merge procedure. This should not change anything but it avoids a
problem
with merging...
This is a good idea. Maybe do it before and after? That also means that decHighwayCount() is obsolete, doesn't it?
decHighwayCount() is obsolete as long as the highway counters are recalculated after mergeRoads(). When recalculating the highway count after mergeRoads() the RoadMerger does not care about (correct) highway counts (maybe a perf improvement might require correct highway counts but I don't know if the improvement is neccessary).
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev