Thank you @gymate for your work so far.
Please excuse my late reply. This is a complex issue that requires enough time to think about. Now I have finally found the time.
As there is a lot of discussion here to read through, I will comment on single posts and the questions where you mentioned me later.
First some general information about mapping stations as nodes vs. areas and why I preferred nodes in the past but now think that areas are the better solution:
The area of a station differs significantly depending on whether you look at it from the perspective of public transport or railway operations. In addition, every public transport station is a train station, but not the other way around (e.g. freight stations). A public transport station includes the platforms, the station building, and overall the areas that are accessible to passengers. The railway infrastructure differs from this: the station building is irrelevant here, but the station area may still include yard tracks, signal boxes and engine sheds. The station is defined by certain signals and switches, so that it can be significantly larger than what the passenger perceives as the station.
In summary: It makes sense to capture both views with separate objects in order to be able to clearly distinguish between the two topics (public transport and infrastructure).
In the past we tried to combine both views in a single feature (partly also for backwards compatibility with renderers), but then you end up mapping a node as a compromise to satisfy both views. But this brings new problems like not being able to query the signals of stations because there is no information about the extend of the station. Which then requires workarounds like the railway facility relations.
Today I think the far better solution is to clearly distinguish between railway operations and public transport view and map both as detailed as possible, which means mapping them as areas.
The updated illustrations and wiki pages are definitely going in the right direction and making things more clearer by separating between both views. But I would still have a few suggestions:
I would suggest abolishing
railway=facility. We (mainly Nakaner and I) introduced this at the time in order to be able to map stations as points on the one hand and to be able to do queries such as “which station does this signal belong to” on the other hand.
railway=facility never really caught on because mapping it was time-consuming and there was no application back then that used it. I’ve actually never really used it myself, too. But the main reason might be that the tagging design was bad:
- I agree with some other comments here that mixing
public_transport=stop_areawas not a good idea. This resulted in complex and confusing tagging like
type=public_transport + public_transport=stop_area + railway=facilityfor passenger-stations and
type=*for non-passenger stations (by the way impossible to create intuitive tagging presets for that). It also resulted in mixing public transport members such as stop_positions and subway_entrances with features such as the landuse from a railway operations perspective.
- The facility relation duplicates a lot of tags of the
- The facility relation maps one real world feature as two features in OSM, which is not a good practice.
Now with the recommendation to map
railway=station as areas (for the infrastructural boundaries), I no longer see any need for the workaround with
railway=facility and propose to deprecate it. It is just redundant information because the information is either already mapped at the station area or can be queried with a simple geometric query without having to maintain a relation and manually adding each signal (can be a lot in bigger stations).
Tag:railway=station - OpenStreetMap Wiki suggests:
It seems illogical to me that there is no land use within the station boundaries, but outside there is. For me it appears a bit like “you do not need any landuse=residential if there are building=detached because they implicate landuse=residential”.
I would avoid such implications as they make using the data difficult. It is necessary to know such rules when rendering a map. And instead of considering just all features with
landuse=* to render a landuse map, it is necessary to also consider stations features.
I would prefer to add landuse=railway` at the station area.
I would suggest to replace
ref=* at the platforms by
local_ref=*. This reflects the local character of this id in contrast to global or operator wide identificators in
ref. Would also be more consistent to use
local_ref both at platforms and stop_positions as it contains the same data.
A problem I see is the compatibility with existing data users, for example OSM Carto. OSM Carto renders
railway=station, but should better use
public_transport=station instead to avoid the known problems with unexpected labelling.