Railway=station as an area?

The railway=station associated with landuse=railway is not an “element” in the same sense as how we DO mean “element,” as it properly associates with the node denoting the location of the station. In the former case (on the landuse), the tag is an adjective, not a noun. In the latter case (on the node), it is a single tag to denote a noun. In the latter case, it IS “one feature, element.” In the former case, it isn’t, as it is a “modifier,” not (strictly) denoting an “element” (as you mean it here): it’s the landuse=railway tag that is doing that there.

I gotta go!

That I’d support. Map the whole railway area as always and draw the area:railway=station as an outline, a station boundary if you will.

1 Like

Thank you for submitting it—it’s a great way to spread the news about this discussion! :slight_smile:

(Just a small remark: it would’ve been great if the newsletter mentioned that the illustration is still a WIP, especially that it could and did become the headline graphics.)

1 Like

I see your point, but unfortunately railway=station can’t be tied to the landuse=railway area in all occasions.

See Ferencváros station where I mapped its boundaries—in agreement with the local community—with an area:railway=station. The area crosses over roads at 5 different places and the vicinity of those roads have a landuse other than =railway. So I had to make a separate area for the boundaries of the station.

Therefore—in my opinion—there is still a need for a separate area:railway=station tag.

Unfortunately, the latest weeklyOSM has already been released, so it won’t be possible to clarify this there. However, I believe that those who follow the link and take an interest in the discussion will see that it’s still very much ongoing.

Currently, in the latest version of diagram, the station area is tagged with railway=station, but that’s simply because I based it on the most recent version of the diagram from the wiki.

If the discussion leads to a common agreement soon, I’ll update the diagram to reflect that. If the discussion takes longer or fades away, I’ll publish the SVG files here so that our shared work isn’t lost and can be picked up again later.

I’m truly grateful to everyone for their valuable advice and for taking part in the discussion. I really hope we’ll find a good shared decision!

1 Like

I also see your point. Although, the fact that this vast area — well, let’s agree it certainly is lengthy — (for the area of a single railway station) needs a tag modifier like area: seems less related to railway specifically than it does to the specific problem (here) of “five different places and the roads in that vicinity having multiple landuses (other than railway).”

So, I don’t like area:railway very much, but I can see how in this specific case, it is a working solution. (BTW, I’ve been to Keleti and Deli, but never Ferencváros).

In my opinion (one person’s only), I say we choose to keep the diagram in its penultimate iteration (“signals smaller and removed the colors”).

But:

  1. We can (and should) certainly mention that in specific cases (like Ferencváros, and we can link the multipolygon in our wiki just like @gymate does here) there may be specific, local, other cartographic reasons to use an area:railway tag for some circumstances. Let’s make sure the wiki documentation makes it clear when this is and is not appropriate. In short, I’d say area:railway is a possible tag as an “exception,” but the diagram(s) are “the rule.” (I use the plural because we’re also going to see the “simplified” version, too).

  2. Regarding platform_edge, despite it making a railway=station “more complete,” I don’t think this diagram can properly do it justice. I mean, as I look at the (newer) diagram with that feature, it isn’t clear that the “edge” is a specific part of the closed-polygon way which is right next to the track (one out of the four segments that make up the rectangular closed way). Honestly, I think we need an altogether different diagram to properly visually denote railway=platform_edge. We should graphically convey this, of course, (and do) but not here, as it really does make our “full sentence” become a “run-on sentence:” one which tries to say too much all at once.

Maybe we have some text around the diagram (nearby, associated with it) that points to area:railway and railway=platform_edge documentation, but “not here.” I once tried putting about six kilos of sugar into a five-kilo sack, and I spilled a fair bit of sugar. Same here: the diagram as of “signals smaller” is visually “at capacity.” A full sentence, one that is like a full meal, from appetizer to dessert. Chef kiss!

Again, this is an awesome collaboration!

1 Like

@dieterdreist, what’s your opinion on it?

While I agree it looks “cleaner” and simpler, this comes at the expense of not explaining well where railway=station should be drawn. It doesn’t show the whole station and the delimitation between railway=station and outside the station is hardly visible. It only works if you draw the node and refrain from the area (and it doesn’t hint at the fact that node and area are alternatives).

1 Like

I think it must be said (either for the first time or maybe you already realize it) that this diagram is not the entirety of a railway station, nor “the area around it.” For that latter meaning, I put it in quotes because in the case of how a station fits into the context of its landuse, it works perfectly. However, in the case of how a station fits into a larger area, with relatively complex landuses that might not allow such a “clean, simple” denotation, we can / should / will say that an area:railway tag might very well work. (We don’t do this in the diagram, but that will be readily apparent with an asterisk or “close-by” documentation).

@dieterdreist, f you have a visual methodology for hinting or actually denoting that the node and area are alternatives, I would love to see that! (Even describe it, as @darkonus is amazing at converting your words into images). Otherwise, let’s toss up as “too hard” solving the problem of letting a diagram further delimit “outside the station.” (As personally, I’m not really sure what you mean by that or how much detail you would expect a diagram — not this one, as it’s “enough” right now — to visually describe).

A diagram can describe “just so much,” and we must let other diagrams and other chunks of text offer a wider context, potential solutions to sticky cartographic problems for which the “best” diagram just can’t go any further, but words can, or subtle, tangential issues that are outside of the scope of the instant diagram, but which offers a context to describe those corner cases.

To summarize, I think we’re pretty close, especially as we keep the “signals smaller” diagram and use other diagrams and chunks of text to further describe.

Jumping in midstream here - the new station graphic is fantastic. It caught my eye on the osmweekly post, as I often refer to the old wiki graphic when tagging up railway stations. I coincidentally came across a railway station with a couple of obsolete tags this morning and decided to take the graphic for a test drive. I found it much clearer and much quicker than the old graphic. (As a relatively new mapper I’m not familiar with some of the more established patterns which underly the old graphic).

My only note to the graphic would perhaps to mark the roles of the elements in the stop area relation. This is a point which often slows me down - having to look up which roles for which relation. Not to overcrowd the graphic, but perhaps the role tags in yellow text by the elements which need them? (I’m jumping in late so feel free to ignore the suggestion if it doesn’t suit).

Regarding the landuse=railway=station - is it really standard to extend the station area to include the signals? This would often make even small stations many kilometres long which feels unintuitive to me. The station I tagged this morning I extended the station area as far as the platforms. Going to the signals would have included at least 2 bridges and whatever else along the way.

Thanks for the effort in creating the new graphic, it will make mapping stations significantly easier(at least for me!)

1 Like

Another update to the diagram: I made it a bit taller and tried a more elegant way to show railway=platform_edge as an experiment. If people here don’t like it, I’ll remove it. I also added a description of the stop_area relation members. Looking forward to hearing what you think! As always, I’m in no rush and can easily roll it back if needed:

1 Like

… and, after some suggestions from @tordans in a comment on a post in my diary:

Visual feedback: I did not understand the relation part the first time I read the diagram. Suggestions: - remove the yellow line from the relation info box to the object and rely on the border color only. Or add a line to all the objects that have a border. Having only one line suggests that this is a info box for only one object. - write out the „RELATION“ kind next to the icon or replace the icon. The icon is too obscure for inexperienced users. - does „all public members“ mean „only add public objects in the given are as members“?

1 Like

The diagram does get more complex, the diagram does get more complete. There does come a point where we truly must say “enough is enough.” I thought we were there a couple iterations ago, but maybe (figuratively speaking) with a bit of a burp and digesting these new, most-recent features, we are at a tippy-top of “enough is enough” with this diagram.

I still don’t quite understand how railway=platform_edge is described by this diagram, meaning I would have to go look that up and view another diagram to visualize the specifics of those. So, maybe not, but others might like this, I don’t know.

I welcome more input (for example, strategies on how to describe that an area:railway tag might be needed in complex landuse cases…), but I would find additional features / more additions to be “simply too much.”

Again, we are pretty close, but I personally would like to see the opinions of others as to the effectiveness of this (latest) diagram. Personally, I find it “one course too many in the chef’s wonderful, though very full meal” (or a run-on sentence, take your pick), but now that @tordans has what he likes, he offers a thumbs-up. That is understandable (I was happy when I saw my features there, people get happy when they see their features…), but the question remains: are we all happy with this (latest) diagram?

Maybe one additional question remains: I honestly don’t know the answer to @TangledRockets question about the true extent of signals defining landuse. I assumed that was true (and it seemed to be so with a couple quick checks I did), but there may be (much?) more to it than we have diagrammed here. Still, I like the simplicity of this, and if there are rare corner cases, we should “leave as is” and note somewhere else that there may be exceptions (like Ferencváros).

I appreciate the diligence of all who participate and the spirit of collaboration here, it’s wonderful!

1 Like

=multipolygon isn’t quite necessary. I won’t recommend showing it, unless you are drawing the voids (stairs, escalators, elevators) together.
The =platform_edge lines needs to be contrasted more. Either thicker, or different color.
If this is too tiring, you could share the source file. Let anyone try to edit a version out.

2 Likes

I would recommend doing so. Otherwise, there is no way to tell which tracks, switches and signals belong to which station.

Well, that’s their actual size. As passengers see it differently, their perspective is represented with the public_transport=stop_area relation and the railway=station node.

2 Likes

@dieterdreist, I meant: what’s your opinion on the comment below?

Thanks to @TangledRockets, @stevea, @Kovoschiz, and others for the thoughtful insights — they’ve been really helpful to me. For now, I’ve decided to step back from trying to visualize platform_edge in this diagram.

In this new iteration, I’ve tweaked the spacing a bit, added a visualization of the unresolved railway=station versus area:railway=station issue, and tried to make the line from the relation callout to its intended member objects a bit thinner and more elegant.

2 Likes

Personally, thought you had the PE in well but maybe having that edge a with little more highlighting where that edge is… only on the long side where a train side doors opening side is, not on the short sides.

NB rereading the PE wiki, missed to see an instruction in what dierection such an edge has to be drawn so the data consumers know where the platform side is and the lower side, same as for kerbs, retaining walls, cliffs and probably a few more. Maybe it’s not of interest at all… it’s a rail side edge and it has a ref=*.

/EOD (End Of Derailment)

1 Like

@SekeRob , I hear loud and clear that PE is indeed as you describe, both a thing and a thing with a certain chewiness and depth. Like other discussed (and more we didn’t, for sure) some less-frequent corner cases for the sake of brevity to a certain degree (burp) this diagram is at such a fullness that it might burst at the seams. It is a lot without being too much for those who allow the fireworks to display into neurons of understanding. It does that for me. It is both pretty and helpful, it has some wow to it like that.

Let’s recall that this diagram (and its soon to exist companion of “simplified”) lives in the context of our wiki, effectively its lede image. It intends to visually convey. I think it does that, even as 14, 15, 16… concepts provide a full visual meal. We know that even from this stage of graphic expression (that of @darkonus), OSM can’t really convey visually the full complexity of such things, our map data do that. We are showing “how” certain things are “tied together.” There are fireworks of understanding going off as people see this. Thumbs up, I’m nodding my head, @gymate offers a heart; köszi!

As this Mct-5 version of the graphic gets nods, we realize it can’t do everything. So we dress up around it that there are deeper specifics to this (like area:railway=station anomalous exceptions, expressed with question marks, further complexities with platform_edge that aren’t present in this diagram…). And that’s why (in the exact context of this diagram) we have wiki text with links to other wiki. The question marks act as daggers and asterisks to footnotes or in this case, wiki text.

We feather an upward edge of around 99% or 100% here. Really, this is sturdy construction and it is as pretty as a sweet kiss. I nod, what think us?

1 Like

Would it not be possible with railway:ref assuming it would be the same as the station node, altough i’d agree that (area:)railway=station could represent the station from a railway perspective whilst public_transport=station could do the same for a travler perpective

Needs to be eg railway:station:ref= on its own first. An application would need to automatically dissolve and chop off landuse=railway , and man_made= =bridge or =tunnel correctly from them to show a meaningful area. I’m guessing this will be difficult. Besides, the landuse=railway should already be divided up to keep to manageable size and extent. They are simply
The other option in parallel at the same time is railway=facility , similar to public_transport=stop_area . But again, as how you have asked for public_transport= , both the area and relational object can be created along each other.
railway=station + public_transport=station is currently required as a point together. This being handled by =stop_area for now. You would need to ask for separating the public_transport=station from the railway=station point to draw another area.