Railway=station as an area?

The DE:OpenRailwayMap/Tagging Wiki page was mainly written by @rurseekatze in 2012. (That page was translated later in 2014 to create the English version.) An RFC was posted here…

…but no questions were asked about railway=facility or railway=site yet, so we might ask: @rurseekatze, could you please tell us your thought process on these tags (and also your opinion on the things above) now? Thank you in advance!

As we unfortunately haven’t got a reply, I’d like to propose the following updated tagging scheme (illustration) as discussed above:

Please let me know if I’ve made any errors or missed something!

1 Like

There is a lot to take in looking at that diagram, and it is hard to follow which combinations are valid. Would it be easier to have two diagrams, either:

  • mapped mainly as nodes v full area mapping, or
  • station with public transport v non public.

It is not clear from the diagram what railway=facility represents - as shown it appears to be redundant with railway=station, as all the members of railway=facility seem to be inside the railway=station area. Or is railway=facility meant to be used when railway=station is a node?

Minor points (and I realise these are probably inherited from earlier versions) : Is there any significance to showing ref= on platforms but local_ref on stop positions? Or to showing name= on stop positions but not on platforms?


As a long-time (14 years) OSM rail mapper, I rather like @gymate’s diagram, though I agree it is fairly complex for beginner-level mappers. It could suffice for advanced mappers who know rail mapping in OSM well, but for beginners, I’d like to see (here, please) what two diagrams that are nearly identical, but one without relations and areas (which could suffice for our “simple railway station” diagram) and the one above, with relations (as more comprehensive, but no longer really “simple”). Also, maybe “mapped mainly as nodes” vs. not. Somewhere, it should be made clear that some elements are optional and some elements do not apply to “not public_transport” flavored stations. The use of color is good, perhaps this can be extended (for optional elements) with additional colors.

I’d make two small tweaks: for both relations, swap the order of type and its first-line companion so that type=site and type-=public_transport come first. (Because a relation’s type is primary in defining what the relation is). Other than that, IMO it’s an excellent diagram, though, it is no longer “simple.” Maybe for the full, comprehensive diagram, we change the word to “generalized.”


type=site + railway=facility for including all rail operation devices is the counterpart to type=public_transport + public_transport=stop_area which includes all public-related features of the station. The railway=station area is the rail operation area of the station (including switches and signals), while public_transport=station area cover only the passenger area with platforms. If the station is not public for passengers, the railway=station becomes railway= =service_station, =yard, or something else.
railway=stop + name= + ref= is representing the stop on the track in the network, so local_ref= is used for the track/platform number of this stop in the station. This is similar to highway=bus_stop , with the difference in whether they are combined with public_transport= =stop_position or =platform .
platform= is considered to be associated with the stop and station. The ref= reflects this local standing.
The practical reason is train stops and bus stops in reality usually get a unique code, and identifiable name in the network level. Platforms don’t, and are only relevant inside the station.


This is a rough-cut and should not be used as-is, as it has hatch marks from my sketch software and my roundrect in green is not “the” roundrect (shape). But I try to be more explicit with color, add notes from @Kovoschiz and “it is getting closer.” So, @gymate, if you want to build from here or wait for further input, at least here is one more nudge towards a finish line:

Really, everyone, we’re nudging here. It’s all chalk and watercolor now, so please touch-up (or even slop on some new paint wholesale) what needs doing. And oops, I see I should have chopped a few more pixels off the right-side edge. But you all get my ideas / suggestions here, I take it.

Edit: 3rd footnote (§) might have its public_transport=station text be pink, not red; I think so, not sure.

The systematic use of colours is helpful.

I think perhaps the box for public_transport=station mapped as an area should be red? And ideally the box where public_transport=station and railway=station are together (for mapping as nodes) would somehow show both red and pink.

I am still unsure what the railway=facility adds on top of railway=station if the latter is proposed to include non passenger facilities. I suppose I don’t fully understand stop_area either. My interpretation of stop_area is that it is important because the station is usually a node, so there is no spatial relationship between platforms/stops and a station (or each other). Would it be fair to say that if all railway=station and public_transport=station were mapped as areas, we wouldn’t need either stop_area or facility relations? Or do they serve some other purpose I am missing?

1 Like

Yes, another “wobbler” I wasn’t sure whether should be pink or red, but red seems more correct for the color of the box, the color of the text and the color of the dashed-line geographic extent around the public_transport=station (if mapped as an area).

I don’t know how to visually convey the combining you suggest for stations (station elements of a relation tagged type=public_transport AND railway=station as a node), especially “both red and pink,” but I do see why you might want to do that. However, I’m not sure it’s a good idea, as while these are both (named) stations, they really are fundamentally different things (one is for passengers, the other is for passengers + rail infrastructure like signals).

Your second paragraph I will leave for others to address, while I thank you for adding it.

Also, the “Green = landuse” line should additionally convey “Blue = route=train relation elements.”

Nudge, nudge.

it looks quite good and the colors work to make the thematic grouping easier to understand, still I think it would be even more understandable if the same tagging (as node and area) would have the boxes directly adjacent (e.g. railway=station mapped as node and way is on opposite sides of the diagram, would better be close to each other).

The idea to have 2 diagrams, a “mapped-as-node” and “mapped-as-polygon” version, also sounds interesting to me, although I think it isn’t obligatory and could be understood with everything in a single diagram as well.

Yes, they do serve a purpose. In short: railway operation related objects in a railway operating site are only a subset of all objects that a railway=station area covers, not to mention multilevel stations. (The same analogy applies to public_transport=station.)

We talked about it (among others) here, here and here in more detail.

I would rather prefer this method due to better maintainability:

But we’ll see how it works out.

Thank you very much for all the suggestions! I’ve made the following adjustments to the illustration:

And @stevea, thank you very much for the illustration! This made it much easier for me to understand your ideas.


So I’d like to propose the following tagging scheme illustration updated with your suggestions:

I’ve also made a simplified one hiding all objects in the illustration that depict optional or complex tagging methods:

I didn’t add the title and footnotes in this illustration because I think it’s the Wiki page’s job to explain the tagging scheme, the illustration only extends that. (I also intend to edit the Wiki page accordingly.) And I think that colors don’t really need an explanation on the illustration as they’re just visual guides for grouping tag categories, but they could be featured on the Wiki file page.

Please let me know your thoughts on these!


Lookin’ really nice. Offering a thumbs up to both of these diagrams, though if others want more or different, I remain listening.

Edit: If I may offer an “editorial preference” of mine, let’s call it, when presenting these graphics in our wiki: the simple one first, then some text, then the “generalized” (more comprehensive) graphic secondly.

It’s pretty neat how the “a picture says a thousand words” adage conveys to our minds in this case. Again, the colors as semantics are a little fuzzy between red and pink, and I hope it is made clear somewhere that blue is for route=train relation elements, but yes, the colors now better carry a nice load visually.

First graphic becomes a newer “simple railway station as a node.” Many, even novice mappers, with a once-through tutorial perhaps, can walk through this. The second graphic might be titled: “more generalized, with multiple themes” leaving this the wet paint that it is right now. I think only minor touch-ups ahead, but I could be wrong. I don’t think we need any wholesale reinvention of this wheel. I’d say we install these graphics in our wiki as their paint dries.

I offer claps on the back to all and sundry who accept claps on the back at a job well done.

1 Like

One more bubble (roundrect, with black text and blue text) I think might properly finish this: could we add

relation: type=route and route=train

with relation: in bold black text and the rest in blue?

Right above the red public_transport=platform (etc) roundrect?

Could fit on a longish single line (“extending east of the red signal”), maybe better two lines of text (with a touch more vertical dimension) to remain consistent with the other two relations with similar notations (in bold). I lean towards a two-liner. It could also cleverly be tucked in at the bottom or far-left corner and maybe bottom. Do-able, but what do others think? This relation (route=train, and the way stops are tagged, and train=yes…) means we should say this explicitly somewhere, rather than implying it. And this format keeps it regular, and black and blue, making sense to me, at least, “completing the picture.” (Like 99 to 100%). “All the syntactic aspects are shown.”

you should remove railway=facility, it doesn’t even have a wikipage, wasn’t proposed and has no clear meaning, it covers the same area a railway=station, and the same key make them incompatible.

1 Like

railway=facility is used on the type=site for rail operation devices. We have discussed the existing railway=site used on points, and site=railway . What do you suggest instead? I don’t like it the most either. OpenRailwayMap/Tagging - OpenStreetMap Wiki

1 Like

Yeah I was thinking the same!

Good idea!

Yeah I see your point but if we would add a description box for type=route & route=train

  1. we should not point to one random (any of the 3) railway=stop dot but two of those dots (on tracks 2 & 3) because the one on track 1—which is a side track—would usually not belong to a relation of this kind,
  2. tracks 2 & 3 should also be marked with a blue color because those should also be added as members to this relation,
  3. we should also mention these tracks in the text box as members added to the relation,


It’s doable but I think it would clutter the (already) complex illustration too much. And I believe the type=route & route=train relation’s main purpose isn’t about infrastructure but rather services provided on them. So I think that this addition wouldn’t really be a good idea.

railway=station, railway=stop, railway=halt etc. were not proposed yet either. (It would be a good idea to propose them though!) But I think this doesn’t mean we can’t use them.

I believe it does have a clear meaning: a relation which “groups” infrastructure elements of a railway operating site together.

It does not cover the same area as railway=station as it is only an abstract relation which has a railway=station node or area among one of its many members.