Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

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

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 5 comments
Closed

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

openstreetmap-trac opened this issue Jul 23, 2021 · 5 comments

Comments

@openstreetmap-trac
Copy link

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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

I will close this per TomH and Ldp.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant