Yeah, I see your point, and I agree that this duplicate tagging is wrong.
Thanks for pointing this out—I’ve edited the issue description.
OSM Carto developers stand by their 2013 decision:
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’ve corrected all of my edits on OSM where I used duplicate tagging (incl. Kimle-Károlyháza).
@DaveF has replaced this illustration with this one:
Unfortunately it has multiple issues so I’ve asked him to correct them.
1 Like
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.
The ref on railway=stop represent the platform. It would be pretty useless to give all stops the same station code.
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=
1 Like
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.”
2 Likes
agreed, local_ref is really crazy, it has the same semantics as loc_ref but should be used only in a specific context, next we will also get loc_reference, and of course local_reference (because we don’t abbreviate generally)
@DaveF, thank you for joining the discussion here! After all, it’s a continuation of your former discussion with @dieterdreist.
It is indeed defined by entry signals (that’s why they are called that way). Just see the Hungarian railway code I linked in the first comment. (It’s not even the German one!) Translation:
1.2.4. Station area
The area between either entry signals placed at the ends of the station bordering the open line or V-letter signals or control signals in the direction of entrance. At termini, the area within the entry signal or V-letter signal or control signal in the direction of entrance.
You also said this on the Wiki:
A railway station is a place accessible to the public. It doesn’t stretch a whole kilometre down the tracks, it doesn’t include sidings (And by that I mean the genuine meaning of sidings. Tracks which run adjacent to platforms allowing passengers to catch a train are /not/ sidings).
The area between entry signals of a station can stretch a whole kilometre—often even more than that. Just check out this Overpass query.
And a railway station does include sidings—see the Train station Wikipedia page or the station manual of any Hungarian railway station.
2 Likes
One of these was:
please add a white background to the text boxes in order to make the texts readable even with a dark background under the image.
@DaveF’s reply:
Under what circumstances are you using a dark background that doesn’t auto-change black text to white?
@DaveF Like here, in the Community Forum. Your illustration looks like this now on my device:
1 Like
Y’know I’m spitballing here, but if somebody in the graphics production chain (@DaveF?) is using a macOS that has been patched (OCLP) recently with a recent Sonoma, “live text” is broken and looks very much like this, but “frozen wrong.” If you were to save a document like this in that scenario, I would further nod my head. Might even be easy to do inadvertently.
An .svg is an .svg, right? Unless some screen-grab or text idea sketch software was used to produce this that got its alpha channel scrambled or something. This shouldn’t happen. The fault lay in the producer of the document, I think. It seems there are too many settings “on” with regard to shadow or background or something like that. I don’t know what “sketch software” you use to produce that, but “some assumptions are being made” that shouldn’t be made.
For all practical reasons, as it says, I agree: the graphic immediately above has “unreadable text.” This graphic gets a thumbs down from me, I’m sorry but truthful to say.
The easiest way to say how I’d fix is to expand the light-puce-colored background in the center to the whole stage (rectangle). That way, your dark text stands out clean in high contrast. Now, that “empty space” either needs to be “clear” or light or dark (with text in high contrast), not a multi-rectangle that varies around a center. If you want to “decorate” that, consider a very light fill pattern, tending to a “light gray.” Otherwise draw a box or blob if edges of boundaries are precise or vague. Show off a bit if you can, but get the basics of “can be seen as a clear diagram” down cold. What we see above ain’t it: text is broken. The other easier way is to note that your dark text is over an area which has no defined background (color, also see alpha channel). So, assumptions re text color is dangerous. Otherwise, nice and visually clean and simple.
And we know it can be done, as the graphic is a nice walk on the way to a clear one.
1 Like
All of the wiki is built on opinion.
Explain how routing works if all railway=stop tags (of which there are multiple per station) all have the same ref=* value as the station code? There has to be a unique tag for it to be workable.
The wiki for stop_positions (public_transport schema’s equivalent of railway=stop) states the ref tag should indicate "Track number/platform number. " not station ref.
Unsure why you @ me. If the graphic isn’t visible in a different piece of software for which it wasn’t created then criticize the person who pasted it & the creators of this software.
They are, by you.
Correct.
1 Like
Are you reading the English version? What I’m seeing is the following:
ref: Track number/platform number. Some people prefer to use local_ref=* for track/platform numbers, some prefer ref=*. Please note that ref=* might be in use for a network-wide unique reference of the stop position.
Once again, this conflicts with existing usage of ref=*. Also, why does the track number need to be tagged on a railway=stop node, if it’s already on the underlying way as railway:track_ref=*? This seems redundant and time-consuming to map.
Correct.
Notice it makes no mention of train drivers or indeed, German rail enthusiasts.
