-
Notifications
You must be signed in to change notification settings - Fork 819
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Render the name=*
of railway=station
areas only at their label
#4946
Comments
railway=station
areas at their label
memberrailway=station
areas at their label
I am not quite sure if i understand your request correctly. You are asking us to de-duplicate double mapping of https://www.openstreetmap.org/relation/7917952 or: https://www.openstreetmap.org/way/1266472328 |
@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 ¹ with a |
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
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. |
railway=station
areas at their label
name=*
of railway=station
areas only at their label
We do not do anything with relation members with a I am inclined to regard a MP with any roles other than inner/outer as an error and not something we want to support. |
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. |
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. |
Oh, I missed that this was about type=label relations. Anyways, we've already stated that we will not be using label nodes (#105) |
@imagico That's a good point, and the answer is no.
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!
I agree, thanks! |
@pnorman @imagico Oh, I see, my bad!
With this in mind, would the following be an acceptable suggestion instead? (If yes, I could open a new issue.)
|
I assume we are still talking about labels for 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 Concepts i can identify in use are (in descending order of prevalence):
Looking at the data also shows that less than ten percent of all In other words: If Independent of that using |
No. It is far too complex to implement given the constraints we have and we shouldn't be using centroid at all |
Looking at this, all three cases are equivalent to the third, so the algorithm is significantly more complex than it needs to be. |
Take a
railway=station
area or multipolygon relation that also has a node at the practical centre of the station (nearbuilding=train_station
) as alabel
member of a) itself, or b) in the case of areas, of a parenttype=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/
The text was updated successfully, but these errors were encountered: