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.
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.)
Thank you very much for pointing it out, I was not aware of that discussion!
The decision there was the following:
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
andrailway=station
orrailway=halt
should be added as members to this relation.
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.
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_area
s 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.
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.
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
andrailway=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 withlanduse=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 asrailway=station
orrailway=halt
is (see Budapest-Kelenföld).public_transport=stop_area
—together withtype=public_transport
—is applied on a relation and used for grouping all objects (incl. objects tagged withrailway=*
orlanduse=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
(withoutpublic_transport=stop_area
andtype=public_transport
) is applied on a relation (see Braunschweig Rbf) with the same kinds of members.
- If the station is not public,
public_transport=stop_area_group
—together withtype=public_transport
—is applied on a relation and used for groupingpublic_transport=stop_area
s 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.
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.
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
.
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.
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:
Yes, that’s because I also suggested changing the Wiki page to discourage applying railway=station
on areas:
But I’m open to any counterarguments!
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.- If you say a
landuse=railway
is “marking its station boundaries” , why shouldn’t that berailway=station
? - Why should
public_transportation=station
be restricted to points due to combination with=station
and=halt
for rail alone?
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.
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 totype=public_transport
randomly throwing in a feature tag. - For the rest, all except 24 are either invalid lacking
type=
, a randomtype=railway
, or atype=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.
I just reverted the recent modification of the image and put back the reference to the discussion here.
I think railway=station
and railway=halt
have the important role of indicating the non-geometric, practical centre of a railway operating site.
Let’s take the small railway club station Sprockhövel - Haßlinghausen for example, currently mapped as a railway=station
area:
(Platforms there are incorrectly tagged as railway=station
areas but it doesn’t make a difference in demonstrating the effects of rendering objects tagged like this.)
OSM Carto renders the station marker at the blue square and iD shows its pictogram at the orange dot. But the practical centre of the station is at the green dot.
I don’t think about this as an issue for smaller stations like this, but when you take Berlin Hauptbahnhof for example—with a shape similar to Sprockhövel - Haßlinghausen’s—problems might start to emerge: the station marker might be rendered away not only from the practical centre but also from any public area of the station, making the marker less helpful.
In the case of Berlin Hauptbahnhof (copied to OpenGeoFiction as a railway=station
area) the marker would be rendered somewhere at the western end of the platforms:
Therefore I think the only practical solution for mapping railway=station
and railway=halt
is applying them on nodes. @Nakaner, spth and @rurseekatze came to the same conclusion at the OpenRailwayMap Mappingwochenende in 2014:
Thank you for pointing this out! Although both versions (1 and 2) of the illustration only depict a simple railway station, I see your point.
I think in the case of elevated stations e.g. man_made=bridge
could be added to the public_transport=stop_area
or railway=facility
relations even if they span greater than the station boundaries.
And underground station boundaries could be mapped as an area tagged with tunnel=yes
and area=yes
, also added as a member to one of those relations.
Regarding editors’ competencies about using relations at railway operating sites, I can only agree with @Nakaner:
That’s also a good point, thanks! The approved tagging of public_transport=station
says the following on its Wiki page:
If a station outline is not known, the station can be mapped as a node, leaving the details to others.
So this means that the tag can be applied on nodes only if there is insufficient data for mapping its whole area. (Unfortunately that’s not the case in reality, because currently only 22% of valid applications of this tag are on areas—but let’s put this aside.)
When public_transport=station
is mapped as an area, it should cover—as I understand its Wiki page—the public area (incl. public amenities) of the railway operating site. Therefore it should be mapped the same way as the dashed purple line on this illustration:
Regarding railway=facility
: I agree, landuse=railway
does need a parent relation (public_transport=stop_area
or railway=facility
) because only that relation and its other members (e.g. a railway=station
, railway=halt
or railway=site
object) can indicate what exactly is in that area. That’s what I suggested here: