[Tilesathome] Avoiding name duplications on dual carriageways

[Knut Arne Bjørndal]

On Tue, Aug 19, 2008 at 11:17:32PM +0200, Frederik Ramm wrote:
>     I have an improvement for or/p that I presented to you a while ago 
> and then forgot about it ;-) it is meant to reduce the number of text 
> duplications (name and ref tags) on dual carriageways and similar 
> situations.
> 
> What it does is this:
> 
> If a text rule in the style file is flagged "avoid-duplicates=yes", then 
> whenever this rule leads to a text being drawn, the first and last node 
> of the corresponding way and the text are stored in memory. Before a 
> text is drawn for another way, the list is checked to see whether the 
> same text has already been written to a way whose start and end nodes 
> are close to the start and end nodes of the way being looked at.
> 
> (The distance between the two nodes that will trigger dropping of labels 
> is currently a hard-coded number in metres, should probably be 
> configurable per zoom level, e.g. "avoid-duplicates=1000" or so?)

Interesting way to handle it in a reasonably simple way.

> This is quite effective at removing double labels, while at the same 
> time not doing full text collision avoidance (i.e. if you have two roads 
> with *different* names next to each other, both names will be drawn no 
> matter what). The drawback is that results may look arbitrary; whichever 
> label gets drawn first, gets drawn first (and blocks out another label 
> in a similar position). Although I have not observed this during my 
> tests, it is conceivable that a "ref" label along a motorway that sits 
> exactly on the line between two z12 tiles would be drawn for one lane 
> on one tile and for the other lane on the other.

I've been thinking we may want to do real collision avoidance, or at
least put what effort we spend on it into something that may one day
do it properly.

I think it makes sense to do that as a post-processor, yes it will
have to handle some stuff like labels that are drawn in two rounds
(core&casing-like), but that shouldn't be /too/ hard. This will allow
it to be used where it's feasible to run perl (or whatever it ends up
being written in), and it will be a reasonably separate component.

Real collision avoidance in XSLT will probably never happen, and I'd
love for this to be available to osmarender/xsl output as well.

> Osmarender/XSLT compatibility: Any software not interpreting the 
> "avoid-duplicates" tag will simply draw *all* labels as before, so again 
> if you are on the border of two z12 tiles and one is rendered with 
> Osmarender/XSLT and the other with or/p, it might happen that the XSLT 
> tile has both names and one of them simply stops at the tile boundary. 
> This is probably the only adverse effect.
> 
> What do people think - should this be used for tiles at home, would it make 
> the maps better on the whole, or do the drawbacks outweigh the 
> advantages? - Since the method has to be activated for each text rule we 
> could start using it only for names/refs on motorways and trunk roads 
> (which are most likely to be dual carriageways) and see how it works
> 
> Bobkare, do you have any plans for doing something similar in the XSLT 
> version (in which case I might shelve this plan and copy your's for the 
> sake of compatibility)?

Afaik I can't even put something off into a global list somewhere to
look up later, so I have no idea how I'd implement this.

/Maybe/ something could be cludged up that worked per-rule, since I
think that shares the same execution path fairly long.

If I look at this it won't be for quite some time, the things on the
top of my current TODO is the testing framework for osmarender as well
as the related SVG::Rasterizer that will also be used for t at h,
replacing much of the current mess in svg2png.

-- 
Knut Arne Bjørndal
aka Bob Kåre
bob+osm at cakebox.net
bobkare at irc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4167 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tilesathome/attachments/20080821/34e1eb83/attachment.bin>