Do we really NEED railway=tram_crossing resp tram_level_crossing?

Basically, railway=tram_(level_)crossing is a controversal tag.

The general idea is that the usage to handle tram crossings is rather confusing since not all tramway crossings are applicable (in short, crossings only with a saltire use railway crossing tags) and I myself have fallen into this trap during my early days, something which I’ve corrected since. Someone recently has been andromechanically (and unannounced) changing these around Germany with no OTG confirmations whether they’re applicable in that situation (OsmCha link for some general changesets).

In particular, these tags have been introduced by a single user without any sort of proposal and only got widespread use because it was added to iD at some point but is otherwise nearly unsupported by every other tool (the justification is that railway and tramway crossings are legally different but this obviously doesn’t justify the lack of proposal).
Basically, this is a hack tag which never should have existed and instead contributed to an annoying mess. Basically, we need to reform railway=tram_crossing.

6 Likes

Related thread:

I would be in favor of marking these two tags as deprecated in the wiki. At least in my region (Germany) I see no reason to introduce new tags for these crossings. And an additional tag like tram=yes might have done the trick, with far less confusion and problems (and long discussions).

If it’s deprecated what should people do instead?

If it gets deprecated, because right now, it isn’t.

The reason why I’ve created this thread in the first place is because of the recent controversy which happened in Germany as well as how the tagging came about to be.

The legal distinction may be part of it, but I suspect this is essentially fallout from the approved 2019 embedded_rails=* proposal. That proposal legitimized the practice of mapping street-running railway tracks as separate features crisscrossing the roadway, as an exception to the physical separation principle, in order to model track geometry more accurately. In so doing, it created many additional highwayrailway intersections. Around the same time, railway=tram_crossing and railway=tram_level_crossing were informally discussed on the tagging list and on the Russian forum, but you’re right that there wasn’t a formal written proposal on the wiki.

iD’s preexisting validator for road–rail intersections automatically added railway=crossing and railway=level_crossing when connecting the ways, due to the very real risk of collisions with users of mobile navigation systems. However, most of the intersections involving these street-running tracks are merely artifacts of our data modeling approach, not real-world level crossings per se. To keep maps and navigation systems from “crying wolf” about these abstract crossings, iD limited railway=crossing and railway=level_crossing to heavy-rail crossings, distinguishing tram crossings.

Street running is by no means limited to trams. But it seems like both iD and the Russian mappers assumed that only trams would need this special treatment because trams are so much more likely to run on the street. Moreover, trams have different safety characteristics than locomotives, and in many cities, real tram crossings look different than real heavy rail crossings. That said, from the edits in Germany, we can see that the use of the word “tram” is problematic, because it implies to some mappers that any tram–road crossing node would qualify. Conversely, a heavy-rail industrial lead several blocks north of me runs along the street and crosses some intersections and lots of driveways, but no one would call them “tram crossings”.

From some of the discussions surrounding these tags, it sounds to me like the intention was for data consumers to ignore them, or at least deemphasize them. If so, I suppose not:railway=crossing and not:railway=level_crossing would’ve been another approach to solving the problem.[1] Maybe when connecting the railway to the roadway, the validator should give the mapper a choice between marking a bona fide level crossing and marking the absence of one. Similarly, when connecting a sidewalk to a service road, iD now lets the user choose whether to mark the intersection node as a crossing or leave it bare. The challenge with these “tram crossings” would be to clearly but succinctly describe the difference, since there are so many edge cases.


  1. crossing=no would be for places where a pedestrian may not cross. ↩︎

Yeah, I was aware of this separation between road and rail (and fixing that in a couple places).

Good to see it wasn’t a service=driveway2 situation. Still fairly rushed, though (e.g. no link to these pages whatsoever up until just now — both are very important), else it felt like these tags were pulled out of someone’s backside.

I can slowly see this point. I can’t quite fathom this because the separation was largely past my registering (albeit not as clean everywhere, I should note) and moreover, there also are lateral crossings which would create “unnecessary” tramway crossings, though I also remember a period where StreetComplete asked the max height at any level crossing before it was disable at any tramway just for the amount of crossings.
(On that aside, in case railway=tram_crossing[1] ever gets deprecated, the rule for street running tramways should be transplanted to railway=tram_crossing.)

There is a reason why I see tramways as a form of light rail and at least in Germany, tramway crossings only need to be protected by barriers (at most single barrier, to be precise) for automated train operation and IIRC that is only needed at busy intersections.[2] Otherwise, the only protection needed are a saltire for an “exclusive” trackbed (Besonderer Bahnkörper) or none at all if considered street running (Straßenbündiger Bahnkörper).
And of course, there also is the issue railway=light_rail which itself is problematic in what even constitutes “light rail” but that’s really just a RL issue than an OSM issue per-se regarding the definitions of light rail. Where it does affect OSM is that, while not as common as with normal tramways, street running also is a thing (being one the main strength compared to proper railways which are legally forbidden to do so or at least require the streets to be cleared) but the default are full railway crossings instead of whatever fits the current situation.

In all fairness, this is a mixture of confusing definitions, bad naming but also of users who don’t read the tags descriptions (points at earlier me).
(This is why I justify the use of crossing:saltire=yes for any tramway crossing.)

Not that it of course make them any less of hack tags (in fact, that strengthens the point).

In all fairness, if railway=tram_crossing weren’t a thing, I’d simply go with railway=crossing for any non-street-running tramway alongside a combination with railway:saltire=* (and make the tag necessary for QA at least for railway=tram/light_rail).


  1. resp. railway=tram_level_crossing but mentioning that all the time would simply bloat the post ↩︎

  2. More accurately, if the trackbed is considered “independent to any highway” (Unabhängiger Bahnkörper) which typically means grade separation but not always. ↩︎

Yes, this is one of those “controversial decisions”. As with many things written out of frustration and mistrust, there’s more to the story, hence the “opinion article” disclaimer at the top.

As a project, we need to do an overall better job of documenting the development of our tagging scheme, whether through proposals or otherwise, to prevent misconceptions (cf. highway=road and paths). Unfortunately, it’s increasingly difficult to find old mailing list threads using a standard Internet search engine. I have the luxury of a local archive of Gmane’s NNTP bridge in Thunderbird, which does a half-decent job of finding things. I only knew to check the mailing lists because OSM tag history showed a trend predating the Slashdot iD effect.

Increasing coverage of crossing:saltire=* sounds wonderful to me, but it would be a monumental task. In the U.S., for example, it’s present on only half a percent of railroad crossings, so requiring it at this point would amount to redefining railway=level_crossing. It might be feasible if we limit the fallout to trams and light rail, but someone would need to champion that tagging more than railway=tram_crossing and railway=tram_level_crossing, which haven’t benefited from proper coordination.

Has oneone ever thought about other types of railway crossings? light_rail was already mentioned briefly, but not yet finally assessed/decided.

What about miniature_rail, for example, where there can also be crossings with footways/paths or highways for wide vehicles (e.g. highway=service). Should there then be other special tags for this, such as miniature_railway=crossing/miniature_railway=level_crossing?

See e.g.: Node: 262169133 | OpenStreetMap or Node: 1383146226 | OpenStreetMap

Or railway=narrow gauge

In my opinion, tram_crossing/tram_level_crossing is a very poor and not fully thought-out concept (or not really a concept at all). Couldn’t someone take pity and write a well-founded (and hopefully sensible) proposal?

My question would also be (see also my comment #3 here at the beginning): why not solve it much more simply by using additional tags for railway=crossing|level_crossing such as:

  • tram=yes
  • miniature_rail=yes
  • narrow_gauge=yes

… if this is really necessary/useful for data evaluating systems – and they should not be able to derive this from the railway tags of the railway routes (ways).

1 Like

Keep in mind the definition doesn’t include every tram-highway intersection (else we wouldn’t have had this incident where one user de-facto automatically changed all types of crossings into the tram variant), only those without saltires, not to mention the main reason for inventing a hack tag is to prevent routers from treating every tram-highway intersection as a major level crossing. Adding tram=yes to them doesn’t solve the problem (or at the very least, less than railway=tram_level_crossing did)

Aside from this, it doesn’t really make much sense IMO to specify the type of railway crossing since the information you’d get from already established tags are generally sufficient (it would be like to specify the type of highway crossing for pedestrians which too is unnecessary because be it cars or cyclists, you still are traversing a non-pedestrian space laterally).

1 Like

Hello ManuelB701!

I understand the argumentation …

But for me the saltire criterion was already off the table because there were enough good counterarguments regarding the feasibility and ambiguity of the real situations (saltire only on one side etc.). Should this really continue to be a (hard) criterion? Or should it be replaced by others if necessary?

In my city (Saarbrücken, Germany), where there is a tram that is more of a light rail system, it would mean that crossings that are actually indistinguishable in terms of their construction/equipment would have to be tagged once with tram_level_crossing (minor) and once with level_crossing (major), which I would find completely absurd.

And the fact that we do not map for a map display, but for routing algorithms, seems to be a fact that is accepted (I would view this critically.). So good tagging concepts should be sacrificed on this altar for worse ones?

The question behind my question as to whether tram=yes etc. would not be the better and simpler solution is probably aimed at whether we should expect the routing algorithms to query this - or just check the existing structure to decide whether it is a “major level crossing” or a “minor level crossing”. Our primary task is to record the data correctly, and of course whether it can be evaluated well. But how far should we go? My opinion is that the result should not be poor, impractical tagging concepts, nor ones that are unnecessarily complicated.

And my feeling here is that this is already going a step too far.

The question has not yet been answered for example: What do we do with miniature railway crossings (or narrow_gauge, light_rail etc.)? That could perhaps serve as a concept test… That’s why I wanted to bring it into the discussion, not to split hairs.

Yes, I agree … Why should we introduce distinctions in the type of crossing for railways that we don’t do for highways? It’s a break in consistency for me, or should we start doing that for highways too (for reasons of consistency Irony off)?

What about miniature_rail, for example, where there can also be crossings with footways/paths or highways for wide vehicles (e.g. highway=service). Should there then be other special tags for this, such as miniature_railway=crossing/miniature_railway=level_crossing?

See e.g.: Node: 262169133 | OpenStreetMap or Node: 1383146226 | OpenStreetMap

Or railway=narrow gauge

In my opinion, tram_crossing/tram_level_crossing is a very poor and not fully thought-out concept (or not really a concept at all).

I believe (in some countries at least) trams are mostly following road traffic rules while railways have their own rules.

True enough. At this combined pedestrian/bicycle crossing Node: 804679746 | OpenStreetMap the trams leaving the tram stop “Trierer Straße” do stop after leaving, while the traffic_signals=tram_priority are off and you can pass as pedestrian or cyclist. Never seen such a thing at a regular railway crossing .

By the way, in the U.S., a crossbuck (saltire) is guaranteed to appear at a heavy rail crossing, but not at a light rail or streetcar crossing, where a traffic light or simple warning sign might be present instead:

Another wrinkle is that, even along heavy rail lines, private crossings only have stop or yield signs, accompanied in some states by a sign that alludes to a crossbuck.

After some back and forth, we documented this kind of sign as crossing:saltire=no.