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=stationrailway=haltrailway=yardrailway=service_stationrailway=junctionrailway=crossoverrailway=spur_junctionrailway=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:
1 Like
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.
1 Like
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.
1 Like
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.
Yeah that’s true. I’m sorry that I missed it.
type=site seems like a good idea to me, it fits the purpose! I wouldn’t choose type=railway because it’s unnecessarily specific next to the railway=facility tag.
1 Like
Who suggested using railway=facility on the same relation as type=public_transport?
But I see your point about mixing public and private use objects of a railway operating site. What about using public_transport=stop_area with type=public_transport for the public part (public use objects added to the relation as members), and railway=facility with type=site for the whole area (all objects added to the relation as members) of the station?
2 Likes
I don’t know and want to ask how were railway=facility and railway=site discussed and created in OpenRailwayMap too. I don’t understand their thinking.
1 Like
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?
2 Likes
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.”
3 Likes
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.
3 Likes
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.