Skip to content

Conversation

davide84
Copy link
Contributor

Added support for CTCS following discussion here:
#37

TODO: finalize color, we can discuss here.

@davide84
Copy link
Contributor Author

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
Copy link

LaoshuBaby commented Nov 21, 2023

图片
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
Copy link
Contributor Author

davide84 commented Dec 7, 2023

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
Copy link

  • 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
Copy link
Contributor Author

davide84 commented Dec 7, 2023

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
Copy link

LaoshuBaby commented Dec 7, 2023

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
Copy link
Contributor Author

davide84 commented Dec 7, 2023

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
Copy link

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?

Key:railway:etcs
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?

railway:ctcs

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

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
Copy link
Contributor Author

davide84 commented Dec 8, 2023

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
Copy link
Contributor

DerDakon commented Dec 9, 2023

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.

Copy link
Collaborator

@Nakaner Nakaner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The colour is close to PZB but PZB is an outdated system (still needing a couple of decades to be replaced by ETCS). Given that PZB is limited to Germany and Austria, the colour is fine.

Zoom 2:

test rendering on zoom level 2

Zoom 3:

test rendering on zoom level 3

Zoom 4:

test rendering on zoom level 4

Zoom 5:

test rendering on zoom level 5

Zoom 6:

test rendering on zoom level 6

@Nakaner Nakaner merged commit c19a215 into OpenRailwayMap:master Feb 24, 2024
@besentv
Copy link
Contributor

besentv commented Feb 24, 2024

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

@davide84
Copy link
Contributor Author

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 #118

@besentv
Copy link
Contributor

besentv commented Feb 25, 2024

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
Copy link

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

Nakaner added a commit that referenced this pull request Feb 26, 2024
This reverts commit c0cc032.

The commit introduced a regression documented in
#115 (comment)
@Nakaner
Copy link
Collaborator

Nakaner commented Feb 26, 2024

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
Copy link
Contributor

freaktechnik commented Feb 27, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants