What makes you say pt=station and rw=station have to be the same node?
Id argue that one pt=station may have two separate amenity=bus_station and rw=station.
For one, it tends to be forced by iD (which will complain that a railway=station or amenity=bus_station is missing a public_transport=station) but for the other, many of these stations are functionally separate, having different names, IDs and usually separate operators (here in Germany, mainline railway stations are operated by DB whereas bus terminals are operated by the transport association, local bus operator or whatever depending which one is more relevant).
Iām talking about the diagram. This was also discussed before. Both =platform and =stop are currently used with the public_transport= counterpart directly. This uniformity would be lost.
Not saying this is impossible, but even with =bus_stop being used differently between public_transport=platform and =stop_position , =bus_station is kept with the =station . You would have a public_transport=station used alone without the modeās feature, although this might be envisioned by the public_transport= proposal. So perhaps paradoxically, this would be leading the adoption of standalone public_transport= features.
Different public_transport=station can always be related by =stop_area_group first. This doesnāt precludes creation of multiple public_transport=station next to each other.
That makes sense, I was looking at it from the wrong angle. Thanks for the clarification
Maybe running off topic, but what is the best-practice for handling bridges within the landuse=railway=station area? (Which will happen a lot when mapping to the signals) A multipolygon connected to either end of the bridge?
It seems to me that the diagram is already complete ā or very close to it. So Iām sharing the SVG file, along with a link to an editable version in the Figma online vector editor.
In addition to the ācomplete taggingā version, Iāve also created a version that illustrates simple tagging. However, Iām not entirely sure how relevant or useful the simplified diagram is.
Iād like to invite those who participated in this discussion to either update the diagram on the wiki or, if needed, continue the conversation and refine the diagram further. @stevea, @gymate ā perhaps the two of you could take the lead together from here?
Finally, I want to thank everyone who took part in the discussion ā I couldnāt have done this without your help 
4 Likes
These (latest) diagrams are an exemplary OSM achievement of thoughtful, patient consensus. They truly are beautiful and itās triumphant to reach this finish line. With more support (thumbs-ups, heartsā¦) for this most recent version, (that is, please add your support with an emoji as you agree that this version is effective!) we can confidently supersede the existing wiki entries.
I am distinctly honored to be a part of this process. With your āvotesā of support, these diagrams will become our latest pedagogical visual aids to better railway station mapping throughout our projectās data. Again, thank you to everyone who participates!
P.S.: I think the simplified version is great as it can be āvisually grokkedā by more-novice users who donāt have to āeat the whole meal.ā When the simplified version nourishes as a ālight meal,ā the more-complete (yet, not fully complete) version can deepen understandings.
1 Like
Sureāthank you very much for your work so far! 
1 Like
I think it is also very much related to mapping philosophy:
- Most of the current
railway=stationareas do not represent actual station boundaries but areas open to passengers. If we were to redefine their meaning, weād instantly get 6,751 invalid usages. railway=stationis currently tied together withpublic_transport=station. Usingrailway=stationfor marking their boundaries would require a change inid-tagging-schemaso that iD would only suggest addingpublic_transport=stationtorailway=stationnodes, not areas.- Having two tags for describing railway station boundaries (based on the location) is an unnecessary complication in my opinion.
1 Like
Tipping my hat to you @gymate as you field our vast system of rail semantics.
We have (all together) said a great deal here. Might we say āthe latest two graphics go a distance to improveā and promote them to wiki? Add a link or three from there to here, and we now have a novice-intermediate-friendly introductory graphic with stunningly effective use of color to introduce. Plus our latest solid work that both looks great and describes a lot quite well. Tip of the iceberg and āmoreā of the iceberg and yes, the latter has a question mark or so about it. There are some additional platform_edge semantics, described elsewhere, omitted on this āmiddle levelā diagram (not the whole enchilada of railway=station semantics), so that would do with some explanatory wiki text, of course. And so on. There are dozens? of authors and feathering of edges that are āstill trueā about how we describe these. Itās complicated, weāve talked about it here for a year and a half. This Discourse topic captures a lot, itās awesome.
Letās herd cats. Everyone, letās promote these latest two graphics to our wiki, with some good links to here (there remain many salient points-to-be-noted) with some brief text that some cleaves and not-fully-resolved edges continue. Iāll call these diagrams 99% to 100% (for now) and they pedagogically rock: OSM does mean to teach these concepts well, these diagrams do that. Letās see them on our wiki, huh? Fireworks want to be free.
Edit: Semantics visually described are not an exact be-all and end-all. They are pedagogical.
Sure, go ahead! But we need to discuss the railway=station vs area:railway=station issue anyway.
Iām interested in your thoughts on the points I mentioned in my previous comment.
Sure, go ahead! But we need to discuss the
railway=stationvsarea:railway=stationissue anyway.Iām interested in your thoughts on the points I mentioned in my previous comment.
typically in OpenStreetMap, we distinguish between linear objects and polygons, and reduce the latter to points if they are either very small or when we want to denote a ācentreā explicitly (and in this latter case, in particular with admin and place, we have a method to combine area and point, but we keep using the same tags, e.g. a place represented as an area has the same tag as one mapped as a point). There is no requirement to specify an āarea:-prefixā because the geometry already implies it.
The only context where we use area: prefixes is with highways, because these are linear objects, and we need to distinguish between linear highways and area highways.
I agree that both are carrying distinct information, polygons and points, but if we were to come up with a solution to map both for the same object, we would rather want to have the possibility to map several points to the same area, so we can map different access points (entrances, gates etc.) for the thing. This is not limited to train stations though, it would be useful for other big pois as well, e.g. airports, universities, ultimately every poi with several entrances.
Huge respect all around; we are heroes together. I offer my perspective re-affirming there are other perspectives (on this large topic in our relational database). With the simple diagram, we use color as blue and green to distinguish different syntax as differing objects, tagged similarly. Everybody can agree to it. It pedagogically rocks; crackle-boom.
Now, simultaneously, a pink landuse thing is going on, too (we render its edges and boundaries, we model with signals and edges of ways in OSMā¦). Not either-or, this is both. Pink AND blue; blue AND green. Yellow as a visual relation call-out. As simultaneous differing concepts. Sometimes syntax shares across things, like railway. A deeper diagram visually groups in geometry and logic as syntax with color. Boom.
The ? is there to denote that the area: prefix, while it exists, is a meta-syntactic method to call out something exceptional or at least different. I see how both can and do exist. There isnāt always a pure āthis method is always correct.ā With these diagrams and bouncing back to further wiki if need be and brief wiki pointing back here, OSM draws a certain-sized box around this (snapshot for now). As two pretty diagrams in our wiki, with some links back here many might say captures 99% or 100% of the spirit. If we must put a number on it. I nod my head.
For now. I call it a wrap!
When I attempt to upload the new .png image(s) to the wiki, I get an error
āFile extension ā.svgā does not match the detected MIME type of the file (image/png).ā
I have had similar trouble before uploading to wiki(commons), I have also had success. I canāt figure out what Iām doing wrong, so any help uploading the new documents (both of them, the āmore completeā version and the āsimpleā one), I would appreciate that! Thank you in advance to anybody who can assist.
It seems the upload issue might have been caused by a mismatch between the file type and extension ā for example, if a PNG image was being uploaded under a .svg filename, the system would throw an error.
In any case, Iāve uploaded both updated diagrams as new versions of the previous files. Iāve added myself and andygol to the list of authors for helpful feedback, software tips, and the idea to improve diagrams with accessible colors.
Many thanks to everyone who took part in the discussion!
https://wiki.openstreetmap.org/wiki/File:Railway-station-tagging.svg
https://wiki.openstreetmap.org/wiki/File:Railway-station-tagging_simple.svg
3 Likes
Applause, everybody! Applause! These diagrams here and now are sweet. I or others can dress them up with minor wiki fiddling as appropriate. Applause. (OK, Iāll stop applauding now).
I hereby declare my (and @gymateāsā¦) very recent wiki-fiddling (truly minor) defining the simple and up to āMore completeā diagrams to be ārailway=station Diagrams 2.0.ā
Chefās kiss, mwah. These are so pretty, effective, shared as ours; cool. Congratulations, OSM.
1 Like
This is a legacy practice because OpenRailwayMap does not work with railway=yard on areas. I am in the process of updating railway yards in Mexico to railway=yard on an area which is the perimeter of the yard.
Regarding the main topic of the conversation:
- Railway stations are inherently areas and should be mapped as such.
- Rendering software should not arbitrarily add a node for stations mapped as areas.
- Good practice for mappers is not to add a node in the ācenterā of the station.
Railway stations have spatial extent, just like supermarkets, power plants, etc. do. Would it make sense if a map rendered a node for power=station? No. Would it make sense if we always mapped power stations as nodes or added a node to the ācenterā? No. Neither it does for railway stations. The displayed node is a spurious artifact of OSM Carto, not something we need to acomodate in our mapping scheme. We already have building=train_station and railway=stop to mark the part that is of interest for passengers.
There is an exception for low zoom levels only: Given that areas effectively become points anyway, it is fair for a map to display areas of interest as points, this being computed, not stored in the database. If for some unknown reason we needed to precisely define the location of that point: let it be the barycenter of all building=train_station areas within the railway=station area.
1 Like
The two diagrams and two lines of text (five sentences) in the āOverviewā section of our wiki (where these diagrams liveā¦including the āmore completeā one as now referred by many other multilingual wikis) succinctly capture these ā1% of edgesā (of the semantics the āmore completeā diagram displays).
So, indeed, we continue discussion on the topics of railway stations being primarily areas (areas defined by landuse=railway + railway=station or perhaps public_transport=station). Though, we do have the diagram display that nodes can āalsoā be tagged railway=station or areas / polygons can be area:railway=station without specifying (in the diagram) these are legacy, rare or exceptional cases.
The diagrams improve much but they do leave this particular 1% or so a bit ambiguous, with a few brief sentences of explanation immediately below them. We have ānailed it upā for now, but the paint is still a bit wet on that / those specific topics.
So, I offer my thumbs-up of agreement to @Ferrocarriles_de_MĆ©xico 's post just above this one.
Edit: I think 100% of OSM can agree the āsimplifiedā diagram is 100% correct. I think the āmore completeā diagram being 99% (or so) correct and agreeable by a great many of us getting us to 199% correct out of 200% of diagrams is āpretty good.ā For now. Discussion continues!
You can try to read through the āconversationā first. The fundamental disagreement is about public passenger area vs much larger and restricted rail operations area vs linear referencing point. The centroid/label/target for rendering and routing comes afterward.
=train_station only covers buildings, causing public_transport=station to be discussed as its own area enclosing the grounds and parts outside (and exposed platforms). =stop doesnāt work for linear referencing at bay platform terminus stations, which were preferred by proponents to be a point at the end of the platforms.
5 Likes
Thanks for your delightfully pithy words. I updated Talk:Railway stations - OpenStreetMap Wiki to point here (in addition to the footnote in the page, and to look at the Talk page).
We seem to have contained current unresolved issues / disagreements in a smallish box, though I donāt know if it gets easier to further refine!
So Iāve read the thread a bit and just wanted to quickly mention, that this is a good idea for smaller stations like halts. It may not work the best for bigger stations though, as the exact area can be heavily disputed. Thatās up for debate though.
The idea of area:railway=station is completely stupid and is not at all what area:highway=* was going for. It really just seems like tagging for the renderer. The actual fix to this is either not caring about rendering or implementing a new centre role for untagged nodes in multipoligons ā if that would even be usable for software. Iām not going to go into too much detail right now.
I have a question about whether or not railway=station should be used on multipoligons. Let me show you my issue:
https://maps.app.goo.gl/3uogt76Kw7nMQHfM6
Right here Iāve got a halt which has platforms on both sides of the road. Would it be okay to use a multipoligon with two outer areas containing a platform and tracks so that it excludes the highway? I really wouldnāt consider the road as a part of the halt.