Thanks. Sorry I found it quite difficult to follow what was being suggested.
1 Like
same for accepted tags (for example highway=path)
This is for me not a issue of the tag. this is more an issue of ID adding tram_crossing per default to all crossings with railway=tram
As much as I would like for us to explicitly tag crossing:saltire=* and other attributes more often, I donât think we should expect data consumers to infer very much from crossing:saltire=no. It just means there isnât a sign that can be recognized at a distance as a crossbuck. It doesnât mean, for example, that rail traffic follows ordinary road traffic rules, something that could maybe be inferred from crossing=tram_level_crossing. Not every streetcar crossing is uncontrolled, and not every train crossing is controlled.
I think we may need some other subkey, but first we need to align on what it is that makes a âtram crossingâ, other than the potential presence of a tram.
2 Likes
However, this âordinary road rulesâ extends in Germany to tram tracks on their own ROW without any saltire. And yet, theyâre virtually identical to those with saltires, I donât see any reason why they need any special tag.
Itâs like asking highway=bus_crossing for any pedestrian crossing on BRT. No, we use normal highway=crossing for that.
And crossings in actual mixed traffic also have a solution: Just use empty nodes unless a saltire exists, period. Abolishing these tags doesnât mean to revert the status quo to before the tag was invented, no, it simply means to take the existing documentation but replace railway=tram_crossing with railway=crossing + crossing:saltire=no.
1 Like
Behold, busway=crossing crossing:saltire=yes. 
So far, the Los Angeles Metro Busway might be the only busway system in the U.S. that features crossing gates and âBUSWAY CROSSINGâ crossbucks (saltires), but many other busway crossings across the country have special traffic control devices that distinguish them from ordinary intersections.
I donât think this necessarily justifies a new tag, but I think it shows why we should refrain from inferring too much meaning from individual crossing:*=* tags.
2 Likes
In all fairness, I did imagine that a BRT should get some saltires (akin to how bus signals are the same as tram signals in various countries), I didnât realise it was already a thing, lol. That being said, it still is a highway=crossing in my eyes, just one which happens to have crossing:saltire=yes (though the same canât be said for highway-busway crossings, that one does need a new tag).
1 Like
I think itâs a benefit to the data if we have separate tags for railway=level crossing and railway=tram_level_crossing. Because in many countries there is a large difference between how traffic behaves around a true train railway crossing and a crossing with tram tracks.
A crossing with a railway is often signaled and has warning signs because trains ride at high speeds and a collision with a train would cause a lot of damage.
Trams on the other hand often take part in normal traffic and ride at lower speeds, making the type of crossing very different. And also the frequency of someone crossing tram crossings is much higher than train railway crossings when youâre riding in a city with a tram system.
For data users this data is important. I can speak for TomTom, but Iâm sure there are others too.
We at TomTom give drivers a warning when they are approaching a railway crossing, so that drivers are aware and pay attention. But because tramway crossings donât have separate tags in some cases, drivers will also get a bunch of warnings when driving through a city with a tram system when itâs not necessary to be warned of a ârailway crossingâ when you are just approaching a normal intersection with tramrails over it.
So, the separation would make it easier for data users to warn people of railway crossings, and Iâm sure there are also other applications of this data.
3 Likes
However, this arguments breaks down at the following points because it still results in false positives and false negatives:
- Navi systems which take
railway=tram_crossinginto account would still warn for mixed-trafficrailway=tram_crossingcrossings (false positives). - Navigations which ignore
railway=tram_crossingwill ignore them in places which do matter (namely tramway crossings with no saltire but from userâs POV, itâs all the same) (false negative)
Itâs these reasons why I see railway=tram_crossing critical, that it didnât solve the actual problems with tramway crossings and you can actually work around with railway=crossing.
The important thing here is that it should warn for railway crossings with trains, and not for crossings with trams. So the important distinction is the one between if the crossing is with a railway thatâs ment for trains or a railway thatâs ment from trams.
Then adding crossing:saltire=no/yes can be an extra addition for extra detail too ofcourse, but not what Iâm going at
Trains like these?
Or Trams like those?
The point Iâm making is that itâs all railways and the strict distinction between trams and trains is mostly artificial since the former is a subtype of the latter (or more accurately, tramways are a subtype of the latter). To make matters worse: Light rail vehicles: Trams or trains?
And donât get me started on the US where you sometimes have full sized trains in mixed traffic.
.jpg){kind=link}
Another difference to keep in mind is the frequency: Tramways generally have a higher usage frequency than railways so while speed is generally slower for the former, you do get more points of conflicts in other ways.
Last but not least: What youâre describing is against the current documentation i.e. tramway crossings with saltires are tagged with railway=crossing, not railway=tram_crossing. Mappers who follow this at their heart still cause these train instead of expected tram crossings. The only way to differentiate between them is to either read the connected railway value or add a tram=yes to the crossing node but again, this made railway=tram_crossing redundant and opens up a can of worms for other railways.
Yes, this feature is also present in OsmAnd and the Mapbox Navigation SDK (via Valhalla). Regulators in the U.S. are keen on getting more navigation software systems to follow our lead, but I suspect we would be back on their naughty list[1] if OSM data consumers were to âcry wolfâ about every street-running crossing, numbing motorists to the alert.
Currently, the OsmAnd and Mapbox implementations rely on the distinction between railway=level_crossing and railway=tram_level_crossing, but I suppose the more technically correct implementation would silence the alert if the roadway has embedded_rails=yes or if the crossing tracks have embedded=yes.
Just to be clear, that photo is from 1968, when street-running was much more common in the U.S. For the last several decades, the federal government has been pouring an eye-watering amount of money into separating rail and road traffic and closing grade crossings where possible. The South Shore Line ended street running in 2022, and itâs one of the last interurban lines in the country, so itâs quite an edge case. However, to your point, there are still some heavy-rail street-running segments here and there.
Oh look, a saltire! 
Alongside Google.
â©ïž
This important distinction should not be based on a railway=crossing but on the railway= (rail, tram, etc.) with which the highway shares a common node. In my opinion, the probability that a railway=*crossing is not set or is set incorrectly is much higher than that a complete railway=rail/light_rail/tram is tagged incorrectly. And thus the probability of missing or incorrect routing announcements.
However, I see a much bigger problem in the fact that mappers are increasingly mapping every physical crossing of two traffic ways with a *crossing. As a result, routers that warn against such crossings do so in many places where it would not be necessary. This tires the user and a crossing that really requires increased attention is then paid less attention to.
Iâve been observing this trend at pedestrian crossings for some time now. With increasing micro-mapping and separately mapped footpaths, a large number of footpath crossings are being created at even the smallest, most normal crossings in residential areas. Crossings that actually require more attention (than they already do) are no different. The effect of a warning from the router is lost. I have already switched off the warning for pedestrian crossings on my OSM-based router and prefer to keep my eyes open myself.
I fear the same development for tram and railway crossings.
1 Like
Same reason here, this tags will be automatically added to all crossing nodes by editors like ID (or even SC?). This would not be a big issue if there is a simple way (e.g using their crossing-tag) to distinguish between important crossings and unimportant crossings.
In all fairness, part of the blame is iD which doesnât give you the option to connect highways and tramways (and light rail by extension) with no crossing node alongside lack of knowledge on how to properly use them (but admittingly, this is a bit of a gotcha).
Itâs a similar issue happened with crossings between highway=footway and highway=service which iD for the longest time automatically added a highway=crossing before it gave you the option to simply not add one when connecting (and I know a neighbourhood which had highway=crossing on the various driveways but letâs be honest, the mapper which added the pavements wasnât careful anyway).
There should be more highway=crossing informal.
Yes and no. We donât map crossings solely for the purpose of alerting motorists during turn-by-turn navigation. There are other important use cases, such as pedestrian navigation, detailed rendering, and network analysis.
If an application unconditionally alerts you about every highway=crossing you approach, then you have no choice but to disable the alert. Ideally, the application would ignore crossings at signal- or stop-controlled intersections, or only alert at the sort of crossing that has signs and flashing lights.
You can see in that issue the pretzel that I twisted myself into, trying to come up with a good heuristic for ânon-intersection crosswalksâ. Iâd imagine it would be similarly difficult for railroad crossings, if not for some explicit tagging distinction on the intersection node, since most routers donât have any awareness about the tags on the edges crossing the route. The distinction between railway=level_crossing and railway=tram_level_crossing isnât ideal, but of all the heuristics and rough proxies that routers rely on, it isnât actually that inaccurate for this purpose.
1 Like
Just FYI, Iâve been drafting a deprecation proposal using the arguments weâve collected and just need to fill out the examples section because of missing images.
Edit: Link fix.
2 Likes
Looks like the link is busted. Hereâs the link to the proposal.
2 Likes
Thanks for posting your draft. Since youâve put effort into polishing this proposal already, I hope you donât mind if I give some early feedback. First of all, it would help to refrain from rhetorical flourishes like âinfamouslyâ (linking to the âControversial decisionsâ page). We know how you feel about this tag, but we need cooperation, not an adversarial process.
Iâve asked folks with more intimate knowledge of North American rail infrastructure to have a look. From my perspective as a road user and frequent train rider, I can see problems with the status quo, but Iâm equally concerned about the potential for further muddling the situation by making new regional assumptions.
The proposal seems to assume a strict hierarchy of safety features. As with pedestrian crossings, any hierarchy that fits well in Europe will fit poorly when globalizing the tagging scheme. If anything, the principal safety device in North America is a train horn (crossing:whistle=*), not a crossbuck (crossing:saltire=*) or crossing gate (crossing:barrier=*).
I think we agree that not every point of conflict between a street and a street-running railroad track should warrant any crossing tagging. If railway=tram_crossing and railway=tram_level_crossing were limited to mere intersections between a track and a part of a street, then these tags would be effectively meaningless, mere placeholders to prevent someone from re-adding an inappropriate railway=crossing or railway=level_crossing.
However, I disagree that the presence or absence of a crossbuck distinguishes one of these points of conflict from an actual railroad crossing. In North America, we have a great many railroad crossings that lack a crossbuck but that are just as dangerous as those with crossbucks, if not moreso. In fact, this is the de facto or de jure standard at any pedestrian crossing or any crossing with a privately owned road (ownership=private, not necessarily access=private). Instead, thereâs usually a yield or stop sign. A crossbuck or crossing gate at any such crossing would be an exception worth tagging.
I regularly ride a commuter rail line. Like many lines around the country, it still features pedestrian grade crossings at some of the stations. Consistent with state law, the crossings have train horns, flashing lights, bells, and an automated crossing gate, but no crossbuck. Express trains bypass some of these stations at up to 79 miles per hour (127 km/h).
Pedestrian crossings along light rail lines can have similar features, even though the lines operate much less dangerous vehicles:
To me, both kinds of crossings are essentially the same, regardless of the presence of a crossbuck, because they occur in a railroad right of way, as opposed to a street corridor.
Why does this matter? A couple years ago, an Amtrak passenger train traveling at 80 miles per hour (129 km/h) barreled into a car at a private driveway:
The popular winery at the end of the driveway is accessible only by crossing the tracks at this private crossing. The only official safety measures are the train horn, a stop sign, and a regulatory sign that means ownership=private access=permissive. Despite at least 16 other collisions here over the years, the owner could not convince the railroad to install proper flashing lights and crossing gates. Instead, he resorted to putting up various homemade signs warning of âTRAINS!â The worst thing we could do is to make these problematic crossings more difficult to discern.
As an end user, I would want my phone or car to warn me about an upcoming railroad crossing â especially if thereâs no crossbuck. I suspect that this sentiment is shared by the officials from two different branches of the U.S. federal government who coincidentally wrote to OSMUS at about the same time, demanding a progress report on facilitating such warnings in mobile navigation systems.
I recognize that these considerations differ from those in Germany. Rail mappers are remarkably tolerant of regional differences in tag definitions and tagging practices. If each continent is a fiefdom, at least it reflects the real-world differences in operating rules. But compared to most rail infrastructure, our coverage of railroad crossings matters to a much wider audience and has a more profound real-world impact. For better or worse, there is much less room for railway=level_crossing to mean something very different in one region versus another.
3 Likes
I get your point but the main focus is on railway=crossing on railway=tram. In fact, Iâm not worrying too much about false positives on railway=rail (maybe on railway=light_rail due to the) since Iâm sure only few routers take care of crossing:saltire into account and if the algorithm has to be changed anyway, the railway type the crossing is connected can also be included in the calculation which has been brought up[1]. In fact, one of my points is that tram crossings without crossbuck arenât that much more different than those with a crossbuck.[2]
In all fairness, the whole debacle bred quite a bit of frustration, not to mention this is the third time Iâve written a proposal (on a controversial tag, to booth).
StreetComplete does that after too many questions about the max height of level crossings on
railway=tramappeared â©ïžIn fact, the upper tramway example in my one of my previous posts doesnât show any one but you wouldnât behave any more differently there than on an uncontrolled railway crossing without a crossbuck. This, and tramway crossings can include barriers which this line regularly does, just not here. â©ïž
1 Like
Thanks for your revisions. Hopefully we can keep the community focused on constructive approaches to solving these problems â a âthird wayâ, rather than a third rail. 
Ah, maybe Iâm reading too much into the proposalâs tagging instructions regarding crossing:saltire=*. If I understand correctly, the primary issue is that routine conflict points within a street or pedestrian plaza are tagged as a kind of crossing, so the bits about crossing:saltire=* are somewhat distracting. Iâd suggest devoting more space to explaining the concept of a conflict point and contrasting it with a bona fide crossing. The explanation can mention crossing:saltire=*, among other things. Iâd also suggest removing the passage about implied protection systems or relegating it to a footnote, because it risks unintended future consequences in regions where itâs inaccurate.
Regarding bona fide crossings, navigation applications are already behaving more or less as they should by alerting the user about railway=level_crossing and railway=crossing and nothing else. If validators would simply guide mappers to use these tags more judiciously, then no algorithmic change would be necessary. Routers wouldnât need to consult crossing:saltire=* or even the tags on the crossing railway. (The latter could be impractical, bordering on infeasible for some routing engines. You bring up StreetComplete as precedent, but it isnât a routing engine â it doesnât need to transform OSM wholesale into a routing graph or perform map matching.)
1 Like