This mailing list has been migrated to Mailman 3. This archive will no longer be updated. Messages after 1 February 2020 are missing. Please use the new archive instead.
Diese Mailingliste wurde auf Mailman 3 umgestellt. Dieses Archiv wird nicht mehr länger aktualisiert. Nachrichten nach dem 1. Februar 2020 fehlen. Bitte benutze das neue Archiv.
Hello Peter and others, thank you for your proposal. Despite that I welcome new ideas, I cannot judge yours. The Dutch situation simply does not have abbreviations like Hp0. In the case you are interested in the Dutch signals, here's a summary. If described with the direction of driving, our signals behave like: green, yellow, red, train, green, etc. All signals are able to display all three colours and main/distant signals are not distinguished. Most of the signals are working purely on train detection, but some signals can be kept red or yellow by the 13 so called traffic control command centres. Kind regards, Jeroen > Op 28 jul. 2015 om 23:00 heeft Christian Wendel <mail at christianwendel.de> 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=10.991992950439453&zoom=12&style=standard >> >> 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#issuecomment-29238913 >> (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 at openrailwaymap.org >> http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap > > _______________________________________________ > Openrailwaymap mailing list > Openrailwaymap at openrailwaymap.org > http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap