Proposal talk:Railway

Another proposition (from User:ShakespeareFan00)

http://wiki.openstreetmap.org/index.php/User:ShakespeareFan00/TagSpew/Rail

--Gummibaerli 09:45, 6 October 2008 (UTC)

service and priority

your priority=* tag is somehow congruent with the already existing service=yard;siding;spur, as I understand the later one as "which service is accomplished on these tracks". "primary" and "secondary" wouldn't fit, but I'm sure we will find another one like "main_line", "commuting" or something similar. The "yard" tag already exists and is even extended with "spur". --RalpH himself 07:59, 15 April 2009 (UTC)

embankment, cutting, gradient

they already exist as embankment=yes, cutting=yes, incline=*% -> see Map_Features#Properties --RalpH himself 21:02, 10 April 2009 (UTC)

new distinguishing of railway=* not exactly enough

as you said, the railway=* tag should define, what the railway line is, not what's driving on it. But there are very well differences between rail, narrow_gauge, tram, subway, disused etc... If we keep that, there is also not much need for the tram=yes, metro=yes, commuting=yes, train=yes, whatever=yes. This belongs mostly into the trainline-route-relations, since on a "normal" rail a big variety of trains can drive: "regular" trains, light_rail, maybe even trams/subways. There are only a few exceptions, eg if a line is ONLY for a special train type due to legal/operational reasons (only fright trains on bad lines, only highspeed trains on highspeed tracks). And by the way, nobody would be motivated to change everything.

The railway=narrow_gauge is really handy, since the "regular" railway=rail includes usually gauge=1435 (or should at least), whereas narrow_gauge can be specified further with gauge=*. Smaller drawing on the map is made easy and is very useful, so no reason to get rid of it. --RalpH himself 20:41, 10 April 2009 (UTC)

I think the biggest problem is that "nobody would change it". But what if the current state is not good enougth? There is this discussion about Sidewalks and bicycle-lanes and that there is a lack of definition on which side the sidewalk is and if the bicycle-lane on one side is oneway or bidirectional. Of course nobody wants to change this too, but if the Data should be augmented that sometimes change is needed

My intention of the gauge-thing was to generate a consistency in the railway-scheme. Since there are also trains with broad_gauge in some countries the need of a railway=broad_gauge would be necessary. I think that every country has its individual "normal" gauge and my intension for consistency-reason was to tag the railways the same way in all countries. PieSchie 11:35, 14 April 2009 (UTC)

That's indeed true. But the street/cycleway thing is about adding information, that can't be added correctly right now. While your proposal is to REMOVE information or mix information that has primarily nothing to do with each other (track with and rack). If a proposal is really about improving the current system, it's no question to introduce it, but here I don't see the progress in this special section of your proposal. --RalpH himself 21:26, 14 April 2009 (UTC)

power

power=* already exists and includes a voltage=* Tag; frequency and type (ac, dc, 3-phase) are about to come. --RalpH himself 20:22, 10 April 2009 (UTC)

Then there should be additional attributes like railway:power=3rd rail/overhead/none/... ? PieSchie 11:38, 14 April 2009 (UTC)

The Tag electrified=contact_line;rail;yes;no already esists (see Map_Features#Railway); any other power is not provided by the railway line, but is an individual property of each train riding on it (steam, diesel). There could indeed be Tags for water/coal/diesel refilling stations, but that's another problem. --RalpH himself 21:15, 14 April 2009 (UTC)

type obsolete

Since type=attraction and type=show do not share the sense of a transporting facility, it shouldn't be railway=*, and therefore type=* is obsolete. These belong to tourism=*. --RalpH himself 20:22, 10 April 2009 (UTC)

same with rollercoasters!! --RalpH himself 20:23, 10 April 2009 (UTC)

rack not exactly enough

railway=rack is not distinguishing enough, as a rack can be used with railway=rail as well as railway=narrow_gauge or any other. IMHO it should be separate, and when we're already on it, it should be more flexible: I support the suggestion of [1] to intruduce traction=adhesion;rack;cable --RalpH himself 19:53, 10 April 2009 (UTC)

switch_box

If a switch_box always has a person in it, what to do in the case of boxes that aren't always manned? Many in outlying areas will close at night, either blocking the line to trains or "switching out" to allow two further-away boxes to work the line. --Chriscf 08:57, 6 October 2008 (UTC)

beeing out-of-order at night would probably need the use of access / hour_on / hour_off - tags PieSchie 09:57, 6 October 2008 (UTC)

Attraction vs. Show

What is the envisaged difference between attraction and show? --Chriscf 08:57, 6 October 2008 (UTC)

attraction are trains where people can sit on (http://en.wikipedia.org/wiki/Children_railways and http://en.wikipedia.org/wiki/Backyard_railroad); show is only to watch! PieSchie 09:57, 6 October 2008 (UTC)

Do you have an example of "only to watch"? I hope you're not suggesting we map people's model layouts. Chriscf 10:47, 10 October 2008 (UTC)

I thought about something to consider Proposed_features/Miniature_railway Since a real miniature can be with and without passengers I think that this differentiation belongs to the level where there is the differentiation between attraction-railway and transportation-railway. IMO the "size"-thing in miniature can be ignorede because it is covered with scale=*. --PieSchie 11:19, 10 October 2008 (UTC)

My thoughts had been that a model without passengers is generally so because it is too small to carry them, and many such layouts are not extensive enough to warrant mapping. Chriscf 14:46, 10 October 2008 (UTC)

ELR

In Britain, lines have a code known as the Engineers' Line Reference (ELR). These apply usually to all parallel lines, but not always. They may also be assigned to sidings, where they apply to parallel lines, but different groups may have a different subscript number. Where might this fit into your proposed scheme? --Chriscf 08:57, 6 October 2008 (UTC)

In Case of setting the ELR to the track_ref it would lead to identical track_ref numbers on parallel tracks when mapping track-detailed. In the other case there would be one way per line. Obviously there is missing the information if the way is a line (multi-track=yes/tracks=2+) or if this is a single track. PieSchie 09:57, 6 October 2008 (UTC)

Use of infrastructural Details

Parts of the infrastructural detail looks like it would be of little use to those outside the industry, and the railway companies being a safety-critical operation (putting it beyond our scope). For instance, what is your envisioned use case for signal data and switch types? --Chriscf 08:57, 6 October 2008 (UTC)

• for me - it is a mapping-help for wide rail-yards. When track-detail-mapping a yard I can geo-reference every single switch (node) from digital images. Since I cannot walk on the tracks to get a GPS-Position I have to identify the switches on pictures from different points-of-view.
• there are a lot of train-simulators and since there are a lot of geeks trying to create a realistic environment It could be a great project to convert OSM-Data into a train-simulation including Landuse, natural, elevation, buildings and the detailed infrastructure.
• for research-use, e.g. the performance of a station/yard/ ... retreiving detailed data from the opperator is very difficult. OSM would certainly be an adequate alternative source. PieSchie 09:57, 6 October 2008 (UTC)

system

system=EBO or system=BOStrab: "system" is a very global name... You will find a lot of systems in the word of rails :-) So system ---> law? Or something other suitable? --Mueck 23:48, 9 October 2008 (UTC)

what about the translation of "Betriebsordnung" = "work_rules"? or "railway:regulation"? --PieSchie 09:41, 10 October 2008 (UTC)

In the UK, we refer to the particular type of operation as "working", one would say "the Milk Wood branch is worked by Llareggub box under Absolute Block rules". This is somewhat reflected in the Australian term "safe-working" to refer to the combination of the signalling equipment and the rules of operation. The word "regulation" refers specifically to controlling the flow of traffic, e.g. ensuring fast trains don't get stuck behind slower ones. Chriscf 10:39, 10 October 2008 (UTC) added some missing words - Chriscf 09:09, 23 October 2008 (UTC)

I do not see a point in providing information about the laws/regulations behind a specific railway line. To those interested, that kind of information can easily be inferred from the "railway" and "operator" tags. --Bigbug21 15:36, 22 October 2008 (UTC)

That would be nice... but sadly, the railway world is never that simple ;) You cannot reliably infer the working rules from the operator information. Even in Germany which is pretty homogenous in this respect, there are corner cases. For example, much of the AVG's own infrastructure is operated according to BOStrab ("tramway" rules), but there are some lines which AVG took over from DB. Those lines are still operated according to EBO ("big railway" rules). --ipodolsk 16:00, 22 October 2008 (UTC)

I'm still concerned as to an actual use of this data might be. The two that jump out at me are cases we don't cover - the railways (safety-critical), and enthusiasts (curious minds). I'm not entirely convinced that this sort of information need be georeferenced in the first place. Chriscf 09:09, 23 October 2008 (UTC)

Sample route tagged using this rules

I've tagged the S6 route of the Stuttgart commuting railway system (from S-Zuffenhausen to Weil der Stadt, relation 37419 37419) according to this proposal, just to see how and whether this proposal is implementable :). I hope I've got the tags right. Comments welcome :) --ipodolsk 07:36, 20 October 2008 (UTC)

looks nice - and ok to me (you where right)

Actually, it'd be nice if you could take a closer look at the connection between the marshalling yard link and Schwarzwaldbahn just before the Korntal station (48.82848,9.12688). The switch track between the northern and the southern track there is tagged as priority=primary train=yes and not priority=switch as other similar switches along the track. Is it what you had in mind with the priorities and train/commuting/...? --ipodolsk 17:56, 21 October 2008 (UTC)

I think the question here is wheater to tag a rail as "switch" if it is a short way to change e.g. between two tracks on one line. I would tag it the same way as a U-turn on a primary-road: primary, too: railway=rail, priority=primary and train=yes. railway=switch belongs only to the node or to a way that is on exaktly one switch. as junction-Tag on highways. --PieSchie 06:20, 22 October 2008 (UTC)

Why not keep it simple?

After skimming the proposal for the first, I am wondering whether or not we can keep the entire scheme a lot simpler. Just a few examples:

• I do not see a point in the "priority" key. Yes, I do believe we need to better distinguish between some basic types of railways (such as main lines and secondary lines). However, I would rather suggest to use the "railway" key for that purpose, just with an extra bunch of values. So, why not keep "railway=rail" for general rail lines and add keys like "railway=primary" and "railway=yard" for a more refined categorization? We could achieve the same result, but keep the tagging scheme simplier by saving keys and having similarities between roads and rails.
• I do not get the point of the proposed "service" key. We already distinguish between "railway=rail", "railway=tram". Why should we give that up? As I said earlier, there certainly need to be some more values to the railway key, but why should we blow the entire system with new keys that can easily be included into already existing ones?
• I'd rather keep switch_type a type. The "switch" information can already be inferred from the "switch" value to the "railway" key.

That's all for now. I'll do my best to contribute on a more regular basis. --Bigbug21 15:46, 22 October 2008 (UTC)

rollercostaer

In my opinion rollercoasters need to be separate from railway, because they're are very different, rollercoaster are not a transport railway. --wiso 09:50, 14 January 2009 (UTC)

Agree. attraction=rollercoaster? Not that I'll be mapping rollercoasters any time soon (the number of overlaps means they'd be pretty complex, plus GPS isn't exactly going to work for fast ones...). Frankie Roberto 23:31, 21 January 2009 (UTC)

power

power:type is in double use... thirdRail|overhead|none and alternating|direct|3phase both is needed, so first should power:contact=... ? --Mueck 03:09, 28 January 2009 (UTC)

Map Features has electrified=contact_line (for overhead) | rail (for thirdRail) | yes | no Which words are better? For first one Leo says both: contact line, overhead, overhead contact line ;-), ... For second one Leo says contact rail, power rail, third rail, ... --Mueck 12:56, 28 January 2009 (UTC)

trains/industrial = passengers/goods?

Does train=yes mean transport of passengers and industrial=yes transport of goods? It doesn't sounds so... Might bei passengers|persons=yes goods=yes would be better? --Mueck 03:12, 28 January 2009 (UTC)

It means: train=yes for tracks where passengers and goods are transported. industrial=yes are tracks that are on a industrial site where goods are transfered from one building to another. (see Industrial_railway) PieSchie 14:36, 10 March 2009 (UTC)

light_rail

I would prefer to divide between:

• tram=yes: a system, where the tram mostly uses the street mixed with cars, seldom separated
• metro=yes: a system, where the "tram" mostly uses own ways, not mixed with cars, also no or very rarely crosing with cars, in the city often using underground

and filling the gap with

• light_rail=yes: a system, where the tram mostly has separated ways from cars, but has crossing, in the city sometimes using underground and also sometimes using tracks of heavy-rail-networks (Karlsruhe, Kassel, Köln/Bonn, ...)

--Mueck 11:29, 28 January 2009 (UTC)

There are some discussions about the differentiation of tram, metro and light-rail. Since e.g. in Karlsruhe the tram / metro? uses rails on the main station there will always be a conflict with "hardware" (rails) and "software" (lines). Therefore I propose a differentiation between those two parts as is at streets where highway=primary does not give specific information about the vehicles that are allowed at this street. PieSchie 14:52, 10 March 2009 (UTC)

Betriebsgleis

What's about an "Betriebsgleis" (sorry, Leo doesn't know it :-) ), a railway, mostly tram, not used by a regular line, but only for deviation, going to yard, changing the line, ... It's not yard, becausw outside of yards... prioritiy=service? --Mueck 13:04, 28 January 2009 (UTC)

service

I think we should distinguish between the physical infrastructure (rail) and the trains, which are using the infrastructure. When we are tagging streets, we only say, which vehicle is allowed to use the street and we do not tag if the street is mostly used by motorcars, bikes or pedestrians. The information about the train which is really using the infrastructure should be only tagged by tagging the relation.--KartoGrapHiti 13:31, 6 February 2009 (UTC)

Merge

It has been suggested that this proposal should be merged with the railways article. I agree that any elements of this proposal that fit with current agreed practice should be merged, but other parts of this proposal seem far from being agreed and should not be until they are mode developed and have more support. PeterIto 19:42, 16 August 2009 (UTC)

Current practice suggests to leave the proposal page. I will archive it however. --Tigerfell  (Let's talk) 20:49, 5 December 2018 (UTC)