Proposal talk:Czech Railway Signalling (Signs)

Please note that, for ease of orientation in open issues, this talk page uses an Archive. For searching in resolved issues, please use the Archive search box on this page.

Competing scheme by HaPe-CZ

In parallel, HaPe-CZ has developed a scheme with great dedication and effort to documentation and tools, which in some parts competes with this proposal. See:

• User talk:HaPe-CZ/Proposal:Czech Railway Signalling (Signs)
• Proposal talk:Czech railway signalling
• Cs:Railway OSM vs ORM

--Chris2map (talk) 14:52, 7 May 2026 (UTC)

Various minor comments regarding the selection of keys

I would like to suggest the following changes:

• Lichoběžníková tabulka is also used in Austria and Germany on branch lines for that purpose (German name "Trapeztafel", German abbreviation "Ne 1"). It is tagged as railway:signal:main=DE-ESO:ne1 or railway:signal:main=AT-V2:trapeztafel. Therefore, I suggest to change its tagging to =* + =* + =*. stop is for signals indicating where to stop at a platform (depending on the length of the train).
• Konec vlakové cesty / Koncovník: If this sign marks the location where vehicles can be parked next to a point without being a danger for movements on a neighouring track, you should change the key to railway:signal:fouling_point.

--Nakaner (talk) 09:14, 2 June 2026 (UTC)

Hi there, thanks for reading the proposal and the feedback!

Concerning the Trapeztafel - I am aware of the difference in tagging with Germany and I did have a discussion about that on discord [1].

• To summarize - even though it is the same physical sign, it has a slightly different oprational rules in Czechia.
• It is only used on lines with reduced ruleset (In Czechia it's called D3; German equivalent would be ZLB)
• It cannot replace a main signal on lines with the normal ruleset.
  Furthermore the Czech ruleset has a list of what's considered a main signal, and the Lichoběžníková tabulka is not on that list.
• In Czechia, it doesn't have a distant signal (that would probably put it into the minor category)
• The operating rules match the description of the stop category closely:
  On branch lines with simplified operational rules, this signal may also be used to mark a position where a train has to stop to wait for a permission to proceed.
• So I believe the different categorization for Czechia is appropriate. What do you think?

Detective-fiasco (talk) 11:16, 2 June 2026 (UTC)

Thank you for your response. I am fine with that, it make sense. Nakaner (talk) 12:20, 3 June 2026 (UTC)

Perfect, that's settled then. Detective-fiasco (talk) 19:48, 3 June 2026 (UTC)

Resolved marker has been removed by --Detective-fiasco (talk) 09:13, 27 July 2026 (UTC) Detective-fiasco (talk) 12:16, 18 July 2026 (UTC)

Unresolved marker has been removed by --Detective-fiasco (talk) 09:13, 27 July 2026 (UTC) The issue has not been fully resolved; it combines elements of domestic and foreign regulations that are incompatible, with different meanings and different applications in practice. HaPe-CZ (talk) 12:38, 24 July 2026 (UTC)

No other party has had a problem with the categorization. (I have had the same discussion on Discord with other people.) I am not planning to change the proposal in this matter. Detective-fiasco (talk) 08:41, 27 July 2026 (UTC)

I split the response into two messages, so that the debate for both of the signs can be separate.

Concerning the Koncovník

• We do actually have a traditional fouling point "sign" called Námezník
  White horizontal beam with two black stripes. [2]
  • I did not add it to this proposal, since there is one near every switch, so the map would be littered with them, and I do not see a clear gain by mapping them.
  • But perhaps I should add it?
• Then we have the Koncovník
  A horizontal beam with one white and one red side.
  • It marks the place where the train has to stop in when a main signal is not positioned directly next to the track (or when there is only one signal for multiple departure tracks).
  • That place doesn't necessarily have to be a near a fouling point. (I do have real world example usages in mind, where that's the case)
• The Námezník (fouling point) and Koncovník (stop) can be merged into one physical beam.
  A horizontal beam with one white and one red side with two black stripes [3]
  • If, in the future, somebody wants to start tagging Námezník, there could be a key conflict in these situations.
• But yeah, this should probably be rethought a bit.

Detective-fiasco (talk) 11:40, 2 June 2026 (UTC)

Thank you for explaining the differences between Koncovník and Námezník. Under these circumstances railway:signal:stop is the better key for a Koncovník. If a Koncovník and a Námezník are merged into one physical beam, one could tag it as railway:signal:stop=CZ-D1:koncovnik + railway:signal:stop:form=sign + railway:signal:fouling_point=CZ-D1:nameznik + railway:signal:fouling_point:form=sign. Here in Germany, fouling point signs are usually not mapped at all. Either because mappers think they are unnecessary and could be derived automatically from track geometries, or because more important signals are still waiting to be mapped. --Nakaner (talk) 12:29, 3 June 2026 (UTC)

Yes, the your proposed tagging is great.

I am thinking of explicitly covering the three cases (nameznik, nameznik+koncovnik, koncovnik) by three separate chapters in the proposal.

However, I am a bit unsure about the placement of the signal node. Specifically the fouling point signals seem to be mapped not on the rail-ways :) but as a separate node representing the actual signal position. (Which makes sense, since it applies to two tracks, and the international tagging doesn't exactly support these cases. It would require two nodes, one on each one of the tracks to map this one physical object)

But since the Koncovnik is actually a directional signal, it would be preferable to put it on an osm way. (So that we can use :direction=forward|backward.)

So what to do when the Koncovnik and Nameznik are merged? I don't have a nice solution for that yet - suggestions are welcome.

--Detective-fiasco (talk) 20:59, 3 June 2026 (UTC)

Alrighty, I've thought about this for a bit and decided on - not adding tagging for either koncovnik nor nameznik yet - to me it seems like the most reasonable solution:

• Koncovnik is (in most instances) directly related to main light signals, which should put it out of scope of this proposal.
• Also it is something like the "place where a signal has effect" for light signals which are valid for multiple tracks. I believe that a better solution for signals valid for multiple tracks should be a bigger discussion, and imho it better fits in the (potential followup) light signal proposal discussion, or perhaps as a standalone proposal alltogether. It will might affect the requirements for the "places of effect". So I am intending to postpone the introduction of tagging for the koncovnik and nameznik until that discussion has happened.
• I will update the proposal momentarily.

What do you think?

--Detective-fiasco (talk) 10:58, 24 June 2026 (UTC)

Resolved marker has been removed by --Detective-fiasco (talk) 09:13, 27 July 2026 (UTC) Detective-fiasco (talk) 12:17, 18 July 2026 (UTC)

Unresolved marker has been removed by --Detective-fiasco (talk) 09:13, 27 July 2026 (UTC) opět nesprávný výklad. Confusing use of the terms “námezník” and “koncovník,” which have two practically entirely different meanings, and a misunderstanding of railway regulations. HaPe-CZ (talk) 12:41, 24 July 2026 (UTC)

This has been solved by removing the debated tagging from the proposal alltogether. Detective-fiasco (talk) 08:31, 27 July 2026 (UTC)

What do you think?

--Detective-fiasco (talk) 10:58, 24 June 2026 (UTC)

What do I think? That you keep coming up with more and more nonsense.

• You still haven’t understood the difference between a substitute signal and a call signal.
• You’re confusing the meanings of the stop signal and the entry signal.
• You can’t describe examples of speed limit signals (see image) according to your own instructions.

HaPe-CZ (talk) 05:43, 28 June 2026 (UTC)

See example tagging in #Response to criticism from user HaPe-CZ

Resolved marker has been removed by --Detective-fiasco (talk) 09:25, 27 July 2026 (UTC) Detective-fiasco (talk) 12:19, 18 July 2026 (UTC)

Note: The user Detective-fiasco continues to confuse the territorial divisions and railway regulations of the German and Czech railways. He is unable to determine whether a line is located in the Czech Republic or Germany, which is why he posts such nonsense. HaPe-CZ (talk) 13:22, 2 June 2026 (UTC)

Unresolved marker has been removed by --Detective-fiasco (talk) 09:13, 27 July 2026 (UTC) An unresolved issue; according to the proposal, this cannot be described. In reality, these combinations may exist. HaPe-CZ (talk) 12:42, 24 July 2026 (UTC)

The tagging is possible and has been explained in this reply [4]. This comment chain is simply a duplicate of that comment chain. Please be so kind and direct further replies there, so that the disussion is more organised. Thanks!

Moved to another comment chain

Detective-fiasco (talk) 08:39, 27 July 2026 (UTC)

An example of inappropriateness or poor design

Based on this example (see the image above), it is clear that even the author of the proposal is unable to describe the example in question according to his own proposal. This is because the description would require the creation of an excessive and nonsensical number of tags, combined in both English and Czech. An example of creative work (taken from the proposal):

• railway:signal:speed_limit:speed:horni_n = 100
• railway:signal:speed_limit:speed:n_s_pruhy = 75
• railway:signal:speed_limit:speed:prechodnost_3 = 40

This is, therefore, a completely nonsensical combination of tags—utterly incomprehensible and misleading. According to this proposal, similar descriptions will be created, such as:

• railway:signal:speed_limit:speed:prostredni = any ... (middle)
• railway:signal:speed_limit:speed:dolni = any ... (lower)
• railway:signal:trpaslik = CZ-D1:trpaslici_navestidlo ... (dwarf)

These combined descriptions cannot be translated from English to Czech or from Czech to English. The reason is the combination of two languages in a single text and, above all, the loss of diacritical marks and commas during translation.--HaPe-CZ (talk) 07:42, 1 July 2026 (UTC)

These subkeys should be translated to English somehow. E.g. railway:signal:speed_limit:speed:ns → railway:signal:speed_limit:speed:tilting. The remaining statements are off-topic. Rokolell (talk) 11:45, 2 July 2026 (UTC)

• You're right, I made a mistake. But you just explained to the user "detective-fiasco" why they shouldn't use Czech tag descriptions. Thank you :)
• The other cases also involve signs where:

1. there are multiple signs stacked one above the other, and
2. the direction of travel toward the turn is indicated

HaPe-CZ (talk) 07:54, 12 July 2026 (UTC)

See #Some notes (Entbert) where this topic is discussed in more detail.

Other cases have also been explaned in another chapter and in the proposal itself. Links inton the proposal have already been provided to this specific user.

Resolved marker has been removed by --Detective-fiasco (talk) 09:13, 27 July 2026 (UTC) No further action neccessary - please direct your comments to the appropriate chapters Detective-fiasco (talk) 12:25, 18 July 2026 (UTC)

Unresolved marker has been removed by --Detective-fiasco (talk) 09:13, 27 July 2026 (UTC) A case similar to the one above, compounded by a confusing mix of Czech and English in the description. HaPe-CZ (talk) 12:44, 24 July 2026 (UTC)

Moved to #Naming of subkeys of railway:signal:*:speed:*Multiple comment chains redirected to one chapter

Detective-fiasco (talk) 08:54, 27 July 2026 (UTC)

System Solution to the Example

The solution (see the image above) is, of course, as simple as using standard tags (if anyone has read the general, comprehensive guide on how to describe multiple objects, but hardly anyone bothers with that). The system description is then simple, clear, and easy to understand, without the need for a double translation between En/Cz.:

• System Solution for Example A

railway=signal
railway:signal:speed_limit=CZ-D1
railway:signal:speed_limi:form=sign;sign;sign;
railway:signal:speed_limit:speed=100;80;60;
railway:signal:speed_limit:shape=NSsquare;round;square;

• System Solution for Example B

railway=signal
railway:signal:speed_limit=CZ-D1
railway:signal:speed_limi:form=sign;sign;
railway:signal:speed_limit:speed=80;60;
railway:signal:speed_limit:shape=|square|;square;

• System Solution for Example C

railway=signal
railway:signal:speed_limit=CZ-D1
railway:signal:speed_limi:form=sign;sign;sign;
railway:signal:speed_limit:speed=60;50;40;
railway:signal:speed_limit:shape=square;square;square;
railway:signal:minor=CZ-D1
railway:signal:minor:form=sign;none;sign;
railway:signal:minor:function=arrow_left;none;arrow_right

System Tags Used / Description according to: railway:signal:speed_limit and railway:signal:minor . --HaPe-CZ (talk) 08:17, 1 July 2026 (UTC)

Hi, what do you mean by the general, comprehensive guide on how to describe multiple objects. Is there an osm-wide guideline for that, could you provide a link? I would be happy to incorporate these osm-wide guidelines into the proposal. Thanks Detective-fiasco (talk) 01:27, 2 July 2026 (UTC)

1. https://wiki.openstreetmap.org/wiki/Multiple_values
2. https://wiki.openstreetmap.org/wiki/Dual_tagging
3. It would also be possible to use relations, but that would be complicated (though not for me).

That is exactly the kind of systematic tagging that detective-fiasco has been ignoring the whole time. HaPe-CZ (talk) 08:00, 12 July 2026 (UTC)

In the case of multivalue tagging, I do belive that this proposals speed limit signal tagging falls within the bounds of Multiple_values#Avoid_MV_tagging_if.... Specifically points 2 and 3.

Dual tagging is explicitly supported in the examples sections. Detective-fiasco (talk) 11:07, 14 July 2026 (UTC)

But it must also be done correctly and logically—not one example following one pattern, but all cases following the same pattern. HaPe-CZ (talk) 08:26, 18 July 2026 (UTC)

Please specify where in this proposal are the guidelines not followed and why, otherwise no action can be taken to correct the proposal (e.g. if there is nothing to correct) Thanks Detective-fiasco (talk) 12:27, 18 July 2026 (UTC)

Response to criticism from user HaPe-CZ

Moved from Proposal_talk:Czech_Railway_Signalling_(Signs)/Archive_1#Articles_by_User:HaPe-CZ

Comment	Response
A.1	Beyond the scope of this proposal (concerning light signals)
A.2	Beyond the scope of this proposal (concerning light signals)
A.3	Fixed in this proposal, this proposal uses slightly different approach to solve this problem. See relevant chapter
A.4	HaPe-CZs comment actually doesn't align with the international definition of :type and :shape. Objectionable statement “Tag Type [byl] od počátku popsán jako rozmístění a barva světel”; that is not true given the international standard. It is true only when limited to tagging in Czechia. The relevant issue is solved by the same approach as in A.3 See relevant chapter
A.5	Beyond the scope of this proposal (concerning light signals)
B	Beyond the scope of this proposal (concerning light signals)
C.1	Describes an inherent weakness in the OSM database schema (the fact that there is no actual schema, but everything is a key-value pair). That's something known, and the issues that HaPe-CZ describes in his critisism (e.g. using wrong value for a key) is not something that I find relevant for this proposal.
C.2	Beyond the scope of this proposal (concerning light signals)
C.3.1	Beyond the scope of this proposal (concerning light signals)
C.3.2	Actually fixed in this proposal See relevant chapter
C.4.1	Beyond the scope of this proposal (concerns quality of existing data)
C.4.2	Beyond the scope of this proposal (criticism of tagging not in this proposal, :deactivated)
C.4.3	Beyond the scope of this proposal (concerning light signals)
C.5	I have used the same approach as the tagging for Germany, Austria (and perhaps other countries) do. The tagging for those countries is widely accepted and there are no major discussions around it.
D.1	Beyond the scope of this proposal (concerning light signals)
D.2	Beyond the scope of this proposal (concerning light signals)
D.3	Beyond the scope of this proposal (concerning light signals)
D.4	(Same as C.3.2) Actually fixed in this proposal See relevant chapter
D.4.1	Example usages of a competing tagging system (not immediately relevant to the proposal)
E	Example usages of a competing tagging system (not immediately relevant to the proposal)
F	Rendering details of a competing tagging system (not immediately relevant to the proposal)
Známé chyby popisu	Beyond the scope of this proposal (concerning light signals)

--Detective-fiasco (talk) 18:22, 18 May 2026 (UTC)

• add A.3 ... The problem hasn't been solved; it's just a cosmetic fix that doesn't address the issue—merely an attempt at a solution that isn't really a solution at all.
• add A.4 ... Detective-fiasco should first read the "SHAPE" article in the German version and check when it was created and what it describes "shape", Stejně tak v anglické verzi "shape". Just for the record, no one has disputed or commented on these articles, and the Germans are usually quite meticulous about such things. So Fiasco might want to stop messing with the system tags and accept that his proposal is flawed.
• add C.1 ... Yes, this highlights a weakness in the "detective-fiasco" proposal, where it is possible to misrepresent the actual state of affairs. Such instances of potential mis-tagging (whether due to ignorance or deliberate stupidity) should be eliminated.
• add C.3.2. ... the labeling used by "detective-fiasco" creates a completely nonsensical description of multiple speed cameras that is difficult to decipher in retrospect; it lacks a coherent descriptive logic.
• add C.5 ... The same old story ... "They do it elsewhere, so I'll do it too" ... is a classic example of being influenced and manipulated by the majority, who fail to understand that things are changing and that their description is somewhat outdated. The original description that detective-fiasco clings to is truly archaic and was created to lighten the server’s load (it lacked the necessary performance); over the past decade or so, server performance has improved significantly, but that has likely escaped the notice of most people with a limited perspective. It is also a question of whether ORM runs on the official server or is just “nibbling away” at the server’s time somewhere (data is processed at night) without the actual operator knowing about it.
• add D.4 ... see C.3.2 the same type of design errors.
• add D.4.1 ... On the contrary, they address this very topic and the flaws in the "detective-fiasco" proposal. Once again, we see the manipulation of facts—a recurring tactic of the "detective-fiasco"—specifically in cases where its error is clearly evident.
• add E ... indicates a systematic approach to tagging, so it falls under the category of criticism.
• add F ... This highlights the excuses for using an outdated system and also reveals the developer’s lack of proficiency with ORM. They likely lack the ability to handle more complex algorithms and tasks. The examples cited in the critique were developed and implemented using programming tools that are more limited than ORM. So this is a compelling argument regarding the capabilities—or rather, the lack thereof—of implementing visualization using ORM.
• Although the other points (unannotated) are not directly part of this proposal, they are nonetheless highly relevant from the perspective of systematic tagging.

--HaPe-CZ (talk) 19:57, 25 May 2026 (UTC)

• A.3
  • The proposed tagging uses the speed suffix, which is what you suggest to be correct, since the signs do not change the speeds they indicate.
  • nevytvářet několik vedle sebe ležících bodů s popisem pro každou rychlost zvlášť - this is achieved in most cases. I should note that those are the same supported cases as is the case for HaPe-CZs tagging.
  • Do you find any other insufficiecy in this specific part of the tagging?
• A.4
  • Shape definition says it is used to differentiate signals which may display similar states with the same meanings. Two speed limit signs with different shapes do not have the same meaning (as they do not apply to the same category of vehicles), therefore I find the shape suffix inappropriate to differentiate them.
• C.3.2
  • So your specific problem is with the names of the :speed:<something> suffix? If that's the case, sure, I do find this part to be a bit wonky, I would appreciate recommendation on the naming of these.
  • Hovever, I believe that the splitting of different speed profiles into separate speed tags is the most reasonable approach. (Pairing two tags, shape+speed together, where some values in the shape (e.g.NSsquareX) doesn't have to have an associated speed is imho succeptible to desynchronization between the two tags.)
• D.4.1
  • Could you add specific examples the tagging can do and the proposed tagging cannot? The current examples can easily be expressed using the proposed schema.

I won't reply to the other parts, since they either add no further information than what was already present. Or attack me or other people personally instead of pointing out specific flaws in the proposed tagging schema.

--Detective-fiasco (talk) 22:31, 25 May 2026 (UTC)

• A.3 The difference is that some things stem from the tagging system, while others are simply creative efforts designed to be "squeezed in" there somehow.
• A.4 You described it correctly; the shape determines the specifications for different vehicles. That is why they are listed in the tag designated for that purpose, along with specific speeds. (A typical example of how "detective-fiasco" causes the discussion to go in circles.)
• C.3.2 Do you have any suggestions on how to solve this? Sure :) Stop coming up with nonsensical descriptions crammed into a single line when there are tags specifically designed for such system descriptions—tags that, with a little knowledge of English, are understandable even abroad. / e.g.NSsquareX ... If the speed isn't specified (or can't be entered), just type "none." It's that simple. Otherwise, decoding paired elements between two tags isn't complicated at all—it's simply a matter of two vectors, and the specific item has the same index. Unfortunately, Hidde Wieringa can't process that (the computer can, but he can't). Otherwise, I can't explain his results :).
• D.4.1 And conversely, what does system tagging not allow? Once again, this is a classic example of how a detective-fiasco, when he runs out of arguments, changes the subject. And when I tell someone they’re doing it wrong, he claims it’s a personal attack. It’s laughable.

--HaPe-CZ (talk) 15:57, 27 May 2026 (UTC)

• A.4
  • The shape suffix is, in my understanding, used to diferentiate visually diferent variants of the same signals, example would be SSSR vs AŽD light signals, as the have EXACTLY the same meaning.
  • Speed limit signals do differ in shape, but that shape is actually significant for the meaning of them (e.g. which trains the signal applies to) - therefore it doesn't completely fit the shape suffix definition (which requires the exact SAME meaning). Imho more fitting tag for this would be :type
• C.3.2
  • Sure, none is a great value for this specific usage, I agree. I would request it to be used consistently like that, then.
  • About the two vectors, sure it's renderable and implementable - but it's not just about the ORM.app rendering, It's also about all the other software around OSM. For example: Multiple simple key-value tags are easy to support in the iD editor, just by adding a custom tagging preset. Two inter-dependent keys with lists of values are not, as there is not a field currently implemented for that (so that it would prevent invalid states = differing vector lengths). Yes - it's implementable, but is it really necessary to develop a specific field for just this tagging instead of simply following supported conventions?
  • Therefore, from my point of view, using multiple key-value tags is preferable.
• D.4.1
  • I don't quite understand what you're trying to say here. You say that the section solves flaws, yet all the examples are directly translatable to the proposed tagging (I am happy to translate them, if it's necessary to move the discussion further). What flaws, e.g. something the proposed tagging cannot express, does your tagging solve (other that the disagreement on the keys used in and the overall structure of the proposed tagging)?
  • To be specific this proposal intentionally changes the structure of the tagging for speed limit signs to be (in my opinion) more in line with the international schema, easier to support by data consumers and editors, and less error-prone (see C.3.2)
• If you think there are other specific as-of-yet undiscussed issues with this proposal, please do bring them up specifically so that I can respond to them, and possibly update the proposal accordingly.

--Detective-fiasco (talk) 22:50, 27 May 2026 (UTC)

Here is one example that illustrates the flawed nature of the proposal:

• "railway:signal:speed_limit=CZ-D1:hlavni_navestidlo"

For non-Czech editors:

• "railway:signal:speed_limit=CZ-D1:main_signal"

which is complete nonsense—exactly what Fiasco is proposing. According to this description, the signal panel would be a separate element, not part of the variable signaling on the signal. Not to mention the persistent ignorance of what a substitute signal is. This is explained and described in the Regulations; ignoring this traffic regulation is nothing short of vandalism.

--HaPe-CZ (talk) 18:46, 30 May 2026 (UTC)

Your example is nowhere in this proposal, nor does this proposal imply this is the correct way to tag that.

--Detective-fiasco (talk) 19:36, 30 May 2026 (UTC)

• A.4

You've missed the point again. The signals are similar but not identical, especially in terms of the placement of the white light (which wasn't even a substitute signal back then, but I guess you'll never understand that).

That's why we have "shape," which defines shapes such as circles, rectangles, and triangles, and that's how we distinguish between them. I suppose this is another difficult concept to grasp.

• C.3.2

You should start by taking a look at yourself and stop vandalizing signal descriptions by repeatedly adding the "substitute_signal" tag, which has a different meaning in the Czech Republic than elsewhere—as is clearly explained in Regulation D1, if you understand it.

Who says you can't handle two vectors? Is that your own idea, or did hiddewie put that in your head? If an editor can check for general errors and inconsistencies (e.g., missing tags, overlapping objects, etc.), it can also compare the lengths of two vectors and flag this—indeed, in PHP and other languages, there are built-in functions specifically for calculating vector lengths. But someone would have to look for ways to solve it; instead, they’re looking for ways not to solve it.

Yes, multiple tags—those are the two vectors, each in a separate tag (for example).

• D.4.1

With system tagging (which was invented by a pretty smart person back in the day), you can do a lot of things, and there’s no need to come up with lengthy descriptions that aren’t easy to understand.

On the contrary, your description is extremely prone to errors due to typos, spaces, underscores, semicolons, accents, commas, etc. Descriptions should be short, concise, and unambiguous. Your descriptions are unnecessarily long, which is precisely why they are completely incomprehensible to foreigners, who simply don’t get it.

• Your suggestion is nonsense; you're just parroting other (equally nonsensical) descriptions.
• "railway:signal:speed_limit=CZ-D1:hlavni_navestidlo" ... This is the result of your description and the result of the tagging. An example of errors and nonsense.

HaPe-CZ (talk) 13:51, 2 June 2026 (UTC)

• A.4
  • I do understand your point - if something differs in shape, then the put in the :shape suffix.
  • However as I said, from my understanding, another part of the definition of the :shape suffix takes precedence. Specifically the part where the the shape must be the only difference, no other meaning of the signal may be changed by changing the shape.
  • Your suggestion is noted, I am not planning on changing the proposal in this matter.
• C 3.2
  • Valid - I already said that my tagging of substitute signal is debatable (similarly with "railway:signal:speed_limit=CZ-D1:hlavni_navestidlo"), and I am intending to open that discussion in a followup light signal proposal. Until then I am planning on adding new data to osm in a self-consistent manner, e.g. not changing the schema until a decision has been reached. I will propose a mass-edit of the tagging once a consensus is reached.
  • Who says you can't handle two vectors? Nobody - I just pointed out it adds complexity to any editor or consumer which wants to support the tagging. (Because it needs to synchronize the two lists (and that's something not many (if any) tagging schemas in osm require).
• D 4.1
  • Lengthy tags is a valid criticism - let's work on that.
  • As one of the design points (I outlined in the previous proposal talk), the schema should be able to differentiate different types of sign signals belonging in the same category. Example: posun zakázán sign, označník sign, konec obvodu vlečky sign
  • I did take inspiration from abroad, where they use a national suffix + identifier of the sign (either a code or its name) to differentiate them
  • In most cases I used transcriptions from the D1 regulation as the name of the sign. Admittedly, this can get quite long, and I am not against meaningful shortening of the names.
  • How would you suggest to approach differentiating these signs? What would you propose to use the as identifier? Or, alternatively, how would you replace the use of the identifier?
  • The lengthy identifiers wouldn't be that big of a problem if there is an editor that supports the tagging schema (Which can be done easily by generating JOSM presets or creating a fork of the id-tagging-schema repository).
• D 4.1
  • What exactly do you mean by system tagging? Are you implying that your tagging is aligned with the descriptions on the page Tag:railway=signal?

Detective-fiasco (talk) 14:30, 2 June 2026 (UTC)

A.4

• he shape must always be specified, because speed limits are differentiated based on the shape—for different trains. That is why I implemented this in the speedometer description as a vector and a second vector to represent speed.
• "However as I said, from my understanding, another part of the definition of the :shape suffix takes precedence. Specifically the part where the the shape must be the only difference, no other meaning of the signal may be changed by changing the shape." ... I really don't get what that was supposed to mean. Something like "blue is blue, a square is a square"?
• For example, "Horní rychlostník N" / "Upper Speed Limit Sign N," where there are multiple speed limit signs, is a completely nonsensical description; it's impossible to tell which sign belongs to which, or what the order of placement on the pole is. Systematic tagging using two vectors solves this. Then it becomes clear. Introducing the term "horní rychlostník" / "upper speed limit sign" is yet another made-up tag that unnecessarily burdens both the tag-generating system and the editors.

C.3.2

• That is not debatable, but completely incorrect. This misunderstanding of Regulation D1 is subsequently reflected in the incorrect description of signals and signal indications. I repeat that the system-based tagging was created based on certain rules (even if not 100% comprehensive), but it allows for the description of nearly 100% of cases.
• If he were a good programmer, he wouldn't say it can't be done. That's just a lame excuse. It might be complicated, but it's solvable. My examples are built on the same programming language and they work.

D.4.1

• In my opinion, the English description is short and to the point when combined with systematic tagging. Systematic tagging is precisely what addresses the issue of long descriptions, because just as a signal is a combination of shapes and colors, systematic tags have the same structure. Neither you nor anyone else noticed this (only the author of the tags, who created them systematically, thought of it).
• The scope (detail) of the description of landmarks and landmarks should be based on the principle of "landscape creation"—that is what mapping is all about: what an ordinary person sees on the ground. Maps, among other things, serve for orientation in the terrain, showing landmarks (hills, buildings, trees, rivers, dams, roads, bridges, railways, power poles, telegraph poles, transmission towers, and even signal posts). In other words, what can be seen in the terrain. When it comes to signal posts, it’s about 50/50 because they are classified as signals. Railway signs (speed limits, whistle signs, level crossing signs, gradient signs… what’s on the post) are no longer visible as landmarks on the map and are therefore unnecessary. The track boundary, railway district boundary, and others are completely invisible on the map and in the field, and are therefore unnecessary on the map. These belong on special railway administration track maps but not on OSM, because they are not landmarks in the field, do not form the landscape, and are not orientation points.
• Inspiration from abroad: Okay, but in your case, you’re just copying it over with the excuse that they do it that way too. Different rail systems have their own specific characteristics; even the metro and trams in the Czech Republic use different signals and signs, and this is all within a single country. If signals are to be displayed somewhere, their presentation must be adapted regionally to match Czech signals. See my examples of signal and sign visualizations. It’s no problem to add, for example, gradient tables for demonstration purposes. Hidde Wieringa actually handles this in real life, which is why he sticks to an outdated description taken from the defunct orm.org project.
• If we use D1, that's fine; the metro could be M, and trams could be T. If we use system tagging, those names will logically be shortened, as I mentioned above.
• I'm laughing. Do you think I can't expand my signal description program to include track markers, panel signals, and the generation of descriptive tags?

D.4.1

• Yes, I think the system-based tagging is better and more in line with the description in the link. That’s also what I based my approach on, following the descriptions in other languages. Those who don’t want to won’t be able to compare. Your description of signals for ORM, as well as the foreign ones, are completely at odds with the principles described in the guide and in the help section, including the foreign ones.
• System tagging uses what is and what has been designed (which makes perfect sense). Your tagging creates a separate description for each case; it’s too much and confusing.
  • If you had cooperated a little from the start, Hidde Wieringa could have demonstrated his superior programming skills instead of copying an outdated ORM mapping system. It simply won’t work without dynamically generating signal lights and signals. His method of generating them based on a single vector is a task for elementary school students, not for a professional (as he claims to be).

HaPe-CZ (talk) 15:23, 9 June 2026 (UTC)

Since you did not provide any actionable comments or suggestions, no changes to the proposal will be made.

Thanks --Detective-fiasco (talk) 16:45, 9 June 2026 (UTC)

A great many suggestions and comments were recorded. Only someone who refuses to engage in constructive discussion based on reality and actual cases would refuse to communicate. On the part of "detective-fiasko," there is no effort to resolve the issue or reach a consensus.

What will the tagging look like in the case shown in the image? Will it be another fiasco?

HaPe-CZ (talk) 13:55, 11 June 2026 (UTC)

Everyting you need to know to construct the tagging is in the proposal, mostly in this chapter: Proposal:Czech_Railway_Signalling_(Signs)#Více_rychlostníků_na_jednom_místě

Ilustration A has an analogous example (with different speed limit values) in the following chapter Proposal:Czech_Railway_Signalling_(Signs)#Více_rychlostníků_na_jednom_místě

Ilustration B has an analogous example (wicht different speed limit values) in the following chapter Proposal:Czech_Railway_Signalling_(Signs)#Horní_rychlostník_N_se_svislými_černými_pruhy

Ilustration C would need to be tagged as theree separate OSM nodes, as mentioned here: Proposal:Czech_Railway_Signalling_(Signs)#Více_rychlostníků_na_jednom_místě.

Two of the nodes would need the :turn_direction tag Proposal:Czech_Railway_Signalling_(Signs)#Směrové_šipky_na_rychlostnících

If you're going to complain that the proposal cannot do something, would it bother you to at least look at the list of chapters to see if that's really the case? Detective-fiasco (talk) 01:04, 2 July 2026 (UTC)

Completely nonsensical descriptions that no one can make sense of. There’s no logical order to the descriptions—is it from top to bottom, or bottom to top? How are the directional arrows added at the junctions (switches)? There’s no system to the descriptions; they lack a consistent structure and logical flow. It’s just all “thrown into one big pile.” HaPe-CZ (talk) 08:07, 12 July 2026 (UTC)

The order of signals should always be the same (as defined by D1). Directional arrows use the :turn_direction subtag. Detective-fiasco (talk) 11:09, 14 July 2026 (UTC)

Many comments and errors have been pointed out. You can simply read them on this page and others. HaPe-CZ (talk) 08:08, 12 July 2026 (UTC)

I did and I responded to them. I have already fixed or am in the process of fixong of those I deem apropriate with the whole concept and general rules of the proposal. Detective-fiasco (talk) 11:03, 14 July 2026 (UTC)

Staničníky

Co se týče staničníků, uvítal bych, kdyby se dalo rozlišit, zda se jedná o kamenný hranol, nebo o obdélníkovou desku. V praxi se lze ještě setkat taky s případy, kdy je staničník součástí hrany nástupiště nebo zdi přilehlé budovy. Předpis D1 to sice nezná, ale objevuje se to, tudíž by bylo fajn mít způsob, jak to popsat (např. něčím jako railway:milestone:type ?). Bilykralik16 (talk) 18:42, 24 July 2026 (UTC)

Souhlasím s nápadem - zároveň třeba i u označníků by se hodilo rozlišovat sloupek a cedulku na sloupku. Přijde mi vhodne přidat novou variantu do railway:signal:*:form=sign (pro fyzicke objekty ktere nejsou cedulky, zatim mne nenapada co) a pak pouzit podobne tagovani pro railway:milestone:form=sign/nova_hodnota. Na mezinarodnim discordu toto tema nadhodim. Detective-fiasco (talk) 21:11, 24 July 2026 (UTC)

Navrhnul bych použít hodtnou marker jako novou hodnotu pro form. Tagování by pak vypadalo následovně:

• Označník jako cedulka:

railway=signal
railway:signal:shunting=CZ-D1:oznacnik
railway:signal:shunting:form=sign

• Označník jako kolík:

railway=signal
railway:signal:shunting=CZ-D1:oznacnik
railway:signal:shunting:form=marker

• Staničník jako cedulka

railway=milestone
railway:milestone:form=sign

• Staničník jako kámen

railway=milestone
railway:milestone:form=marker

• Ostantní varianty staničníků bych řešil jako :form=sign a poznámkou note=*

Je otázka, jestli tohle neoddělit do dalšího proposalu, protože zavádění takhle významné hodnoty by mohlo mít důsledky i pro zahraniční tagování?

Díky za feedback! --Detective-fiasco (talk) 18:25, 29 July 2026 (UTC)

Mně se ten nápad jako takový líbí, akorát u těch ostatních variant by možná stálo za to označit je např. jako :form=other nebo něco tomu podobného. Ona to mnohdy není cedulka, ale jako kámen se to taky úplně klasifikovat nedá. Bilykralik16 (talk) 07:54, 30 July 2026 (UTC)

Ano, souhlasím - v brzké budoucnosti pro to vytvořím samostatný proposal. Detective-fiasco (talk) 13:55, 30 July 2026 (UTC)

Naming of subkeys of railway:signal:*:speed:*

There seems to be an ongoing debate and disagreement on the naming of the subkeys of railway:signal:*:speed.

This discussion is happening in multiple chapters simultaneously, so I created this chapter to unify the discussion and have it all in one place.

Moved from Proposal_talk:Czech_Railway_Signalling_(Signs)/Archive_1#Some_notes_(Entbert)

Moved from #An example of inappropriateness or poor design

Moved from last few comments of #Response to criticism from user HaPe-CZ

I am currently working on followup actions outlined by user Entbert

I wonder if the :speed:..... keys could be changed to something which would be applicable to other countries as well such as :speed:freight or :speed:tilting for maxspeed:freight=* and maxspeed:tilting=*

As other countries also have differentiated speed limit signals and we lack (as far as I know) a good way of tagging these, I think it would be great to introduce some kind of unified tagging applicable to all countries. I guess this is not in the scope of this proposal though and would require knowledge regarding many national rulesets. I also get that these are often very specific categories of trains only applicable to a single country. Maybe have some international categories and others with prefix cz:?

Detective-fiasco (talk) 08:50, 27 July 2026 (UTC)