Yeah, merging roads if possible would be great. Even more important would however be smoothing of curves. i.e. make serpentine corners on mountain streets more smooth, because otherwise if there is a say 160° corner, it will add a big time penalty, which in a car is more or less correct, but on a bicycle overrated.
However, how do you want to do the merging without loosing attributes (i.e. roadname changes, bridge, etc..), I think this could only work by running after the main processing, and merging everything identical if possible. Otherwise before merging there needs to be a check whether there is not a rule in the style-file that would change either the name of the road OR the type (0x??) of a road. If both not changed then merge it. Nice to see some work on it. On 25/07/2009, Thilo Hannemann <thann...@gmx.de> wrote: > Hi Johann, > > Am 25.07.2009 um 10:54 schrieb Johann Gail: > >> A further development would be, to consider only nodes which are >> visible >> crossings at the current zoom level. I.e. if a residential connects >> to a >> big road and the residential is not visible at the current zoom level, >> then it is allowed to zap this node. This would straighten out lines >> at >> low zooms much more. But at the DP filter code I don't have this >> information available. > > Yes, that would be the best way. But one would need to change a lot of > the underlying code to make it happen, as currently only the number of > highways that use a node is stored, but no reference to which highways > that are. Changing this would be a major act unfortunately. > > About the error distance: What I still experience is that the lower > resolutions look bad in the maps. It seems that the ways get too much > simplified for lower resolutions. It seems almost like a scaling > problem with respect to the resolution. I reduced the error distance > to 1/8th of the resolution and that brought some improvement in the > higher resolutions (20, 22). But if I look at the lower resolutions > (down to 12) it gets worse and worse. Looking at the DP code I can't > find any hint why that should happen, so it might happen somewhere > else? I have no clue. > >> Btw.: there is another patch around, which merges lines before DP >> filtering them. This is reasonable for the highways at very low zoom >> levels, which could be simplified often to a sinlge line in the >> overview >> maps. (But only if they are not cut in segments from exit to exit). >> If I find some time I will release an updated patch for it. > > this is very interesting. I was planning to implement something likes > this for some time, but didn't get around to do it. But not so much > for display, but for routing. I think the routing could be much > improved if we would merge ways, especially for bicycle routing, where > the cycleways consist of tiny bits here and there. The routing > algorithm in the Garmin units then won't find a nice route, because it > gives up trying to wiggle its way through the short bits. Instead it > takes a long way that goes into the general direction of the > destination. Which often happens to be a major road that you don't > really want to use while cycling. The cycleway going alongside it > isn't used, because the routing algorithm doesn't find it. > > So if you have that patch available please post it. Even if it doesn't > work against the current trunk I'll happily try to make it work. > > Regards > Thilo > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
