render labels for named barriers

[matkoniecz]

Done to handle case reported in #1824

https://cloud.githubusercontent.com/assets/899988/10177608/45f21e9c-66fb-11e5-9d85-82d369039b18.png (the same place, more zlevels)

https://cloud.githubusercontent.com/assets/899988/10177637/674fa0aa-66fb-11e5-87b7-4face372bd89.png (named barrier in mountains)

note that in case of using one element to tag both named area objects that is not rendered and linear barrier it will result in an unwanted name for barrier - see for example https://cloud.githubusercontent.com/assets/899988/10177630/5f4ddc6e-66fb-11e5-8543-a593a47a59d4.png (caused by http://www.openstreetmap.org/way/115536902#map=19/41.89471/12.50457)

In more popular cases (one OSM element with name to represent both rendered area object and linear object name is not rendered on barrier) - see https://cloud.githubusercontent.com/assets/899988/10142490/49c48cfa-6613-11e5-9069-7f7d2dad99ca.png

[matthijsmelissen]

This introduces another catch-all rendering (for barrier names), I think we wanted to avoid these. I guess it'd be better to explicitly define a list of barrier values?

[pnorman]

Yes, this is labeling objects which may not otherwise be rendered - e.g. barrier=foo name=bar would get a name, but nothing else

[matkoniecz]

At this moment I think that rendering names for all rendered barriers is OK.

We have anyway catch-all rendering of all barriers, reported as #818.

After fixing of #818 also names should be displayed only for valid values of barrier key.

[matthijsmelissen]

Ok, good point.

[matthijsmelissen]

I would significantly increase, or drop, the text-wrap. For names rendered along lines, a short text-wrap does not look very good.

[matthijsmelissen]

Thanks @matkoniecz! I'm going to accept #1986, would you be able to make this PR match? Feel free to re-open the PR when ready (or create a new one).