Railway=station as an area?

[Richard (Richard Fairhurst)]

The notion of “no points == halt” is a DACH thing (and Hungary, apparently). It’s not a sensible distinction to apply to the rest of the world.

(“Points” being British English for “switches”.)

[dieterdreist]

it implies one train cannot pass another one, so this is functionally a significant distinction, but I agree it is not necessarily the distinction made between halt and station

[UrbanUnPlanner]

The presence of points/switches at a station does not necessarily mean that trains can meet/pass there. An industrial track freight station in the US with a non-clearing spur (i.e. a spur off a fast CTC mainline that lacks leaving signal or electric lock protection) would be an example of a place where you can’t have trains pass despite having a switch and a track to do it with.

[SK53]

Indeed, I find it very odd that Punt Muragl Staz is a different kind of station from Celerina Staz. The latter has a small siding, but no ability for trains to pass.

Many other RhB stations are unattended request stops, as do numerous stops on lines in the Scottish Highlands, which conform reasonably with original railway usage, are all tagged railway=station. As presence or absence of switches (or branching of railway tracks) can be ascertained with relatively simple queries, it looks as though railway=halt is not a particularly useful tag.

Until recently my local station was Furze Platt, which was, and largely still is, a classic halt in both the original UK sense, and the DACH OSM sense. Indeed it was originally called Furze Platt Halt (only renamed in 1969). The fly in the ointment is that it has a lot of passengers (~180k pre-covid), and consequently also has a ticket office open in the morning weekday rush hour.

[gymate]

Thank you for all the replies so far!

My final suggestions would be the following then:

@gymate

I would recommend restoring the old tagging scheme on the Wiki page and adding a recommendation to map railway=stations as areas.

@gymate

it would be a good idea to mention on the Wiki page that if station boundaries can’t be easily defined, map it as a node, but as an area otherwise.

@gymate

I would also recommend mapping railway=halt as an area (if halt boundaries can be defined) if the halt has switches

If you have any further thoughts on these, please share them!

[Mammi71]

im deutschen Forum gab es vor fast 10 Jahren die gleiche Diskussion und soweit ich verstanden habe, begann dies mit der gleichen Idee, aber das Ergebnis war dann ein anderes.

[UrbanUnPlanner]

Another good corner case to consider is the Amtrak station at Winter Park – there is a turnout there (East end of Winter Park siding), but it’s not part of the Amtrak station! (The infrastructure owner on that line has their own notion of a “station” at Winter Park that has nothing to do with the Amtrak station there.)

[gymate]

@Mammi71

im deutschen Forum gab es vor fast 10 Jahren die gleiche Diskussion und soweit ich verstanden habe, begann dies mit der gleichen Idee, aber das Ergebnis war dann ein anderes.

Thank you very much for pointing it out, I was not aware of that discussion!

The decision there was the following:

@Nakaner

Bahnhöfe gehören weiterhin als Nodes mit railway=station getaggt. Wer eine Fläche für die Fahrgastsicht benötigt, soll doch einfach eine konvexe Hülle um die stop_area-Relation bilden, wie es z.B. die ÖPNV-Karte tut. Die Bahnhofsfläche (also von Einfahrtssignal bis Einfahrtssignal) wird mit landuse=railway getaggt. Die Verknüpfung der landuse-Fläche mit ihrem Zweck erfolgt über eine Betriebsstellen-Relation . Mitglieder dieser Relation sind:

• Bahnsteige
• Haltepositionen
• bei U-Bahnhöfen: Eingänge
• landuse-Fläche(n), mehrere, falls es sinnvoll ist diese aufzuteilen (z.B. wenn Bahnhof nahe an einer Flussbrücke liegt)
• Bahnhofsgebäude
• Betriebsstellen-Node (der Node mit railway=station)

To sum that up in English, if I understand it correctly:

• Stations should remain tagged as railway=station nodes
• The station area (defined by local railway regulations) should be tagged with landuse=railway
• This area should be linked to a public_transport=stop_area relation.
• Objects tagged with public_transport=platform, railway=stop, railway=subway_entrance, landuse=railway, building=train_station and railway=station or railway=halt should be added as members to this relation.

[gymate]

I see their point—this is already a much better idea than mapping stations as railway=station areas because relations can have dedicated members which could include all infrastructure elements of a station.

My only concern is that the public_transport=stop_area wiki page defines the tag’s purpose as

…to identify all of the features associated with a public transport interchange or part of one.

So this cannot be applied to rail yards without passenger service, right? Because I think having a connection with infrastructure elements at those stations would also be important.

[gymate]

I think I’ve found the answer on the OpenRailwayMap tagging page:

Operating site (relation)

The associated components of an operating site, such as platforms, buildings, and stop positions. The tagging is based off of stop_areas in the Public Transport schema, but is extended to cover non-public transit operating sites.

It says that railway=facility should be used for these operating sites without the type=public_transport and public_transport=stop_area tags. So I think this question is solved.

[gymate]

@gymate

• Objects tagged with public_transport=platform, railway=stop, railway=subway_entrance, landuse=railway, building=train_station and railway=station or railway=halt should be added as members to this relation.

I would like to suggest extending this recommendation to add all railway=* objects (incl. railway=switch and railway=crossing) of that operating site as members to the public_transport=stop_area or railway=facility relation linked to their area in order to enable querying all railway operating site infrastructure elements.

[gymate]

So, if I understand it well, the common tags used on railway operating sites could be roughly summarised as the following (from a railway perspective):

• railway=station and railway=halt are used on nodes to indicate the center of a railway operating site.
• landuse=railway is applied on all areas of land used for railway operation or supporting it. A railway operating site should have its own area—marking its station boundaries—tagged with landuse=railway (see Kőbánya-Kispest).
• public_transport tags only apply to public operating sites.
  • public_transport=station is used on all public stations. If the station is a railway operating site, it’s used on the same object as railway=station or railway=halt is (see Budapest-Kelenföld).
  • public_transport=stop_area—together with type=public_transport—is applied on a relation and used for grouping all objects (incl. objects tagged with railway=* or landuse=railway) at the area of that railway operating site together as members of the relation (see Hegyeshalom).
    • If the station is not public, railway=facility (without public_transport=stop_area and type=public_transport) is applied on a relation (see Braunschweig Rbf) with the same kinds of members.
  • public_transport=stop_area_group—together with type=public_transport—is applied on a relation and used for grouping public_transport=stop_areas at the same interchange as members of the relation (see Berlin, Hauptbahnhof).

If this seems right to you, I’d like to restore the old tagging scheme on the railway=station Wiki page and adjust all these tags’ Wiki pages to match the guidelines mentioned above.

[dieterdreist]

@gymate

To sum that up in English, if I understand it correctly:

• Stations should remain tagged as railway=station nodes
• The station area (defined by local railway regulations) should be tagged with landuse=railway
• This area should be linked to a public_transport=stop_area relation.
• Objects tagged with public_transport=platform, railway=stop, railway=subway_entrance, landuse=railway, building=train_station and railway=station or railway=halt should be added as members to this relation.

This would be overcomplicating things by requiring a relation to understand the extent of a station, and is not what is done in many places. It would imply that 2 areas tagged with the same tag “landuse=railway” would be used for both, land along the tracks belonging to a railway, and railway stations, only differentiated by membership in a public transport relation, i.e. only applicable to public transport railway stations. You changed the current illustration in the wiki which ignores the possibility of a railway=station area, this is in opposition with the textual definition on the very same wikipage.

[gymate]

@dieterdreist

This would be overcomplicating things by requiring a relation to understand the extent of a station

@dieterdreist

It would imply that 2 areas tagged with the same tag “landuse=railway” would be used for both, land along the tracks belonging to a railway, and railway stations, only differentiated by membership in a public transport relation

Could you please elaborate on why this solution would be overcomplicated?
I don’t really see any other option to enable querying all infrastructure elements of a railway operating site. And if railway operating sites have a public_transport=stop_area relation including a landuse=railway area as a member which marks its boundaries (rendered exactly the same way by OSM Carto as a railway=station area), I don’t see the purpose of having an additional area tagged with railway=station.

@dieterdreist

and is not what is done in many places.

Only roughly 7% of correctly used railway=station tags are applied on areas. I see that it’s still a lot of objects, but my point is that the most railway=station tags (by far) are currently applied on nodes—including both reference stations on its Wiki page.

[gymate]

@dieterdreist

i.e. only applicable to public transport railway stations.

Yes, public_transport=stop_area is only applicable to public railway operating sites, but railway=facility can be applied on non-public railway operating sites:

@gymate

It says that railway=facility should be used for these operating sites without the type=public_transport and public_transport=stop_area tags.

[gymate]

@dieterdreist

You changed the current illustration in the wiki which ignores the possibility of a railway=station area, this is in opposition with the textual definition on the very same wikipage.

Yes, that’s because I also suggested changing the Wiki page to discourage applying railway=station on areas:

@gymate

and adjust all these tags’ Wiki pages to match the guidelines mentioned above.

But I’m open to any counterarguments!

[Kovoschiz]

1. landuse=railway can’t be used for underground, or elevated stations spanning other land. building=train_station is insufficient, and there may be multiple structures.
2. If you say a landuse=railway is “marking its station boundaries” , why shouldn’t that be railway=station ?
3. Why should public_transportation=station be restricted to points due to combination with =station and =halt for rail alone?

[dieterdreist]

I have never heard of railway=facility and it doesn’t have a wiki page, I am not sure what it is thought for, although it has 9000 uses (almost all on relations). https://taginfo.openstreetmap.org/tags/railway=facility#map

There are more than 7000 railway=station on ways, I do not see a benefit in discouraging its use, rather we should discourage representing something as big as a railway station, with often several entrances, fenced off etc., as a single node. What is the benefit of a node? I do not believe we need to enforce public_transport=stop_area relations just to be able to map the extent of a train station.

You can propose to change the system, but just applying the changes to the wiki is not the right way to achieve it, the wiki should document what is actually done, and railway=station areas are a valid and established way to map.

[Kovoschiz]

I have tried to use it in my country. But it is quite broken.

• Almost all (~98%) are with type=public_transport . =facility is then a duplicate with =stop_area + train=yes for the feature, and non-formal to type=public_transport randomly throwing in a feature tag.
• For the rest, all except 24 are either invalid lacking type= , a random type=railway , or a type=route mistake for some reason.

The latter should use type=site , but then railway=facility would be debatable. Either it should use type=site + railway=service_station as that is available, following power= (not exact comparable due to lack of point or area for distributed wind farms), heritage=, and =historic ; or site=railway following site=parking , to avoid duplicating railway=service_station , and posing as another railway= feature .
There is another railway=site that should be looked into. With dubious operating_times= that could simply be service_times= if not opening_hours=. OpenRailwayMap/Tagging - OpenStreetMap Wiki
Anyway, type=site can have label and perimeter that would facilitate representation. The point can be label . It’s not a must to bind certain feature tags to the object topology, as =station or =site for points, and =facility for relations. A railway=station area as perimeter could be interpreted as non-exact, or the broadest extent of the station.
For station, I tend towards using railway=station + public_transport=station for passengers, and railway=site / railway=facility for the rail operations area. There should be consistency with other public_transport=station , at least =bus_station on areas (=ferry_terminal is another mess). As for =service_station , I’m not familiar.
landuse=railway is a homogeneous statistical/taxonomic classification paint. It isn’t a feature. It needs railway=site / railway=facility or something to show what it is exactly here. Relating in =public_trasnport or =site only is not a complete solution.
Much of what OpenRailwayMap suggests can use some public scrutiny.

[dieterdreist]

I just reverted the recent modification of the image and put back the reference to the discussion here.