allow collisions with some symbols

[matkoniecz]

obvious situation with strong improvement

http://www.openstreetmap.org/?mlat=49.4712&mlon=21.3811#map=15/49.4712/21.3811

really high gate density with some improvements and some regressions, overall effect is IMHO positive (and new problem may be almost certainly fixed by adding halo to street names)

http://www.openstreetmap.org/#map=16/50.0484/19.9300

Fixes parts of #323 and #964

Likely also other symbols may benefit from similar change, but not all of them - see #982 (comment)

[mboeringa]

and new problem may be almost certainly fixed by adding halo to street names

that halo will indeed be vital for this. Without it, the names of the streets are completely illegible.

Looking at this particular example, I personally really feel the gates shouldn't be rendered before Z18, but that discussion has been going on elsewhere...

Once the halo is implemented, I think you made the most of a situation upon which no really good agreement and solution is possible.

[matthijsmelissen]

I think for unclassified/residential, adding halos is no problem.

For motorway/trunk/primary/secondary/tertiary, adding halo might decrease legibility.

[HolgerJeromin]

For motorway/trunk/primary/secondary/tertiary we could use a halo in the color of the corresponding road fill. No visible changes in the normal case, but better readability if there is for example a gate underneath.

[matthijsmelissen]

I have tested this, and I think this can be merged, provided #1010 (road halos) is merged as well.

[matthijsmelissen]

You could consider allowing collisions for peaks as well.

[matkoniecz]

@math1985 There are areas with high peak density giving results even worse than my parking example ( #982 (comment) ). Some people micromapped the slightest hill in their city as a peaks, what would result in peak icons merging and covering anything except labels.

Note that such tagging is OK according to http://wiki.openstreetmap.org/wiki/Tag:natural%3Dpeak

[gravitystorm]

Sorry, I don't want to see half-a-symbol peeking out from behind something else, that's really low-quality cartography. If our priority is wrong (e.g. if road labels are more important than gates) then they should be rendered first.

Overlapping stuff is a fudge, just like transparency!

[matthijsmelissen]

@mkoniecz Could you generated the second example again with #1010 merged into your branch? I would need to see how that looks before I can form an opinion.

[matthijsmelissen]

I think moving the layers for towers and gates etc. above the text layers would be doable. It would also prevent half-gates from peeking out under other icons - not sure if that's an improvement or not, but at least @gravitystorm seems to think it is.

With that method, I think we would be able to include peaks as well.

[mboeringa]

Sorry, I don't want to see half-a-symbol peeking out from behind something else, that's really low-quality cartography. If our priority is wrong (e.g. if road labels are more important than gates) then they should be rendered first.

Overlapping stuff is a fudge, just like transparency!

I think most here agree, but I think this was an attempt at a kind of compromise to keep some "gate-mappers" happy and still show gates at zoom levels they probably shouldn't be displayed at...

Maybe it requires an "executive" decision by you all maintaining the style, to no longer render gates at anything but Z18 or 19 (you might be able to get away with Z17 looking at this example), because that is the level of detail these micro-mapped gates are only reasonably viewable without major compromises or problems with collisions.