Render the `name=*` of `railway=station` areas only at their `label`

[gy-mate]

Take a railway=station area or multipolygon relation that also has a node at the practical centre of the station (near building=train_station) as a label member of a) itself, or b) in the case of areas, of a parent type=label relation.

Expected behavior

The label is only rendered at the node, the same way as place=city multipolygon relations, like Chicago are on lower zoom levels:

Actual behavior

The label is duplicated. It's also rendered at the centroid of the area or multipolygon relation.

See the railway=station area Kimle-Károlyháza for example:

Or the railway=station multipolygon relation Rajka:

Links

Related discussion on the Community Forum: https://community.openstreetmap.org/t/railway-station-as-an-area/104839/

[imagico]

I am not quite sure if i understand your request correctly.

You are asking us to de-duplicate double mapping of railway=station with polygon and nodes, prioritizing the node mapping and discarding the polygon? Like here:

https://www.openstreetmap.org/relation/7917952 https://www.openstreetmap.org/node/4751043700

or:

https://www.openstreetmap.org/way/1266472328 https://www.openstreetmap.org/node/91711594

[gy-mate]

You are asking us to de-duplicate double mapping of railway=station with polygon and nodes, prioritizing the node mapping and discarding the polygon?

@imagico Yes, but only if the double mapping is on purpose (in order to avert issues like these), i.e. the node is (in the case of areas: indirectly¹) connected to the polygon with a label membership.

¹ with a type=label relation "between" them

[imagico]

type=label has 51 uses on relations and the documentation indicates it to be intended as a map drawing vehicle rather than a method for documenting geographic information.

Nodes as members of multipolygon relations are undocumented and used rarely (<10k of 36.5M relations). I am not aware of any data users that interpret such.

I don't see any documentation of railway=station having a different meaning when tagged on:

• nodes
• polygons
• nodes that are member of a relation of some type

Is there a de-facto difference in meaning between these different types of use?

Is there agreement among mappers that the examples of double mapping linked to above are correct? That would seem odd in light of https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element.

[pnorman]

The label is only rendered at the node, the same way as place=city multipolygon relations, like Chicago are on lower zoom levels

We do not do anything with relation members with a label role. In fact, it is not technically possible to do so with the osm2pgsql backend we're using. See #103 for some related discussion.

I am inclined to regard a MP with any roles other than inner/outer as an error and not something we want to support.

[mboeringa]

Take a railway=station area or multipolygon relation that also has a node at the practical centre of the station (near building=train_station) as a label member of a) itself, or b) in the case of areas, of a parent type=label relation.

This whole construct of a type=label relation doesn't make a lot of sense.

Usually, a node label member is added to an existing relation with role=label, e.g. of type=multipolygon or type=boundary, but here you are "upgrading" the label to be a relation by itself. This seems a really confusing and non-standard usage of label nodes in relations.

I really recommend you to add the node that is supposed to be a label as a member of a multipolygon or boundary relation with role=label instead of inventing a whole new type of non-standard relation. Just see the Chicago example you posted yourself: it doesn't feature a type=label relation, but simply adds the node with role=label to an existing boundary relation.

[imagico]

We do not do anything with relation members with a label role. In fact, it is not technically possible to do so with the osm2pgsql backend we're using. See https://github.com/gravitystorm/openstreetmap-carto/issues/103 for some related discussion.

To be clear: As i see it this is, on its own, not a reason not to support MPs with node members, it is more a symptom of the fact that these do not have any broader support in the OSM community.

And to be fair to osm2pgsql - they are now supporting node members for relations. So this is not really an external constraint any more that prevents us from doing so. One of the strategic reasons for #4112 is to allow us to be able to support new developments in relation mapping in OSM without depending on software developers to endorse these.

I am closing this because of the clear lack of consensus among mappers on the specific mapping methods this issue suggests to support. That does not mean we are against changing the way railway stations are rendered. Public transport mapping has developed quite a bit and although there are various competing schools of tagging in that field there are also things on which there is quite broad agreement that we do not yet support. Identifying those and developing design concepts to support them would be a valuable contribution here.

[pnorman]

Oh, I missed that this was about type=label relations.

Anyways, we've already stated that we will not be using label nodes (#105)

[gy-mate]

Is there a de-facto difference in meaning between these different types of use?

@imagico That's a good point, and the answer is no.

Is there agreement among mappers that the examples of double mapping linked to above are correct? That would seem odd in light of https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element.

No, there isn't, yet. We're figuring it out right now. But thanks a lot for all of your input on this, it helps to steer the parallel discussion in the right direction!

there are also things on which there is quite broad agreement that we do not yet support. Identifying those and developing design concepts to support them would be a valuable contribution here.

I am closing this because of the clear lack of consensus among mappers on the specific mapping methods this issue suggests to support.

I agree, thanks!

[gy-mate]

we've already stated that we will not be using label nodes (#105)

@pnorman @imagico Oh, I see, my bad!

That comment from #105 was:

The geodatabase is for geodata. Rendering decisions are made by the renderer. If the renderer isn't sufficiently advanced to place a label to your desire, then lets improve the renderer.

With this in mind, would the following be an acceptable suggestion instead? (If yes, I could open a new issue.)

• Take all railway operating site areas and multipolygon relations
• Check if there is any railway=stop node in their area
  • If no: don't change the rendering location of the label
  • If yes:
    • If there is only one: render the label at that location
    • If there are two:
      • Connect them with a line
      • Render the label at the midpoint of the line
    • If there are more than two:
      • Connect them in a way that they form an area
      • Render the label at the centroid of the area
• If the calculated rendering location of the label lies outside of the area or multipolygon relation of the railway operating site, render it at the nearest point of the area.

1. This would move the rendering location of the label much closer to the "practical" center of the railway operating site, i.e. what its users (passengers) have in their mind.
2. The tags this would depend on are quite widespread and I think there is a consensus on how to use them.

[imagico]

I assume we are still talking about labels for railway=station polygon features here.

In general, i would be in favor of improving labeling based on the data context of the feature in question. But this requires data quite consistently complying to well defined mapping conventions. I am not too sure this is the case here. And it would have to be intuitively understandable for the map user to comply with our goals.

My impression from looking at the data now is that railway=station is typically used on polygons for mapping a variety of fairly different concepts and these are just incidentally using the same tag. This is not well documented and i am not sure if there is consensus among mapper on these to be used in parallel. Until recently the wiki documented some of this. But that has been removed now - which does not mean there are no differences in mapping practice any more.

Concepts i can identify in use are (in descending order of prevalence):

• the station building
• a compact hull around the navigable area of the station from a passenger perspective
• the perimeter of the station from a facility management perspective
• the perimeter of the station from a railway operations perspective

Looking at the data also shows that less than ten percent of all railway=station are mapped with polygons anyway. Of these nearly 75% are tagged on buildings. For the rest i can find only very few cases where your sketched algorithm would be likely to produce a better label location than what we use right now. Most of the cases where this might theoretically be the case are subway stations with complex geometries - where labeling is a challenge for very different reasons and stop locations are likely not helpful. Most other cases of polygon mapping are following the second concept with relatively compact geometries, often simple rectangles, narrowly enclosing the platforms and other publicly accessible parts of the station. In those case a label location based on railway=stop locations will rarely lead to better labeling.

In other words: If railway=station is tagged on a polygon that is a deliberate choice of the mapper to map the perimeter of the feature but not its location. I am not sure if it is a good idea for us to try to infer the location from other data if it has been deliberately not mapped explicitly even though node mapping is clearly the dominant form and there are different conflicting concepts for polygon mapping in practical use.

Independent of that using railway=stop is problematic (a) because tagging competes with public_transport=stop_position + train=yes (128k vs. 102k) and (b) because it would interfere with ideas to visualize railway=stop/public_transport=stop_position in some way (like #4662).

[pnorman]

With this in mind, would the following be an acceptable suggestion instead?

No. It is far too complex to implement given the constraints we have and we shouldn't be using centroid at all

[gy-mate]

@pnorman I see.

@imagico Thank you very much for your detailed reply! So, if I understand it well, let's wait for more consistent mapping methods (I guess a proposal process for the regarding tags would facilitate this) and then come back to this—with a different approach.

[pnorman]

• If yes:

  • If there is only one: render the label at that location

  • If there are two:

  • Connect them with a line

  • Render the label at the midpoint of the line

  • If there are more than two:

  • Connect them in a way that they form an area

  • Render the label at the centroid of the area

Looking at this, all three cases are equivalent to the third, so the algorithm is significantly more complex than it needs to be.