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

Op 28 jul. 2015 om 23:00 heeft Christian Wendel <mail(a)christianwendel.de&gt; het volgende geschreven: Hi Peter, Michael, these are a lot of proposals. Mostly, I am not convinced of their advantage. (Think of me as a heavy Joe Average-Mapper) But the point to merge combined with main signal types could work. Why? In fact, any combined signal can be tagged as a main signal also showing Ks2. But tagging would be lots easier as described. It's lot of work to change signals from "main" to "combined", if the distant state had missed. I hate this kind of work. On the other hand, there a lots of more annoying definitions in OSM tagging. The current railway tagging works well in most of the cases, even if many functions are combined on one signal. Christian PS: I try to be polite even when opposing proposals. > Am 28.07.2015 um 20:52 schrieb Michael Reichert: > 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 _______________________________________________ Openrailwaymap mailing list Openrailwaymap(a)openrailwaymap.org http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap