Re: [openrailwaymap] Proposal for new Ks signal tagging scheme

TL;DR I strongly oppose any tagging changes which are - not backward compatible to existing tagging - just changes of wording to fit better to professional literature - make contributing more difficult for people with less or no knowledge of signalling rules. Hi Peter, Am 2015-07-27 um 18:38 schrieb Peter Hudec: > Proposal for new tagging scheme for Ks signals > > A. Problem > > Today there are 3 different signal "types" for tagging: > - distant > - main > - combined > signals. > > The only participant in train protection are main and combined signals. > > Distant signals do not manage the movement authority. They "just" announce the > state of the following main aspect signal. > > Combined signals are no special "type" of signal, they just be "intelligent" > with showing the signal states. > > That means, the aspects of signals can show the following: > > - main: Hp0, Ks1 > - distant: Ks1, Ks2 > > When combining two aspects, some states are suppressed: > > Main + Distant = Shown state > Hp0 + Ks1 = Hp0 > Hp0 + Ks2 = Hp0 > > Ks1 + Ks1 = Ks1 > Ks1 + Ks2 = Ks2 > > B. Solution > > It would be much more logical to map both aspects, main and distant, at one > node. > > Advantages: > - When not knowing whether a signal is main or combined, it stays flexible to > change it later. Do you know fixme=*? There are even special maps which highlight this tag. If I am not sure if a signal is a main or combined signal (sometimes I just have to look 1000 m ahead if there is the next main/combined signal), I tag it as a main signal and add fixme="may be a combined signal, please check and correct". > Nowadays, you have to delete all "combined" tags and make "main" tags an vice > versa > - No need to have 2 (main + combined) namespaces with all the properties of > signals > - No need to maintain 2 JOSM preset items That's a problem of JOSM's preset structure and should be solved at JOSM's source code. I think that the pain is not hard enough at the moment. > - Possibility to filter all main aspect signals, no matter whether they are > "combined" signals or "normal" main signals Why don't you change railway=station/halt to railway=passenger_entry_point + passenger_entry_point=station/halt? :-) It's a very similar problem because most customers do not care if the place where they enter the train has a switch or not. > To tag the states I propose to tag a main aspect signal: > railway:signal:main=DE-ESO:ks > That makes a signal identified as Ks signal, no matter of the states > railway:signal:main:states=DE-ESO:hp0 > That is what every main aspect signal can show > Optional: > railway:signal:main:states=DE-ESO:hp0,DE-ESO:ks1 Btw, we use semicolons to separate multiple values. That is the common way OSM does. railway:signal:main:states=DE-ESO:hp0,DE-ESO:ks1 should not be optional. If you do not know all states a signal can show, you have to use "railway:signal:main:states"="DE-ESO:hp0;?". (question mark as placeholder) > Every distant signal can show DE-ESO:ks2 > There is no need to tag this. Our tagging system is designed to be as international/as portable as possible. That's why some things have to been tagged even if they seem to be obvious in one country. Mandatory tags for each signal are: - railway=signal (except buffer stops and derailers) - railway:signal:direction=* - railway:signal:TYPE=COUNTRY-COMPANY/RULESET:NAME - railway:signal:TYPE:form=light/sign/semaphore - railway:signal:TYPE:states=COUNTRY-COMPANY/RULESET:NAME1;COUNTRY-COMPANY/RULESET:NAME2 (only light and semaphore signals) Very recommended but, from my point of view, not mandatory and therefore not enforced by style sheets and validation rules: - railway:signal:position=left/right/in_track/overhead It may be look like a waste of storage for you that we tag railway:signal:speed_limit:form=sign for every Lf 7 speed limit signal but the data should be usable with less or without knowledge of the signalling systems. What about users who want just count the number of semaphore main signals in a country? Following your suggestions, this would not be a problem in Germany because we already and still add railway:signal:main:form=semaphore because both light and semaphore Hp signals are tagged railway:signal:main=DE-ESO:hp. But there are other countries which may have different names for semaphore and light main signals. If they follow your suggestions (because we want to be consistent beyond country borders), this will result in an information loss. Communities of these countries would not tag railway:signal:main:form=* and therefore this query would not return useful information. http://overpass-turbo.eu/s/aCx It is never a good idea at OSM to change a already heavily used tag. Your proposal conflicts with existing tagging. [1] At the moment the signals you modified in order to match your proposal are rendered wrong by OpenRailwayMap because their tags are wrong. (rendered as Ks distant or main signal although it is a combined signal) I think that the benefits are not high enough to justify a different tagging of Ks combined signals. > If a distant signal can also show ks1, tag: > railway:signal:distant:states=DE-ESO:ks1,DE-ESO:ks2 > > There are signals before a buffer stop that can only show Hp0 and Ks2. > > They would be tagged as follows: > railway:signal:main=DE-ESO:ks > railway:signal:main:states=DE-ESO:hp0 > railway:signal:distant=DE-ESO:ks > railway:signal:distant:states=DE-ESO:ks2 This is already possible with the current tagging scheme and has been supported by our JOSM presets for a few days or weeks. railway:signal:combined:states=DE-ESO:hp0;DE-ESO:ks2 It may be a good idea to add a note=* to such signals because the usually get attention by users using data validation tools to prevent questions and disimprovements. ;-) > A marker light should not be tagged as "DE-ESO:kennlicht", as it is not clear if > it is a property of main or distant aspect. > > I propose to go back to the past with: > railway:signal:marker_light=yes > > That neutral to main or distant. This tag was too German-centric. I hope you already read the discussion at the archive of this mailing list. > The minor signal should distinguish between Ra 12 (DV) and Sh 1 (DS). > > I propose to tag: > railway:signal:minor=DE-ESO:ds:sh1 > or > railway:signal:minor=DE-ESO:dv:ra12 Why? Just because it has another name in East Germany or because it has different rules? When Alex designed the tagging scheme in 2011/2012, he decided only to use prefixes if the same signal abbrevation has a different appearance or rules in West and East Germany. > Use ds and dv namespace instead of db and dr, as DB and DR no longer exists, DV > and DS are the official abbreviations used by DBAG. > > When tagging signals that are harmonized in DS and DV = Ril301, DO NOT tag this. I do not see any benefit of ds and dv over db and dr. db and dr are easier understandable for people who don't know Ril 301 (German signalling rules) by heart. It would only result in a unnecessary mechanical renaming edit without no benefit for data users and most mappers. > Zs6 (Gegengleisanzeiger): > railway:signal:wrong_road=DE-ESO:zs6 > > Specify form: > railway:signal:wrong_road:form=sign > railway:signal:wrong_road:form=light > A light can also be Zs8. NO SPECIAL TAGGING, as it is not needed. Every Zs6 can > technically show Zs8. If the signal box can't do it, there is no need to tag > this at > > the signal. What you wrote above about Zs 6 only affects Zs 6 signals at Ks signals, doesn't it? If every Zs 6 can shown Zs 8, it should be tagged as such. Please remember that local defaults should be tagged because they are no global defaults. That's why following tagging is IMHO better: Zs 6 /light/ signals at Ks signals: railway:signal:wrong_road=DE-ESO:zs6 railway:signal:wrong_road:states=DE-ESO:zs6;DE-ESO:zs8 railway:signal:wrong_road:form=light Zs 6 /signs/ at all main signals: railway:signal:wrong_road=DE-ESO:zs6 railway:signal:wrong_road:form=sign > Tagging of the signal ref: > Distinguish between ESTW-Kennzahl and signal ref. > 16P3 > = > 16 + P3 > ref:kennzahl=16 > ref=P3 > > That makes it possible to show only the P3 in special applications. When one > needs the 16 he can take it from ref:kennzahl. I think that this separation should be done by the data users, not by the mappers. Joe Average-Mapper would tag railway=signal + ref=16P3 or railway=signal + ref="16 P3" + no other tags. How do you want to explain him that he has to use ref:kennzahl=16? We must keep the entrance level for a OSM contributor who already has some editing experience as low as possible. He should be able to enter as much data as possible without using the JOSM presets. There are lots of signals in North Rhine-Westphalia where local mappers (having no knowledge of railway signalling) just added railway=signal + ref=<number> because OSM mappers have been used to add reference numbers as ref=* for many years. (ref=* is the numeric brother of name=* at OSM) Please note that German keys and values should be avoided as much as possible! > Zs3/Zs3v: > Switch over to > railway:signal:speed_signal > > Advantage: Possibility to tag a Lf7 at the same position > > railway:signal:speed_signal=DE-ESO:zs3 > railway:signal:speed_signal:speed=60 > railway:signal:speed_signal:form=sign/light (default: sign) At railway:signal:TYPE*=* TYPE is the function, not the appearance. If you really want a differentiation between Lf 7 and Lf 6 (distant signal of Lf 7) vs. Zs 3 and Zs 3v (distant signal of Zs 3), you have to differentiate these signals by their a scope of application. Example (for non-Germans and people with less knowledge about signalling) showing the exit of a simple station, train runs to the right: -D--P1-----+1-----E----- ----P2----/ P1: main exit signal P2: main exit signal + speed limit signal Zs 3 showing digit "5" D: Lf 7 speed limit signal showing digit "8" E: Lf 7 speed limit signal showing digit "9" Speed limit signal at P2 is only valid until the last axle of the train has passed swich 1. Speed limit signal D is valid until E (or another speed limit is indicated in the timetable. If the example is between Augsburg and Donauwörth, Zs 3 at P2 is valid until E and therefore has the same function as an Lf 7 (just a different location where it is mounted). (Augsburg–Donauwörth has special signalling rules) That's why I oppose a differentiation between Zs 3 and Lf 7 at the used OSM key. How do you explain a railway fan who started contributing that he has to tag Zs 3 at Mering station railway:signal:speed_on_switch=DE-ESO:zs3 and at Gablingen station railway:signal:speed_limit=DE-ESO:zs3? http://www.openrailwaymap.org/?lang=de&lat=48.362864571600966&lon... We should keep our tagging system as easy as possible but also as powerful as possible. Sometimes you need tweaks and dirty hacks at OSM. Mapping POIs sometimes as nodes and sometimes as areas is an example. > As signals have positions, meaning a km (example: km 18.543) the tag > railway:signal:position=18.543 > should be used. We already have railway:position:exact=* which can be tagged to every node of a track. Why not use this tag? > The "Standort" should be tagged as > railway:signal:location=left/right/bridge Why do you want to change railway:signal:position=* to railway:signal:location=*? I do not see any benefit. Just every, EVERY data user has to adapt his software, style sheets and config files just because one guy thinks that "location" sounds nicer! > The direction should be tagged as > railway:signal:direction=nominal/reverse > regarding to the OSM way. Why do you want to change railway:signal:position=* to railway:signal:location=*? I do not see any benefits. It just changes the values to words which are used in professional literature. When I read your proposal, some power refinement proposals by user fanfouer are called to my mind. He tries/tried to rename lots of keys and values because the where different to those used in professional literature. I strongly suggest everyone (not only you, Peter) to read a posting of Andy Allan, maintainer of OSM Carto, about changing tags and consequences of tagging changes. https://github.com/gravitystorm/openstreetmap-carto/issues/230#issuecomme... (I fully agree with that posting) Best regards Michael [1] There are some do-not-does for tagging proposals - read tagging discussions at least a few months before you try to invent great changes or lots of new tags – it will benefit YOU - don't try to change existing tagging - use British English at keys and values - no spaces (apart from names and reference numbers) - avoid abbreviations _______________________________________________ Openrailwaymap mailing list Openrailwaymap(a)openrailwaymap.org http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap