I corrected the instructions for adding labels to areas and multipolygon relations on the railway=stationWiki page. I tagged the following stations accordingly:
I’m a bit confused by the Carto issue. As a station should only have one railway=station object, it seems like a good thing that Carto renders two labels where there are two objects, as mappers are more likely to realise there is duplication.
I am also a bit concerned that the page is moving beyond clarifying current practice towards prescribing a new approach. It now gives high prominence to railway=facility which is rarely used in some (most?) countries. It now reads almost as if it is compulsory.
@imagico Also expressed his concerns on GitHub about using type=label relations and label members on multipolygon relations:
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?
Speaking only for myself, I found the mapping of Kimle-Károlyháza quite surprising. It wasn’t where I thought the previous discussion was leading. We now have two objects that repeat almost the same tags including railway=station and public_transport=station. How would mappers know which one belongs in a stop area relation, for example? Note there is also an ongoing discussion on this forum about removing duplicate railway=station which informs mappers that there should be strictly one of these objects per station: Maproulette challenge: Fix duplicate railway stations [looking for feedback]
Also, I feel it is unclear whether you are asking for rendering specific to train stations or more generally. Is there any reason to treat stations differently from hospitals, shopping centres, or universities?
Given the low usage of type=label and the fact that the only documentation seems to be a proposal from 2008 that went no further, I would say it is going to be difficult to get this type of relation rendered.
I think it is rather different from the administrative boundary situation, where it is not quite true to say that the Chicago label is only rendered once - the label also appears alongside the boundary line if you zoom in far enough.
I’m confused on what’s happening. I mentioned label as one possible option to replace the railway=station point if an area is not enough. That may not be needed if areas are accepted.
It’s entirely the wrong concept to put a “label” node in the database, and I’ll not be using it for rendering.
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.
I suggested a method to improve the renderer but it was rejected by @imagico and @pnorman for a number of reasons. @imagico recommended to wait for more consistent mapping methods (e.g. more railway operating sites being mapped as areas) first, and then come back to this question.
I fixed the landuse polygon, but I agree that “local_ref” is what is documented for local refs (platform refs as indicated). (although it is not intuitive IMHO, for one I do not understand why “local_ref” had to be invented as a different key if “loc_ref” was already documented for ages, and secondly, I would have found more intuitive to have “ref” for this, and have some more specific tag for potential “global” reference identifiers, e.g. ref:deutsche_bahn=*).
The svg graphic I created is solely for the railway=station wiki page. It contains no information about public_transport=* tags as that is a completely different schema to railway=*. Please, please do not confuse the two.
Local_ref is a tag created for the public_transport schema therefore has no place in this svg graphic.
Railway=station is defined by it’s access for the public so they can catch trains, not train drivers or rail enthusiasts in Germany. It is not defined by signals, switches, cross-overs or junctions.
I will be adding more relevant railway=* detail to the svg
Your diagram conflicts with existing usage of ref=* on railway=stop, which represents the station code (matching that of the railway=station), not the track number.
On the other hand, railway:track_ref=* is used on the underlying way to indicate track number.
No, it’s not. The ref= can be used for locating and routing on the track. They are indeed stopping at the same station. At an interchange station, some lines may not connect with each other either.
Besides, this is about existing usage, not your opinion. I would welcome more explicit prefixes, but not in the documentation. Reappropriating plain ref= isn’t an improvement.
Think about how all the =stop have the station’s name=
I don’t agree with this, nor does the wiki. It says railway=station is a tag for a railway station. It is even explicit in the definition that passengers aren’t required at all: “ Railway stations (including main line, light rail, subway, etc.) are places where goods or passengers are loaded and unloaded.”