You appear confused about general tag usage. To repeat so it’s abundantly clear:
public_transport=* is a completely separate tagging schema from railway=*
Many different objects can, and do, use the ref=* tag.
railway=platform & railway=stop both use the ref=* tag.
A railway=stop’s ref tag has the same value as the adjacent railway=platform’s ref tag because it indicates that a train stopping at say, railway stop 4 is adjacent to platform 4. It’s essential for routing.
Well, as I’ve already said that’s a problem with this forum, not OSM wiki or SVG.
Please don’t mention this again, as it’s just deflection from the original point of this thread.
A railway station’s entrance:
Wikipedia’s description of a railway station:
You’re misinterpretation of the meaning of a siding requires further explanation to you in a separate thread.
A railway station is not defined by signals, switches, cross-overs or junctions.
I don’t recall mentioning public_transport=*. railway:track_ref=* is not part of public_transport=*.
There are still several unresolved issues with the new diagram you unilaterally created, and it is clear that consensus has not formed around the tagging scheme described in it. I support reverting the wiki pages to the previous diagrams until we can come to a consensus.
The whole premise of this thread is @gymate’s & @dieterdreist’s false belief that the public_transport schema is the same as, or somehow intertwined with railway=*.
It is not. This thread, & previous discussions reinforces my belief that those who advocate, & even created, the public_transport_schema bit off more than they could chew.
I will continue to make OSM wiki edits in order to put a clear gap between the two.
OSM wiki is used primarily by inexperienced contributors. Th wiki needs to written with the KISS (Keep It Simple, Stupid) theory in mind.
Of note, no images of signals, crossovers, (true) sidings or junctions are returned when Google searching ‘railway stations’
https://www.google.co.uk/search?q=railway+station&udm=2
I’ve looked up the source and the location of this image.
Even the original file name says New signal structure at Thorpe Le Soken station-3.JPG. You can also see the switches in the background which are also part of the station. Reference: this website from the same company (Network Rail):
We renewed a junction at New Cross station, south of London Bridge on the Charing Cross to Dover Mainline, over Christmas 2016. The switches and crossings and other track equipment that make up the complex junction, which is third-rail electrified, were completely replaced to provide better, more reliable journeys on the railway
Please explain why these invalidate my previous arguments. Using sources facilitates the debate, but please also make your arguments explicit.
Alright, please open a new topic for this then! But if you think it’s relevant to mapping railway=stations, then please discuss it here.
I don’t currently believe that the public transport schema is the same as railway=* tags. I’m sorry if I wasn’t clear.
I only included public_transport=* tags in my illustrations because
railway=stations are also public_transport=stations (i.e. they are open to the public)But now that I’ve heard your arguments, I’m completely open to separating these two schemas better.
This is a flimsy argument because Google shows you results based on your current location. For example, I get the following results in the first three rows (using incognito mode and iCloud Private Relay):
Although they are not in the foreground, these images include at least 17 signals and 13 switches.
But I would recommend sticking to primary sources when discussing this issue.
I’ve remapped Budapest-Keleti railway=station as an area. Now it looks like this:
The label is rendered far away from the station building marked with the purple dot.
I’m sorry to bring this up again, but I asked (HU) fellow mappers at a recent OSM Hungary Meetup if they agreed with this mapping method, and if they would be willing to wait for more railway operating sites being mapped as areas—until this problem is fixed in the renderer.
@BáthoryPéter suggested that in these cases—where the station label would be rendered far away from the public areas of the station—, we could go back to using a railway=station node, and map the station area with a separate landuse=railway area, which has an additional tag that could be chosen by agreement. This additional tag could distinguish it from other landuse=railway areas that do not mark the boundary of a railway operating site. This way the renderer would be “forced” to render the name of the station in the correct place.
What do you think of this idea?
It’s good to know that if we decided to map some stations this way, we would make it harder to connect the station with its perimeter (which is actually why I started this discussion). For example, we would lose the ability to Overpass query all objects of railway operating sites where the area of landuse=railway is mapped as a multipolygon relation. This is because the API can’t convert multipolygon relations that do not have a name=* tag to areas. (See this example.) So they couldn’t be written to sets and passed as input to another line in the query (like here) in order to get all elements within the station boundaries.
I think manual label placement is necessary in terminal stations like Budapest-Keleti. Even if all the tracks within the polygon are considered part of the station, they’re clearly arranged to serve a passenger facility at the end of the tracks. An automatically-placed label in the center of the area would be misleading to railroad passengers and workers alike.
At several major stations in North American cities, the tracks are tucked away in a vast basement, with a street-level entrance building integrated into the urban fabric above. For Grand Central Terminal in New York, the label is currently placed over the center of the station building, from the passenger’s perspective. Automatic label placement would probably put Grand Central somewhere along 46th Street, which would look bizarre to New York commuters, as well as confusing to tourists looking to marvel at the architecture. Besides, Grand Central is Mile 0 for various railroads heading north out of the city—it only makes sense to put the label near where the tracks start.
Even if all the tracks within the polygon are considered part of the station, they’re clearly arranged to serve a passenger facility at the end of the tracks. An automatically-placed label in the center of the area would be misleading to railroad passengers and workers alike.
could there be a distinction between public_transport and railway=station, the former being used for the publicly accessible part of the station?
Yeah, you’re right. I actually made the illustration like this:
But then I think I misunderstood @rurseekatze’s comment so I merged public_transport=station into railway=station:
I’ve undone that now:
Please let me know if you find any further mistakes in it.
This should fix the problem I raised (and it would also work for Grand Central Station), so I’d suggest it to OSM Carto developers. I’d also request an update to the iD tagging schema.
I’d just caution that the public_transport tagging schema was never meant to change the meaning of earlier tagging such as railway=station. In fact with the public transport tags as originally proposed, there was no way to tell that a station is a train station (as distinct from, say, a bus station) unless it has the railway=station tag. (I know some people get around this by adding train=yes, which was not part of the proposal).
So saying now that public_transport=station has a different meaning to railway=station is a fairly significant change. If the proposal is for Carto to prioritise public transport tags instead of the original tags, does that also apply to bus stations, highway=bus_stop and so on?
But it did—just two days after 2014-11-20 (when the voting for the public_transport=* schema ended) a short guide was added to the railway=station Wiki page on how to map it as an area. Before that, there was only an example on that page with a different approach.
I see your point, but I think it’s normal (and often beneficial) for an approved tag to influence a de facto one.
Yeah, but using public_transport=station on the same node as railway=station was not part of the proposal either. (And however not together with public_transport=station, but train=yes was at least in the proposal.)
It is, but not to public_transport=station, I think, as it retains its original meaning.
The proposal is that Carto should only prioritise the tag public_transport=station. But yes, it would also apply to all other common uses of this tag.
Yes, specifically referring to the area used for passenger services. There was no hint at that point that railway=station would refer to an operational site or be defined by signals.
Using a generic public transport icon? Or using train=yes etc. to decide the type of icon, effectively formalising this in tagging? I have a feeling there have already been long discussions about this but I can’t locate them right now. You would probably need to be able to explain why thr situation has changed since those discussions.
Unfortunately the proposed relationship between the two tagging schemes does not seem to have been made clear, and we are still living with the consequences. By not deprecating the old tags, and not defining any reason that the new tags would apply to different objects, I feel it was implied that in general the tags would apply to the same objects. But that was before I joined OSM and maybe that was not how people viewed it at the time.
The latter.
I’d be grateful if you could find any of those earlier discussions. Unfortunately, my search hasn’t yielded any results.
