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!
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.landuse=railway
is “marking its station boundaries” , why shouldn’t that be railway=station
?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.
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.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.
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:
Did you mean adding landuse=railway
to a public_transport=stop_area
or railway=facility
relation as a member?
If yes, could you please elaborate on why this wouldn’t be a complete solution for marking overground railway operating site boundaries? Thanks in advance!
I totally agree—that’s why I posted my intentions here first and waited 12 days for further comments before restoring and updating the old tagging scheme on the Wiki page. And I’m happy to continue the discussion about it.
Although it doesn’t have a separate wiki page, its usage is described on the OpenRailwayMap tagging page, which I cited here:
The man_made=
=bridge
or =tunnel
structure won’t be exactly the same as the station operation area. It could be much longer in most cases.
label
, and building=train_station
or railway=subway_entrance
can be shown to the public; or another feature tag eg railway=site
can be changed to be usable for the operation area. The former is the same situation as how routers have trouble with finding where to go for other all other features, requiring entrance=
, =parking
, and even a new Key:routing:entrance - OpenStreetMap Wiki inside. The size and completeness of the entire station shouldn’t be compromised in favor of rendering, routing, or other applications.
Yeah that’s a good point (take Haliç for example).
Fair enough—in that case I agree that instead of landuse=railway
(or anything else) railway operating site boundaries should be mapped as an area when possible, with one of the following tags:
railway=station
railway=halt
railway=yard
railway=service_station
railway=junction
railway=crossover
railway=spur_junction
railway=site
This also means that the Wiki pages or sections of the tags marked with links above need to be changed to allow applying them on areas.
Just to mention: this also results in OSM Carto rendering railway operating site areas’ name not at the practical centre of the station, as mentioned above. I think this could be solved by also rendering public_transport=station
on OSM Carto, which would indicate the practical centre of the station. (Note: this would also result in rendering the name of a station twice, if both the railway operating site and public_transport=station
is mapped as an area. Maybe checking if the public_transport=stop_area
or railway=facility
relation the railway operating site area is a member of has a public_transport=station
object could help—because in that case rendering the railway operating site area’s name could be omitted.)
So, taking this and the usage of public_transport=station
in account, I suggest the following updated tagging illustration for a simple station:
Sorry, I need to clarify I want to use railway=station
+ public_transport=station
for the passenger area , to follow public_transport=station
in other modes . That’s already dominant railway=station | Tags | OpenStreetMap Taginfo close to 75%. It’s not a good idea to separate them. No other mode has a public_transport=station
alone without the corresponding feature.
railway=site
currently for points only should be changed to be usable for the operation area, replacing railway=station
in this use.
I don’t deal with freight, but I believe there can be =yard
in stations? Notably Tag:railway=yard - OpenStreetMap Wiki Russia has "yards which are parts of larger station. " . Then what should the operation area use, assuming there is only one including both the station and the yard?
The needs of general and technical usage should be balanced. A specific tag can be used for the specific purpose of operation area. It’s not a must to modify =station
or =yard
to fit it.
Again, I will emphasize label
in =site
or type=label
can be used for the meaningful and representative centerpoint if needed.
As for =junction
and others, they are fine.
The existing =facility
relations structure should be cleaned up. It’s invalid to have railway=facility
alone without a type=
for non-passenger ones. That’s undefined behavior. Either at least the type=railway
in use should be defined similar to type=power
, or ideally type=site
(+ site=railway
/ railway=site
) should be used directly. Why not limit the =yard
to the actual loading & unloading and sorting area?
Whoever suggested adding =facility
to type=public_transport
is still wrong. Aside from modifying the syntax of type=public_transport
without clear consensus from the transit side in public, railway=signal
etc operation devices are not relevant to transit for passengers, and =stop_area
can include other PoI eg in amenity=
that has nothing to do with rail operations. (railway=subway_entrance
is arguably not related to rail operations either) They can be kept separate. This is not redundant.
I think it is a good idea indeed. The Wiki page of railway=station
says the following:
railway=station should be tagged as a node, placed at the centre of the station from the passengers’ point of view (i.e. near platforms), or as an area covering the whole station.
And the Wiki page of public_transport=station
says:
A station will normally have some, but not all of the following attributes:
- Have a physical presence consisting of a building or other structure […]
- Have a number of platforms and stop positions […]
- […]
- Have amenities for waiting passengers including shops, vending machines and information services and possibly car parking […]
- […]
The station itself is mapped as an area, usually covering the outline described above […]
So railway=station
should cover the whole station (from a railway infrastructure perspective), but public_transport=station
should only cover the public area of the railway operating site.
I agree, but train=yes
applied on the same area as public_transport=station
is could indicate that it’s a railway public transport station.
My bad, sorry, I didn’t understand it at first! Good idea—I agree that a label member of the relation should be used to render the station marker at the correct location.