I think I'm seeing some unintended consequences of the avoid duplicates feature.
In this area http://www.informationfreeway.org/?lat=51.33878030479553&lon=-0.51082781519874&user=80n&zoom=17&layers=B0000F000Fthere is a long way named Woodlands Avenue that joins another way with the same name. Only one of the ways has it's name rendered. Firstly can anyone confirm whether this is likely to be caused by the avoid duplicates feature or whether I should be looking for some other cause? If it is avoid duplicates would it be possible to tune it in some way so that it doesn't do this? What's the algorithm that is currently used? 80n On Wed, Jan 7, 2009 at 4:13 AM, Matthias Julius <[email protected]>wrote: > Frederik Ramm <[email protected]> writes: > > > Hi, > > > > since nobody cried havoc, I have now enabled the "avoid duplicates" > > option for or/p for all street names and numbers (name= and ref= tags) > > on zoom levels 14, 15, 16, 17 (SVN revision #12998). > > > > The change should be noticeable in places where until now many street > > names/labels were printed on top of each other. It may require some fine > > tuning and it might even accidentally drop a name for which there would > > have been space, but it will only ever drop a name where the same name > > is used in the immediate vicinity. > > > > Memory usage will be slightly increased. > > > > If you want to know what labels it drops, you can enable the "drawing" > > debug setting or or/p to get debug messages. > > It seemed like you have missed a few 'if ($debug->{"drawing"})' > conditions on those debug messages. I have added them in r13022. > > Matthias > > _______________________________________________ > Tilesathome mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/tilesathome >
_______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
