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.”
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 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.
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.
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.
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
Yeah I see your point but if we would add a description box for type=route & route=train…
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,
tracks 2 & 3 should also be marked with a blue color because those should also be added as members to this relation,
we should also mention these tracks in the text box as members added to the relation,
etc.
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.
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.
the difference is that railway=station was there “forever”, while railway=facility was introduced when publicly discussing and voting on proposals was already very established.
dieterdreist:
has no clear meaning
I believe it does have a clear meaning: a relation which “groups” infrastructure elements of a railway operating site together.
I totally get that, but I still think that this shouldn’t hold us back from using it. If you have an other suggestion, please share it – I’m open to anything!
It does actually have a wiki page which redirects to OpenRailwayMap/Tagging where the tag is defined in detail. But you were right, the redirection was partially broken as it didn’t jump to the correct section of that page, so I’ve just fixed it.
About the search results: the second result to the query you linked is OpenRailwayMap/Tagging, where the tag is defined—although it doesn’t jump to the section in question. I agree that this might be enhanced later with creating separate wiki pages for all tags on OpenRailwayMap/Tagging.
Since me was cutting out railway corridors (landuse=railway) from many miles of farmland, scrub and wood, real fun since all was mapped in umpteen member MP relations, took the KISS route and just included the station area into the landuse=railway giving resultants like this…
The facility… 1 building at most of the halts \o/. For stations like Gare du Nord, better involve the mappers of those big stations which include bus, taxi, streetcar, metro (makes me think of Heathrow with their 5 apart terminal buildings). There the work is surely cut out.
(Done some indoor of a larger station like foot routes to the platforms, escalators, elevators never having felt the urge to create a binding relation. Certainly hoping when the framework has been hashed out to see a cleanup of ever repeating station names in the same zone… go fetch a coffee and start counting the number of times Centraal Station appears in this picture, at one zoom.
I don’t take issue with the tag name, what I am missing is an established definition. I would suggest to either write a page where the tag is defined, or better make it a proposal so that it can be formally approved. The latter would make it less likely that someone comes out later and questions the tag.
Thank you for the pointer. So basically this is for places that meet the German railway law definition of “Betriebsstelle”?
Good idea! I think it would be better to propose all the tags on the illustration at once in order to avoid (future) conflicts between them. But since I unfortunately don’t have time for that now, I’ve moved and updated the tag’s definition from the OpenRailwayMap/Tagging page to its separate wiki page. Improvements are welcome!
On that wiki page, under References, I expected to see “diagram 2” (the fully themed one) we just all achieved. Seems like a “chef’s kiss” place to put that diagram (or link it from the wikiverse). I mean, we all stand by that, link it up. If you point to this topic (in the wiki), I’ll offer an A+. Nice work everybody!
| 
dieterdreist:
