Rendering of Chinese CTCS signalling

[davide84]

Added support for CTCS following discussion here: https://github.com/OpenRailwayMap/OpenRailwayMap-CartoCSS/issues/37

TODO: finalize color, we can discuss here.

[davide84]

Regarding the color: at small zoom levels it is expected that three main areas of homogeneous signalling emerge, Europe USA and China. Maybe India and Russia at a later stage. So, 5 colors max? They should really not be any similar to each other, mainly because of the legend.

ETCS is blue and well established, compatible with the other many regional colors. PTC of USA is currently dark red, no other signalling rendered in the region, and even PTC is not that much used.

Options for CTCS are green, yellow/orange, or red as asked from local contributors. The use of red, at any shade, should in my opinion go together with a recoloring of PTC, which I think is at this time still possible.

A possible combination: ETCS blue PTC lilac or brown CTCS red India green Russia orange

I'm asking for a feedback from the maintainers about whether or not changing the PTC color. If not, I would swap PTC and CTCS from the list above.

[LaoshuBaby]

I just mentioned this PR in a group of mainly Chinese contributors and asked for comments A mapper who doesn't know how to use GitHub suggested pink, let's record it as an opinion.

---

What about add this to #118 now or later?

[davide84]

It could be added to PR#118. However I need

• a quick feedback from the maintainers on changing the current ATP color, which is not much used yet, and
• a quick feedback from the maintainers on that PR; if it moves forward, I'm ok with starting with two new tags instead of just one. China has to be retagged anyway due to ETCS tags

[LaoshuBaby]

• China has to be retagged anyway due to ETCS tags

In fact, I have been checking the information these days and deleted many labels that were wrongly labeled as ETCS on the railways in China.

• a quick feedback from the maintainers

Usually not quickly :sad:

[davide84]

Are you already checking the tags? Then could you add

railway:train_protection=CTCS

to all the lines you edit? This way if I incorporate the changes in PR#118 I have data for testing.

[LaoshuBaby]

Are you already checking the tags? Then could you add

railway:train_protection=CTCS

to all the lines you edit? This way if I incorporate the changes in PR#118 I have data for testing.

What I removed was the railway:etcs=1/2 tag, but some of them had the railway:ctcs=0/2/3 tag

I will go immediately check OSMWiki to determine how to tag it. (Sorry, I also ask https://t.me/OpenRailwayMap/19/897 for some suggestion)

[davide84]

According to the proposal, version numbers can be added like this:

railway:train_protection=ETCS:1LS railway:train_protection=CTCS:3

The new tagging system looks for "CTCS" or "ETCS" in the string, so version number won't affect the rendering (unless in the future we decide to).

[LaoshuBaby]

According to the proposal, version numbers can be added like this:

railway:train_protection=ETCS:1LS railway:train_protection=CTCS:3

There seems to be a discrepancy between this and what I've heard within the editor community, perhaps we need to look to the ORM mailing list and tagging for a larger discussion?

• https://wiki.openstreetmap.org/wiki/Key:railway:etcs
• https://wiki.openstreetmap.org/wiki/Key:railway:lzb

As far as the OSM Wiki is referenced, the form of railway:*=value is currently absolutely dominant, and the current use of railway:train_protection is indeed not widespread. Before we make a global revolution in railway signaling system tagging guideline, should we keep compatibility with the status quo be considered?

• https://taginfo.openstreetmap.org/keys/railway%3Actcs#overview

Because CTCS is not documented in OSM Wiki (but it does not mean it does not exist, there are more than 20,000 ways), so this is the data of taginfo

• https://wiki.openstreetmap.org/wiki/Key:railway:train_protection

I admit that railway:train_protection is a more semantically explicit key name that unifies all signaling systems.

But it takes time to go from proposal to promotion (given the cooperative model of the open source community, this usually takes several years), and what we are facing is the current status of OSM data.

[davide84]

There seems to be a discrepancy between this and what I've heard within the editor community, perhaps we need to look to the ORM mailing list and tagging for a larger discussion?

I'm happy to be referred to an active mailing list :-)

As far as the OSM Wiki is referenced, the form of railway:*=value is currently absolutely dominant, and the current use of railway:train_protection is indeed not widespread. Before we make a global revolution in railway signaling system tagging guideline, should we keep compatibility with the status quo be considered?

Yes. First comment, the PR for ORM can be absolutely compatible with the status quo. Second comment, the "status quo" is very recent - some tags like SSC started to be used just a couple of months ago. So I think it's still a good moment for a discussion, exactly before the logic gets cast in stone with years of usage. Third, introducing a tagging system does not mean removing the existing tags, although in the long term a strategy can be applied.

Because CTCS is not documented in OSM Wiki (but it does not mean it does not exist, there are more than 20,000 ways), so this is the data of taginfo

Unfortunately many things are not documented, other things are documented but in practice do not exist.

I admit that railway:train_protection is a more semantically explicit key name that unifies all signaling systems.

But it takes time to go from proposal to promotion (given the cooperative model of the open source community, this usually takes several years), and what we are facing is the current status of OSM data.

I think as long as you add things you have margin of action. Tags in OSM are full of things like A:B:construction and A:construction:B, and sooner or later consensus is reached and a bot is created to uniform the situation. I don't see a problem with the proposal.

[DerDakon]

IMHO there is no possibility to get even the "big" systems not not share colors somehow. ETCS will likely be somewhat global, and I expect the same happening for CTCS. So if CTCS would be red as the German LZB is I don't expect any clashes, as the CTCS will not likely start to exist in Germany, and LZB is waiting for it's removal (there are no new installations). But for somewhat local systems like any of the other existing European systems I personally would say they only need to be distinct from the color of their neighbor countries unless there is a big company behind them selling them worldwide, in which case we would need to discuss. At the end you will have similar colored systems in the legend.

On an unrelated note I once tried to have geofenced legend entries, i.e. if you zoom in into Europe then CTCS would be omitted from the legend or vice versa. I never really finished that, but I would love to see someone picking this up again. But before that we really need a way to get the legend use the CartoCSS style.

[besentv]

I think this introduces a regression where all tracks rendered as previously unknown are now rendered as having no train protection.

[davide84]

Regression seems confirmed... honestly, I don't understand why.

And to say everything, it's the fourth time we run into the same issue of having to check all possible combinations to detect the lack of signalling. My proposed fix is in the other PR that uses the proposed new tagging system https://github.com/OpenRailwayMap/OpenRailwayMap-CartoCSS/pull/118

[besentv]

My proposed fix is in the other PR that uses the proposed new tagging system #118

Yes, this is the right way forward imho.

[STemplar]

@davide84 don't forget to add "CBTC" to the Legend also.

[Nakaner]

I don't know why I did not notice the black lines in my own test renderings. I reverted the commit, deployed and started rerendering it a few minutes ago.

[freaktechnik]

honestly, I don't understand why.

It's because of the combination of railway_null_or_zero_to_no and just a direct condition of cbtc = 'no'. If you compare with ETCS it has a bunch of careful clauses to only actually count as no if the other systems that could be present are also explicitly marked as absent. ZSI127 doesn't use railway_null_or_zero_to_no for exactly this reason, the other systems that might be there are not tagged in most places that might not have ZSI127. And only because it doesn't default null to 'no' it can use the shortened condition.