Hey everyone,
I'd like to share a new Maproulette challenge in Latvia: Latvia - Missing Railway Level Crossing - 210 tasks.
It aims to improve road safety by adding missing railway crossings, where needed, at intersections between major roads and train/tram tracks.
Feel free to jump in, contribute, share any feedback or local knowledge and especially whether you find it useful or not.
Thanks! :raised_hands:
Looks like 95+% are tram crossings. And most of these are rails running along roads and crossing in intersections and such.
Honestly, I don't even know how best to tag these in convoluted locations. Something like this
It's kind of silly to have like a dozen crossings here. Roads have embedded_rails=*, so I think ideally routers should not be treating these as true crossings, but I have no idea.
Good question. I’ll discuss with my colleagues to understand how such situation is treated in our routing engine and confirm whether we should exclude roads with the tag embedded_rails=* from the check.
Hi! We reviewed this with the team behind the challenge.
The multiple tram crossing tasks are expected, as OSM maps each railway/highway crossing node separately. To avoid missing any crossings, the challenge creates one task per potentially missing node, especially in complex junctions. Mappers can solve nearby tasks together in MapRoulette using the workflow explained here: https://learn.maproulette.org/en-US/documentation/solving-multiple-tasks-together/
As for roads tagged with "embedded_rails=*", we keep them in the challenge intentionally. Even where tram rails are embedded in the road, there can still be valid crossings with other tram or railway tracks that should be mapped as a specific railway level crossing node.
I completely understand that these situations can be tricky from a mapping perspective. From a routing perspective, however, nearby crossings are typically grouped into a single alert by the algorithms rather than generating multiple warnings.
Hope that helps clarify things, and thanks again for the feedback! :raised_hands:
Thanks for clarifications. I understand it's a complicated and convoluted topic. The thing with embedded rails is that an expected rail crossing depends completely on the direction or travel and turning. Take this example:
![]()
If you travel along blue line, you cross the rails twice. If you travel along the green line, you don't cross the rails at all. This can only be determined from embedded rails and not the intersecting nodes. Which is why it's not really expected to have crossings mapped there - the "crossing" there is just a consequence of the way OSM represents highways and rails in this situation. (And it's definitely not mapped consistently.) I don't really have a solution for this...
Got it, thanks for sharing this concrete example! This is exactly the kind of situation I assumed the routing algorithms would need to interpret correctly in order to provide accurate guidance and warnings.
I'll pass this on to the team for further review.
I'm also confused with the places where street with embedded rail splits into two separate directions.
Like in this case:
![]()
There are no crossings here (if you move along the road), right?
Related mapillary at https://www.mapillary.com/app/?pKey=2116746515493062, if it helps.
Yeah, that's also one of the complicated variants, because the road briefly changes between having embedded rails and not having embedded rails due to having physically separate rail platforms. I briefly mentioned this in one of the embedded rail discussions that these should not even be connected to rails, not just not have crossing tags. But we didn't arrive at consensus and all editors complain about the crossing ways issue, so in the end, they all got connected.
Indeed, I was reading couple of conversations on the forum mentioning those cases. We are looking internally what would be the best approach. I'll come back to you shortly.
Based on the examples discussed, especially the cases where certain turning movements do not actually cross the tram tracks, from the challenge standpoint, it should be considered as false positives and closed as "Not an Issue".
We also found similar nearby situations that are already mapped using railway=tram_level_crossing at 56.924430, 24.169072:
![]()
Since there is still broader discussion within the OSM community about the tagging of tram crossings and embedded rails, we don't want to prescribe a specific tagging scheme. We'd rather follow local knowledge and community consensus.
If the community feels these cases should be excluded, we can review the remaining tasks, remove similar false positives, and reload the challenge with improved filtering.
Please let me know if that sounds like a reasonable way forward.
Last updated: Sep 10 2026 at 11:46 UTC