[amenity-points] use type=label relations in mapnik

[openstreetmap-trac]

Reporter: Oli-Wan
[Submitted to the original trac issue database at 12.58pm, Tuesday, 6th July 2010]

Sometimes mapnik's placement algorithm for labels (names, icons, etc.) on areas (or buildings, etc.) is not quite optimal, especially for somewhat exotically-shaped areas.

osmarender allows for the type=label relation to specify the location the label should be placed. I believe this is a very good thing, so I suggest that the relation should be used by mapnik as well. (See http://wiki.openstreetmap.org/wiki/Relations/Proposed/Label for details about the type=label relation.)

This issue is loosely related to #1534 (area label positioning) http://trac.openstreetmap.org/ticket/1534 . But while #1534 concerns extending the placement algorithm itself to check for holes in multipolygons etc., here I suggest an explicit override to be specified in the map. I am not aware of any other way to specify such an override, but if it already exists (please give me a hint!), maybe the corresponding routine could be extended to check for type=label relations as well.

[openstreetmap-trac]

Author: TomH
[Added to the original trac issue at 3.56pm, Wednesday, 7th July 2010]

Ye gads no. A type=label relation is an abomination - it's a canonical example of "mapping for the renderer" and we don't do that in OpenStreetMap!

[openstreetmap-trac]

Author: Ldp
[Added to the original trac issue at 7.05pm, Wednesday, 7th July 2010]

Also, different renderers would use different fonts and font size/styling, and so different placements could be needed for these different renderers. This could create a tug of war scenario with respect to label placement using this relation.

[openstreetmap-trac]

Author: Oli-Wan
[Added to the original trac issue at 10.15am, Thursday, 15th July 2010]

Replying to [comment:2 Ldp]:

Also, different renderers would use different fonts and font size/styling, and so different placements could be needed for these different renderers. This could create a tug of war scenario with respect to label placement using this relation.

The renderer could just read the relation as "imagine the area were a single node at the specified location" and then just do what it would in that case.
I don't see wars coming up here. The label relation is not meant for "optimizing" label placement - it is intended only for a tiny fraction of cases where the default position chosen by several common renderers is complete garbage.

[openstreetmap-trac]

Author: Oli-Wan
[Added to the original trac issue at 10.30am, Thursday, 15th July 2010]

Replying to [comment:1 TomH]:

Ye gads no. A type=label relation is an abomination - it's a canonical example of "mapping for the renderer" and we don't do that in OpenStreetMap!

There's no rule without an exception.

Imagine a train station (mapped as a highly asymmetric area), where the actual platforms, along with all connections to roads, other public transit, shops, vending machines, etc. are all in one part of the area, far away from the center. One can argue that the train staion's label should then be placed in that part, and not at the default location (the area's center of mass, I guess).

There are probably more examples of such cases where labels are rendered at counter-intuitive positions, but I have seen only one, which is related to a somewhat strangely shaped station. But since those cases are so rare (most labels are displayed at sensible locations), there is no need to change the algorithms, but instead users should be given the option to override the default.

[openstreetmap-trac]

Author: math1985
[Added to the original trac issue at 3.38pm, Friday, 30th May 2014]

I will close this per TomH and Ldp.