Proposal:Deprecate railway=tram crossing and railway=tram level crossing

Deprecate railway=tram crossing and railway=tram level crossing
Proposal status:	Draft (under way)
Proposed by:	ManuelB701
Tagging:	railway=crossing, railway=level_crossing and crossing:saltire=*
Applies to:
Definition:	Deprecates railway=tram_crossing and railway=tram_level_crossing while also reforming railway=crossing and railway=level_crossing to take street running into account.
Draft started:	2024-10-23

Proposal

The goal of this proposal is to reform the way how tramway crossings are tagged on OSM right now by deprecating railway=tram_crossing and railway=tram_level_crossing in favour of going back to the old style with railway=crossing resp. railway=level_crossing (note that in this proposal, tram_crossing is used to also represent tram_level_crossing, ditto crossing and level_crossing) but also refined the old tags to take street running into account.

Rationale

The history of both tags happened during a change on how to tag highways with embedded rails. Historically, a lot of highways with embedded rails were mapped as only one element i.e. one single way had both highway and railway. However, this broke two of OSM rules:

• It breaks the rule of One feature, one element: Road and rail are physically both separate elements and can have separate properties. This means name could refer to either the road or the tracks (and some tramways do have their own name) and you can't differentiate information between tram and trolleybus overhead wires (e.g. voltage levels).
• It breaks the rule of Dual carriageways: Each direction is drawn as its own separate way but for OSM, this mapping is only valid at physical separations and many streets with embedded rails were single carriageways which should be tagged as one way on OSM only.

For this reason, a new tag, embedded_rails, was invented to tell data consumers that there are rails embedded within the highway surface and the practice to map highway and railway in one way largely disappeared, even supported by *:lanes=* which allows for a greater detail on how the tracks are embedded.

One side effect of this separation process resulted either in a lot of unconnected highway and tram crossings and editors like iD used to add railway=crossing at any connection for highway-railways (tramway or otherwise) or railway=level_crossing was added at every single crossing from the start, neither of which took care whether the crossing exists in reality. This became notable in the Russian community where it's e.g. forbidden to make a u-turn at railway crossings but allowed for tramway crossings in Russia so these new railway=crossing resulted in a lot of false positives. Other potential issues a cluttering of (non-existent) crossings on the map and routers taking (non-existent) crossings into account and rerouting users into a less optimal path.

The result is the invention of railway=tram_crossing and railway=tram_level_crossing which should solve these issues.

However, over the time, more and more problems appeared and the existence of these tracks were put in question:

• The first one is that neither of these tags were formally proposed which resulted in an introduction of Russian-specific tagging into the international community but also lacked the input of the latter nor the introduction of these tags were properly discussed (e.g. any potential problem).
• The value itself as well as the documentation outside of the tag page generally imply that these are to be used for railway=tram much like railway=crossing is for railway=rail which caused three problems:
  • It misled many mappers that any highway-tramway crossing applies to these tags instead of those which lack a crossbuck / saltire
  • Even beyond that, the official definition mentions that railway=level_crossing is only used on actual crossings, not for on-street sections, but many still use them for any sort of highway-tramway crossing, regardless on whether they're on-street or on their own ROW.
  • These crossings aren't just applicable to railway=tram but also to other railways like railway=light_rail (which in many countries run under the same laws as railway=tram) and even some railway=rail.
• Lots of software, from various editors to routers, don't actually support railway=tram_crossing.
  • This can be seen as a feature and not a bug with the original intention (the aforementioned u-turn, etc. rules between railway and tramway crossings) but it can also be seen as tagging for the router (i.e. adapting OSM data instead of adapting routers and therefore breaking data for data consumers).
• From a user's POV, there is no difference between a tramway crossing with a crossbuck and one without, you should be careful to not cross the street at red or at the very least watch out for a train nonetheless.
• Last but not least, iD added this tag for any highway-tramway crossing regardless of the context (be it in-reality-not-a-crossing, on-street sections, guarded and unguarded crossings) so the overall problem was shifted to a different tag, especially because data consumers which do take railway=tram_crossing into account will throw false positives again unless the crossings have been curated.

For these reasons, the only rational solution is to deprecate both tags in favour of going back to railway=crossing resp. railway=level_crossing, albeit with better rules to deal with street running alongside taking crossing:saltire=* into account (which originally railway=tram_crossing was the only thing which differentiated them from railway=crossing on railway=tram).

Arguments to keep those tags (and counterarguments)

Keep in mind that railway=tram_crossing has some defenders and these arguments have been brought up:

• Routers don't have to display a warning on every crossing and would cry wolf on street-running tramways.
• It allows navigators to tell the user that a tram crossing and not train crossing is ahead

However, counterarguments to these tags have been brought up:

• Overuse of railway=crossing on street running sections is a tagging error, when it was added without any consideration. Retagging them into an unsupported tag is only temporary but doesn't solve the core issue:
  • If navigators don't take care of them, they wouldn't warn at tram crossings which do matter (false negatives).
  • If navigators do take care of railway=tram_crossing, they would cry wolf in places which don't matter (false positives).
• It contradicts with the current documentation which mentions that tram crossings with a crossbuck are tagged railway=crossing nonetheless. This is thus a major redefinition of an existing tag and requires a new proposal.
• A tram is still a train, just one optimised for on-street operation (higher acceleration, narrower body, often times a lighter body) but can be used as more typical trains:
  • Many tramways integrate former branch lines into their network without making any major changes to the infrastructure
  • In other cases, modified tramcars run on mainline tracks (known as tram-trains)
  • Conversely, mainline trains can run on tramways
  • More rarely, mainline railways can be on streets
• Routers can deduce the expected trains by looking at the railway value and demanding the use of railway=tram_crossing
  • An alternative which has been brought up is to add tram=yes on the crossing node (this also helps to cover railway=light_rail instances)

Tagging

The proposal takes a middle ground approach by taking some ideas of railway=tram_crossing to railway=crossing. This means, the tag takes some ideas of the former and implement them to the latter. In addition, the more-or-less unofficial (unproposed) tag crossing:saltire=*, which is sometimes used to mark the lack of crossbuck on level crossings (major railways normally do, light railways can come without), gets integrated for crossings on railway=tram.

Most notably, the usage table of the current railway=tram_level_crossing page gets transposed to railway=crossing for a dedicated tramway section with the following rules:

• With a saltire (both, dedicated ROW and mixed traffic):

Any crossing is tagged with railway=crossing + crossing:saltire=yes

• Without a saltire but on its own ROW (can be shared with buses)

Any crossing is tagged with railway=crossing + crossing:saltire=no

• Without a saltire and in mixed-traffic:

No railway=crossing nor crossing:saltire=no (trains are treated as road vehicles, all crossings informations are derived from highway instead)

The result is that crossing:saltire cannot be assumed to be yes at a railway=tram crossing so any such crossing has missing information. railway=light_rail is more nuanced because the default assumption for saltires depends on the legislation but also on OSM perception (most notably, heavy railways like the S-Bahn in Berlin are tagged as railway=light_rail).

It does mean that replacing railway=tram_crossing into railway=crossing + crossing:saltire=no can't be done just automatically and requires either pre-purified data (i.e. all the crossings have been sorted out into these aforementioned categories) or require manual inspection but automated edits are discouraged on OSM anyway.

Features/Pages affected

• Deprecate railway=tram_crossing and railway=tram_level_crossing
• Add a "Crossing" section for railway=tram and railway=light_rail
• Add a tramway section for railway=crossing, railway=level_crossing and crossing:saltire

External discussions

• https://community.openstreetmap.org/t/do-we-really-need-railway-tram-crossing-resp-tram-level-crossing/118987

Comments

Please comment on the discussion page.