[WIP patch] Add railway junction check for missing switches and crossings

[gaben]

If there is a Y connection on a railway, there is usually a ​Tag:railway=switch or ​Tag:railway=railway_crossing. The following lines will issue a warning if neither is on the junction node.

way[/railway$/] >[index=1] node[/railway$/!~/switch|railway_crossing/]:connection,
way[/railway$/] >[index=-1] node[/railway$/!~/switch|railway_crossing/]:connection {
        set .railway_first_last_connection;
}

way[/railway$/] >[index!=1][index!=-1] node.railway_first_last_connection {
        group: tr("missing tag");
        throwWarning: tr("use one of railway features: switch, railway_crossing");
}

It's only a partial solution as I couldn't think out a rule which works when the railway ways split at the Y junction. I wanted this to be entirely MapCSS for other services benefit, like osmose.

[taylor.smock]

Would it help if I dusted off my patch for #16998? I think the test would look like the following, but I'd have to check.

way[/railway$/] > node[/railway$/!~/switch|railway_crossing/]:connection {
    set .railway_first_last_connection;
}

way[/railway$/] > node[count(parent_osm_primitives("railway")) > 1].railway_first_last_connection {
    group: tr("missing tag");
    throwWarning: tr("use one of railway features: {0}, {1}", "switch", "railway_crossing");
}

[skyper]

railway=razed, railway=abandoned and railway=construction might lead to false positives. Personally, I use prefix for switches and crossings, too, e.g. razed:railway=switch or construction:railway=railway_crossing.

I guess a warning for situations where two or more ways are crossing with one common middle node is missing. This should be the default for railway=railway_crossing as there is usually no need to split the ways at the intersection.

I'd prefer a throwWarning: tr("Railways connection node without {0} or {1}, "railway=switch", "railway=railway_crossing");

[gaben]

Replying to taylor.smock:

Would it help if I dusted off my patch for #16998?

Yes, I think. The patch I provided is catching the most common errors (try it out on a country size railway data), but as skyper pointed out, there is room for improvement. With your added function from #16998 all cases can be covered.

Replying to skyper:
Probably I didn't get what you mean by default. Anyway, here is a PDF from the State of the Map 2018 conference with ​examples on various crossings. It shows that a simple X junction can be a switch and a railway_crossing as well.

[skyper]

Replying to gaben:

Replying to skyper:
Probably I didn't get what you mean by default.

I mean, the tags of the tracks on both sides of railway_crossing usually do not change and unlike switches relations will never lead to splitting the ways at a railway_crossing. Therefore railway_crossings should be on middle nodes (e.g. the default). We could even think about a (informal) warning for railway=railway_crossing on end nodes.

[gaben]

Good idea. I think it can be even a warning level message.

Another false positive: turntable <> rail connections.

[gaben]

New version, please test.

way[/railway$/!~/turntable|traverser|roundhouse|workshop/] >[index=1] node[/railway$/!~/switch|railway_crossing/]:connection,
way[/railway$/!~/turntable|traverser|roundhouse|workshop/] >[index=-1] node[/railway$/!~/switch|railway_crossing/]:connection {
        set .railway_first_last_connection;
}

way[/railway$/][/railway$/!~/turntable|traverser|roundhouse|workshop/] >[index!=1][index!=-1] node.railway_first_last_connection {
        group: tr("missing tag");
        throwWarning: tr("use one of railway features: {0}, {1}", "switch", "railway_crossing");
}

node[railway=~/switch|railway_crossing/]!:connection {
        throwWarning: tr("disconnected railway junction");
}

Also ping @taylor.smock for #16998.

[taylor.smock]

Replying to gaben:

Also ping @taylor.smock for #16998.

Sorry -- I've been banging my head against kendzi3d (I'm porting it from JOGL to LWJGL, so it can (a) run on Java 9+ and (b) run on ARM Macs so that when we move to Java 17, we don't have users staying back because that one plugin doesn't work). I've gone ahead and added reminder to update and merge #16998 on March 10 in my calendar.

As a heads up, I'm treating the JOSM source code as if it were in "Feature Freeze" ("Stabilization") right now for anything I merge -- we've been releasing on the first weekend of the month, when we have releases, but the wiki:/DevelopersGuide/Schedule page says that it should be the last weekend of the month. So I'm kind of leery about doing anything that isn't specific to a bug fix around those two weekends right now. I should probably ping Don-vip and see if we have officially changed the release schedule.

[gaben]

This time it's pong. The validation could be a good candidate for the next release.

[taylor.smock]

I just merged #16998. Was there anything from it that you wanted to use?

[gaben]

Yes, probably I was waiting for the parent_osm_primitives function. I have to refresh my memory :)