[mkgmap-dev] highway count not fixed yet... - merge-roads-branch

Sun Sep 29 12:30:45 BST 2013

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 at web.de
> To: mkgmap-dev at 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 at lists.mkgmap.org.uk
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20130929/8ac9c69a/attachment.html 