Openrailwaymap April 2015

openrailwaymap@openrailwaymap.org

12 participants
12 discussions

Re: [openrailwaymap] Openrailwaymap Digest, Vol 15, Issue 16
by Tracy Kasperczyk 13 Apr '16

13 Apr '16

Hallo Zusammen, wir werden die Tags wieder entfernen. Viele Grüße Tracy Am 24. April 2015 um 12:00 schrieb < openrailwaymap-request(a)openrailwaymap.org>: > Send Openrailwaymap mailing list submissions to > openrailwaymap(a)openrailwaymap.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap > or, via email, send a message with subject or body 'help' to > openrailwaymap-request(a)openrailwaymap.org > > You can reach the person managing the list at > openrailwaymap-owner(a)openrailwaymap.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Openrailwaymap digest..." > > > Today's Topics: > > 1. Re: priority-Tag (danmey(a)web.de) > 2. Re: priority-Tag (Rolf Eike Beer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 23 Apr 2015 23:17:17 +0200 > From: danmey(a)web.de > To: openrailwaymap(a)openrailwaymap.org > Subject: Re: [openrailwaymap] priority-Tag > Message-ID: <5539615D.5040500(a)web.de> > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > Hallo! > Ein altes Thema ein bisschen anders: In Ostwestfalen-Lippe gibt es > reihenweise *nodes* mit priority=primary: http://overpass-turbo.eu/s/82J > Fl?chendeckend an alle nodes von railway=rail. > Kann das weg? Oder steckt Sinn dahinter? > VG, Daniel > > > > > Am 06.11.2014 um 10:00 schrieb Merle Ro?ner: > > > > Hallo, > > > > inzwischen ist wieder einiges bei uns passiert: > > > > Wir werden jetzt die Relationen an den Schienen auswerten und > > dementsprechend nicht mehr den Tag priority setzen. > > > > Viele Gr??e > > > > Merle von MentzDV > > > > > > > > _______________________________________________ > > Openrailwaymap mailing list > > Openrailwaymap(a)openrailwaymap.org > > http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap > >

3 2

Station importance
by Alexander Matheisen 07 Apr '16

07 Apr '16

Hello everybody, for rendering, it would be nice to have any information about the importance of a station/halt. With this information, the renderer could render captions in different zoom levels or font sizes or decide which label is rendered in cases of collision. Currently we have the tag railway:station_category=1-7 for mapping the German railway station category [1]. But this is very german-specific, so we should think about a way to tag the importance of a station using generic rules that are independent from any country-specific categories. Should we use the existing tag railway:station_category=* and translate the German definitions, so that they can be applied internationally? This would have the advantage that German stations, that are already tagged with the existing tag, do not require any retagging. But using just numeric values is not so Or should we create a new tag a tag like railway:station_importance=* with some category values such as local/regional/international/... and leave the existing railway:station_category=* tag for mapping country-specific categories? Any ideas? Regards Alex [1] http://en.wikipedia.org/wiki/German_railway_station_categories

8 21

[CH] Telefonrufsignal / phone call signal
by Michael Reichert 14 Sep '15

14 Sep '15

Hallo, beim Erstellen des Schweizer Taggingschemas habe ich ein paar Signale ausgelassen, an deren Existenz ich Zweifel hatte oder bei denen ich mir mit dem Verständnis schwer tat. Ein solcher Fall war das Telefonrufsignal. Die Fahrdienstvorschrift beschreibt es so: > Obligatorische Verbindungsaufnahme vom Lokführer zum Fahrdienstleiter > bei haltenden Zugfahrten und Rangierbewegungen Auf Drehscheibe-Online habe ich dann nachgefragt und mir wurde mit einem tagesaktuellen Bild bestätigt, dass es dieses Signal noch in Basel Rangierbahnhof gibt. Verwendet wird es aber nicht mehr (zumindest bei der SBB in Basel Rangierbahnhof). http://www.drehscheibe-online.de/foren/read.php?106,7364538 Ich schlage folgendes Tagging vor: railway:signal:phone=CH-FdV:277 railway:signal:phone:form=light railway:signal:phone:states=CH-FdV:277;off Es würde daher also der neue Signaltype "phone" für Signale im Zusammenhang mit der kabelgebundenen Kommunikation geben. Bisher gibt es schon "radio" für Signale des Zugfunks (z.B. Zugfunk-Kanaltafel). Viele Grüße Michael -------------------------------- Hi, at the moment I am finishing a railway signal tagging scheme for Switzerland. [1] There is one signal there which I cannot assign to a existing signal type (e.g. main, distant, speed_limit, radio, …) – the phone call signal (German "Telefonrufsignal"). It flashes if the staff at the signal box wants to call a train driver. He has to leave his locomotive and talk to the signal box staff using the next phone. Although Switzerland has GSM-R (or analogue radio at some lines) and public cell phone networks as an alternative, this signal still exists (e.g. at Basel Yard Station). A Swiss train driver told me that he has not seen it flashing for a long time. http://www.drehscheibe-online.de/foren/read.php?106,7364538,7365464#msg-736… I suggest following tagging: railway:signal:phone=CH-FdV:277 railway:signal:phone:form=light railway:signal:phone:states=CH-FdV:277;off This would introduce the signal type "phone" parallel to the existing "radio". phone should be used for cable-bound communication, radio for GMS-R etc. Best regards Michael [1] English translation will follow soon. It should be an example tagging scheme documented both in German and English. https://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Tagging_in_Switzerland -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists)

2 1

Harzer Schmalspur Bahn
by robert 13 May '15

13 May '15

Dear OpenRailwayMappers, recently I had a look at the marvellous openrailwaymap. I am astonished by the many different classes for railway lines. Although commuting everyday by train, I never imagined so many different track types. One thing confused me, maybe you can enlighten me. Why is the 9701 "Brockenbahn" running to the top of the highest peak in the Harz mountains neither "Schmalspur" nor "Museumsbahn" but a "Überleitgleis". Even more confusing, at some stations the parallel tracks are tagged as "Schmalspurbahn" (e.g. Schierke). According to the website of the "Harzer Schmalspur Bahnen" http://www.hsb-wr.de/mehr-erfahren/streckennetz/interaktives-streckennetz/ the "Brockenbahn" and the "Harzquerbahn" are claimed to be "Schmalspurbahnen". thanks robert

5 7

Mapping/importing milestones
by JJJ Wegdam 28 Apr '15

28 Apr '15

Dear ORM community, the Dutch rail infrastructure provider ProRail has a lot of data available in the public domain, which makes the Dutch situation quite different than the German one (I heard DB-netz is not very willing to share data). To make use of the data I'm working on quite a large import proposal: named the ProRail import. As described at the wiki-link, it will be done in several slices: one per object category (e.g. platforms, signals, turnouts). I will inform this mailing list about each slice, before proposing it to the imports mailing list. The first slice is on milestones. The milestone import already has it's own wiki section within the ProRail import wiki. You can read all import details there. The tagging, however, is very important to ORM. This because the milestone placement in the ProRail database is quite in another way than is described in the ORM tagging scheme. Quote: ''They should be entered as nodes on the tracks themselves. If the railway line has more than one track, it should be entered on each track.'' I personally object to such an approach, because it neither encompasses the theoretical nor practical situation. The theoretical situation is placement of milestones directly on the reference ribbon, along the centre of a railway line. The practical situation, however, is placement of signs perpendicular from the reference ribbon (note that this can create other signs intervals than described on the signs). Railway companies mostly use the reference ribbons in their maps and systems, because those values are more precise. I would propose to make mapping of the theoretical and practical locations of milestones possible, by allowing these systems on the wiki. Importing the Dutch milestones automatically would be impossible without such permission. Your thoughts on the milestone import and milestone locations are highly appreciated. Thank you in advance. Best regards, Jeroen

6 14

Rückblick auf die vergangenen Monate / Looking back at the past months
by Alexander Matheisen 27 Apr '15

27 Apr '15

(English version below) Hallo, auch wenn es in den letzten Monaten keine neuen Blogartikel zu lesen gab, ist die Entwicklung nicht stehen geblieben. Wir freuen uns, mit Eike (Dakon) einen weiteren Entwickler im Team begrüßen zu können. Seit dem FOSSGIS-Hackweekend im Linuxhotel im Januar wurde der Signallayer um weitere deutsche und österreichische Signale ergänzt. Es werden jetzt Kreuztafeln (So 106), Rangierhalttafeln (Ra 10) bzw. Verschubhalttafeln und Wartezeichen (DB Ra 11/11a/11b) bzw. Wartesignale gerendert. Diese drei Signale haben den Vorteil, dass sie in Deutschland und Österreich ähnlich (oder gar gleich aussehen), sodass man dieselben Icons verwenden kann. Bei den deutschen Signalen gab es Zuwachs in Form von Blockkennzeichen (mit Anzeige der Blocknummer), Ks-Signalen mit Zusatzlicht (bei verkürztem Bremswegabstand oder Wiederholern) und Sv-Signalen. In der Ansicht der Höchstgeschwindigkeiten werden stillgelegte und im Bau befindliche Strecken nun ebenfalls angezeigt, zur Unterscheidung von den übrigen Strecken allerdings etwas heller. An Brücken und Tunneln werden statt des mit name=* erfassten Streckennamens bevorzugt die mit bridge:name oder tunnel:name angegebenen Tunnel- oder Brückennamen dargestellt. Bei spurgeführten Verkehrsmitteln wie etwa Schwebebahnen, bei denen es sich nicht um Eisenbahnen handelt, werden Brücken und Tunnel nun nicht mehr dargestellt. Dies hatte in der Vergangenheit zu unerwarteten Kartendarstellungen geführt. Eike hat zwischenzeitlich das Rendering von Stellwerken verbessert und sie in den thematisch passenderen Layer der Signale und Sicherungssysteme verschoben. Stellwerke werden jetzt mit Namen in grün gerendert. Damit auch als Gebäude erfasste Stellwerke angezeigt werden, waren Korrekturen am verwendeten Renderer node-tileserver notwendig. Im Infrastrukturlayer werden nun Drehscheiben und Schiebebühnen angezeigt. Der beste Datensatz nützt aber nichts, wenn die Datenqualität niedrig ist. Um die Qualität zu steigern, haben wir weitere Abfragen in den Validations-Regeln für JOSM ergänzt. Unter anderem wird jetzt geprüft, ob Gleisnummern als solche getaggt sind (und nicht als Namen) und ob das Tagging eines Signals logische Fehler enthält. Ebenfalls werden die Objekte auf diverse veraltete und nicht unterstützte Tags geprüft. Auch in der JOSM-Vorlage gab es einige Änderungen: So wurden Einträge für Zugdeckungssignale und ETCS-Haltetafeln (Ne 14) hinzugefügt und einige neue Icons ergänzt. Die Signale wurden mit dem neuen Länder-Betreiber-Präfix versehen. Außerdem wurden einige Einträge auf neues Tagging umgestellt, das im Rahmen der Treffen in Köln und Bad Nauheim vereinbart wurde. Ebenfalls wurden kleinere Syntaxfehler behoben und die Einträge ins Englische übersetzt. Auf der Webseite selbst gab es ebenfalls kleine Neuerungen: Es ist nun möglich, die Karte auch ohne Hintergrundkarte zu betrachten. Außerdem findet die Suche nun auch (Ausweich-)Anschlussstellen, die mit railway=spur_junction getaggt sind. Daneben ist die Webseite nun auch in Türkisch verfügbar, vielen Dank dafür an Kudret Emre. Noch nicht ganz fertig implementiert sind Icons für Bahnübergänge im Infrastruktur-Stil, die Darstellung von Gleisnummern, Vorsignaltafeln in verkürztem Bremswegabstand, deutschen Zs 3(v)-Lichtsignalen und Fahrleitungssignalen (in Deutschland und Österreich, da die Signale identisch sind). Wir bedanken uns bei der Geofabrik aus Karlsruhe, auf deren OSM-Hackweekend im Februar Alex und Michael einen Teil der oben genannten Funktionen implementiert haben. Neben dem Fertigstellen der noch offenen Änderungen stehen für die nächste Zeit eine Überarbeitung der Legende, Aktualisierungen und Ergänzungen bei den Übersetzungen und eine Neugestaltung der Webseite an. Daneben wird der Signallayer schrittweise um österreichische und niederländische Signale erweitert. Die Suchfunktion soll künftig auch stillgelegte, abgebaute, im Bau befindliche und geplante Betriebsstellen zurückliefern. Touristisch und militärisch genutzte Strecken, die momentan nicht auf der Karte angezeigt werden, sollen in der Kartenansicht berücksichtigt werden. Gruß Alex *** Hi everybody, even if there was no new blog article in the last few months, the development has not stopped. We are happy to welcome Eike (Dakon) as a new developer in our team. Since the FOSSGIS Hack Weekend in January, the signalling layer was extended by several German and Austrian signals. Now it shows distant sign("Kreuztafel"), shunting stop signs ("Rangierhalttafel" / "Verschubhalttafel") and shunting signs ("Wartezeichen" / "Wartesignale"). The advantage of these three signals is that they are almost equal in Germany and Austria, so that we can use the same icons. The German signals were extended by block marker signs ("Blockkennzeichen"), repeated or shortened light signals type Ks and combined signals type Sv. The maxspeed layer now also shows disused and construction tracks, which are rendered in lighter colours to make them distinguishable from active railroads. In infrastructure layer, bridge and tunnel names tagged with bridge:name and tunnel:name are favoured over track names. Bridges and tunnels at tracks such as monorails, which are not traditional railroads, are not rendered any more. In the past this caused unexpected results on the map. In the meantime, Eike improved the rendering of signal boxes and moved them to the more appropriate signalling layer. Signal boxes are now rendered in green with names. Some bugfixes at node-tileserver were necessary to render signal boxes tagged as buildings. The infrastructure layer now also visualizes turntables and traversers. To improve the data quality, more validation rules for JOSM were added. These new rules check e.g. whether track numbers are tagged correctly and not as names or if signals have logical tagging issues. Features are also checked for various deprecated and not supported tags. There were some changes of the JOSM presets, too: Items for platform section signals ("Zugdeckungssignal"), ETCS stop signs (Ne 14) and some new icons were added to the German preset. The signals were retagged with the new country-operator-prefixes. Tagging changes, that were decided at the meetings in Cologne and Bad Nauheim, were applied to some items. There were also some bugfixes of syntax errors and translations to English. There are also some new features on the website: Users can view the railway overlay without any basemap. The search now also finds spur junctions tagged as railway=spur_junction. Kudret Emre added a Turkish translation of the website, thanks a lot! Some new features such as icons for crossings in infrastructure layer, rendering of track numbers, German distant signs with shortened braking distance, German light speed limit signals and catenary signals (in Germany and Austria) are still under construction. We thank Geofabrik from Karlsruhe for hosting the OSM Hack Weekend in February, where Alex and Michael implemented a part of the new features mentioned above. Beside finishing the pending changes, improvements of the legend, updates and additions of the translations and a redesign of the website stand on our todo list. The signalling layer will be continously extended by Austrian and Dutch signals. The search will be improved, so that it returns also disused, abandoned, constructed and proposed stations. Tracks used for tourism or military purposes, which are currently not rendered on the map, will be visualized, too. Regards Alex

1 0

priority-Tag
by Merle Roßner 23 Apr '15

23 Apr '15

Hallo, inzwischen ist wieder einiges bei uns passiert: Wir werden jetzt die Relationen an den Schienen auswerten und dementsprechend nicht mehr den Tag priority setzen. Viele Grüße Merle von MentzDV

3 2

Mapping/importing milestones
by JJJ Wegdam 18 Apr '15

18 Apr '15

Good evening Michael, The advantage is that we have data available for the entire Netherlands until the milestones are mapped at their final location. That looks like an advantage but it is a big disadvantage. It is never a good idea to import data into OSM and let the community fix it. personally, I regard this differently; why would we only accept a final form of data, while we are currently not having any Dutch milestone data at all? To illustrate this: OSM is actually based on importing data which was afterwards improved. As an example: in the Netherlands all meadows and residential areas for example have been imported by AND. These were welcomed as a country-wide basis because there wasn't any data on this subject at all by then. Nowadays, we are still improving and detailling that data through Bing and other sources. Imagine the other method: not accepting any meadow imports for example and ask all mappers to map meadows according to Bing. That would take years, while still having blank spots. A nice example of such a contradiction can be found at the border of the Netherlands with Nordrhein-Westfalen: http://www.openstreetmap.org/#map=11/52.2635/7.1727. Just have a look at all these TIGER data garbage (stevea as railway mapper could teach you a lesson – he is fixing all these data in California). The TIGER import imported road data of a low quality over the whole US. Up to now about 95 % (rough estimation) has not been fixed. The import took place about 6 to 8 years ago! There are several other imports which did the same – their data has not been fixed yet. A nice example of a big bad import indeed. I think it is not justified to compare such a poor and large import with my current proposal though: A few weeks ago, I attended a guest lecture on mapping ProRail's infrastructure. Fugro explained how they did it with a standard deviation of 15 mm's. That very data is the source for my import proposal, which makes my import data somewhat 500 times more precise than the TIGER import data. When comparing with the current OSM data, this means a deviation of max. 2 metres with the current OSM data, which I consider as very acceptable. If you wish, please consider the attached lecture nodes at page 21 and the attached JOSM screenshots (blue dots are ProRail data and grey is OSM rail). TIGER consists of many seperate changesets. When I first attempted the milestone import, it was possible with just one single changeset. This makes it very easy to revert if ever considered necessary. Another safety measure is the tag combination that I'll add to it, which makes it easy to remove parts of the dataset by using XAPI. This enables mappers that are adding more precise data, to remove old data parallel to theirs with some simple mouseclicks. TIGER consists of a heterogeneous network of ways with even some weird drawing styles for seperated lanes. My proposal is very simple and contains just nodes with homogeneous properties (all nodes the same tags). Like described above, the import will not intervene in existing data, because there is literally just two milestones in the entire country (like shown in the attached overpass). Shortly, if you propose an import at Imports list as you are doing here now, your proposal will definitely fail. Since I already tried this before, I am well aware of the standards of the Imports mailing list. Thank you for your concerns though; it's members are (with reason) very strict. 2015-04-14 01:47 JJJ Wegdam wrote: Milestone systems and signal locations are used for many purposes, like defining and finding maintenance or research locations, but also capacity-calculation. Especially the milestones; I simply know that ProRail employees would greatly appreciate a milestone map that works well at their mobile phone. Railmaps does not and ORM does. I promised them to make this work as soon as I could. This is also why I tried the milestone import before. If people are interested in having milestons in OSM why don't you ask them to help them tracing from an WMS layer. Because all interested people that I am aware of are working in the rail sector. Because of competition between the companies, they are all interested in either improving their own services or welcoming open source services made by others. You can set up a WMS service using a database like PostGIS + a server like Mapserver or Geoserver. I will try to set up such a service (it's not much data, i.e. it does not need a powerful server) at my private server but you might have to wait a few days. I'm unaware of what WMS precisely is and how it works, but it sounds nice. I could provide you with the shapefiles and accompanying QGIS renders? Kind regards, Jeroen

1 0

Zehn Abfragen gegen schlechtes Signaltagging / Ten Overpass Queries to search bad signal tagging
by Michael Reichert 16 Apr '15

16 Apr '15

Hallo, da ich bei meinem "mechanischen" (haha [2]) Edit viele Signale sichte, fallen mir Taggingfehler in nennenswerter Zahl auf. Einen Teil kann ich korrigieren, weil die Mapper note=* getaggt haben, einen Teil aber auch nicht. In letzteren Fällen habe ich die Signale oft nicht auf das neue Präfix umgetaggt (damit sie später noch auffallen) und die schuldigen Changesets kommentiert. So wie es unter präfix-losen Signalen Fehler gibt, dürfte es diese Fehler auch bei präfix-habenden Signalen geben. Wer Zeit und Lust hat, kann mal mit der Overpass-API auf Fehlerjagd gehen. Die Abfragen geben XML mit Metadaten aus, d.h. über Export -> JOSM könnt ihr euch die Abfrageergebnisse direkt in JOSM laden. (1) Signalnummern, die als railway:ref=* erfasst sind. Beispiel-Abfrage: http://overpass-turbo.eu/s/8JM (2) Signale, die sowohl mit railway:signal:main!=DE-ESO:hp als auch railway:signal:distant=* getaggt sind. Gegebenenfalls andere Hauptsignal-Vorsignal-Mischungen mit Ks- und Hl-Anteil ausprobieren. http://overpass-turbo.eu/s/8JN (3) Ähnlich (2), aber die Kombination railway:signal:main!=DE-ESO:hp und railway:signal:combined=*. (4) Ähnlich (2), aber die Kombination railway:signal:distant=* und railway:signal:combined=*. (Geht in der Realität einfach nicht, da das Mehrabschnittsignal schon eine Vorsignalfunktion hat) (5) Signalen mit name=* statt ref=*. http://overpass-turbo.eu/s/8JO (6) Weichen mit name=* statt ref=* http://overpass-turbo.eu/s/8JP (7) Signale ohne railway:signal:direction=*. http://overpass-turbo.eu/s/8JR Ich spreche mich dafür aus, diese nicht mehr zu rendern, denn Renderer haben Macht. [1] (8) Signale ohne railway:signal:position=*. http://overpass-turbo.eu/s/8JS (9) Sh 1-Licht als eigenständiges Sh-Signal gemappt. In den Signalschirmen von Hp-, Ks- und Hl-Signalen sind oft Sh 1-Lichter integriert (sodass dann Hp 0 + Sh 1 gezeigt werden kann). Viele dieser Signale wurden jedoch so gemappt, als wären es zwei eigenständige Schirme am gleich Masten (gibt es zwar, aber nur bei Sv-Signalen und sehr alten Hp-Signalschirmen). Falsches Tagging (denkt euch das DE-ESO ggf. einfach weg): railway:signal:main=DE-ESO:hp railway:signal:main:form=light railway:signal:minor=DE-ESO:sh railway:signal:minor:states=DE-ESO:hp0;DE-ESO:sh1 (bis vor Kurzem wurde statt Hp0 noch Sh0 getaggt, was laut Ril 301 aber bei Lichtsignalen falsch ist) railway:signal:minor:form=light Richtiges Tagging: railway:signal:main=DE-ESO:hp railway:signal:main:form=light railway:signal:minor=DE-ESO:sh1 railway:signal:minor:form=light Man kann bei Hp-Signalen aus der Ferne eigentlich schlecht diesen Fehler korrigieren. Es bedarf Ortskenntnis. Beim Rest (Hl, Ks) kann man das eigentlich aus der Ferne tun, sollte jedoch sehr vorsichtig sein und ggf. den Mapper kontaktieren. (10) Ein weiteres Problem, das mir aufgefallen ist, sind Verwechslungen zwischen Signaltypen. Besonders gerne: (a) Ks-Haupt- und Ks-Mehrabschnittsignale werden als Hp-Lichtsignale erfasst. Man erkennt auch ohne Ortskenntnis potentielle Fälle an Signalnummern, die nach folgenden Schema aufgebaut sind. Sie enthalten meistens einen Nummer am Anfang, die im gesamten Bahnhof gleich ist. Einfahrsignale: 53A, 53AA, 53B, 53BB, 53F, 53FF, 53G, 53GG (Doppelbuchstaben immer im Gegengleis) Ausfahrsignale: 53N1, 53N2, …, 53P1, 53P2, … (nach N/P steht die Gleisnummer, gerne auch zwei- oder dreistellig; in einigen Stationen wird neben N und P auch noch zusätzlich O oder M verwendet, z.B. Krefeld Hbf) Zwischensignale: 53ZU1, 53ZU2, … (markant ist das Z, davor die Bahnhofsnummer, dahinter ein Buchstabe für den Bereich im Bahnhof, gefolgt von der Gleisnummer) Regex für Ks-Signalnummern: [0-9]+(([M-Q]{1}|Z[R-V]{1})[0-9]+|[A-K]{1,2}) Diese Regex matcht nicht in Potsdam Hbf! Wenn also ein Bahnhof vor dem A, B, N, P, Z* usw. eine Nummer hat, sollte man Googlen, ob dort in den vergangenen Jahren ein ESTW errichtet wurde. Es gibt auch bei H/V-Signalisierung Bahnhöfe mit Nummern vor den Buchstaben, diese Bahnhöfe sind dann ferngesteuert, z.B. Karlsruhe–Graben-Neudorf oder z.B. Mühlhausen (Wern). (b) Ks-Mehrabschnittsignale werden als Ks-Hauptsignale erfasst. Das erkennt man nicht aus der Ferne, wenn nur wenige Signale erfasst sind. Statistisch dürfen Einfahr- und Zwischensignale meist Mehrabschnittsignale sein, Ausfahrsignale und Blocksignale sind nur Mehrabschnittsignale, wenn die Blockabstände kurz sind oder der nächste Abzweig/Bahnhof weniger als Vorsignalabstand + Durchrutschweg + ein Bisschen entfernt ist. Viele dieser Fehler (ausgenommen Abfrage 6, 9 und 10) stammen von iD-Usern. Siehe auch https://github.com/rurseekatze/OpenRailwayMap/issues/192 Viele Grüße Michael PS Die OpenRailwayMap-Vorlagen sind mittlerweile in den Vorlagenverzeichnissen der JOSM-Entwickler gelistet. [1] Nicht umsonst spricht man von "Mappen für den Renderer". [2] Da ich sehr viele Signale sichte und viele Fehler finde, fühlt sich das alles andere als mechanisch an. ------------------- Hi, I have found lots of tagging errors during my mechanical edit which adds the prefix "DE-ESO:*" to a lot of German signals. Following eight queries might dig out errors in your area: (1) Signal numbers tagged as railway:ref=* instead of ref=* http://overpass-turbo.eu/s/8JM (2) *Germany only* Signals tagged both railway:signal:main!=DE-ESO:hp and railway:signal:distant=*. You might try other combinations with Hl and Ks signals. http://overpass-turbo.eu/s/8JN (3) *Germany only* SSimilar to (2), but the combination of railway:signal:main!=DE-ESO:hp und railway:signal:combined=*. (4) *Germany only* SSimilar to (2), but the combination of railway:signal:distant=* und railway:signal:combined=*. (It's impossible in reality that a combined signal shares a its pole with a distant signal because the combined signal is already a distant signal.) (5) Signals tagged name=* instead of ref=*. http://overpass-turbo.eu/s/8JO (6) Switches tagged name=* instead of ref=*. http://overpass-turbo.eu/s/8JP (7) Signals without railway:signal:direction=*. http://overpass-turbo.eu/s/8JR I support not to render signals without railway:signal:direction=* (they are rendered at the moment) because people often only map things which are rendered. (8) Signals without railway:signal:position=*. http://overpass-turbo.eu/s/8JS (9) *Germany only* If a Hp, Ks or Hl light signal can show Sh 1 the following is the right tagging: railway:signal:main=DE-ESO:hp railway:signal:main:form=light railway:signal:minor=DE-ESO:sh1 railway:signal:minor:form=light The wrong tagging: railway:signal:main=DE-ESO:hp railway:signal:main:form=light railway:signal:minor=DE-ESO:sh railway:signal:minor:states=DE-ESO:hp0;DE-ESO:sh1 (bis vor Kurzem wurde statt Hp0 noch Sh0 getaggt, was laut Ril 301 aber bei Lichtsignalen falsch ist) railway:signal:minor:form=light The "wrong" tagging should only be used if the minor signal is a separate signal which is mounted below the main/combined signal at the same pole. (10) *Germany only* Some Mappers mix up Hp light signals with Ks light singals and Hl light signals with Ks light signals. You cannot correct the tagging without local knowledge but you can create a "review list" because Ks signals inside stations have different numbering system than Hp and Hl signals. Inside stations Ks signals have a number which follows the following regex: [0-9]+(([M-Q]{1}|Z[R-V]{1})[0-9]+|[A-K]{1,2}) Most of these errors are done by iD users (except no. 6, 9 and 10). See also https://github.com/rurseekatze/OpenRailwayMap/issues/192 Best regards Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists)

1 0

Mechanischer Edit an Eisenbahnsignalen in Deutschland / Mechanical Railway Signal Edit in Germany
by Michael Reichert 11 Apr '15

11 Apr '15

Hallo, ich beabsichtige zur flächendeckenden Einführung des neuen DE-ESO:*-Präfixes einen mechanischen Edit durchzuführen, der die alten Signale um das Präfix ergänzt. Weitere Details findet ihr im OSM-Forum. http://forum.openstreetmap.org/viewtopic.php?id=30676 Wenn ihr in JOSM für die Objektvorlage die URL (also http://www.openrailwaymap.org/josm-presets/…) eingetragen habt, dann solltet ihr schon eine Version der Objektvorlagen verwenden, die die Präfixe nutzt. Andernfalls möchte ich euch bitte, eure Objektvorlage zu aktualisieren. Viele Grüße Michael Hi, I am going to run a mechanical edit on railway signals in Germany. I want to add the DE-ESO:* prefix to all signals which do not have it but should have it. More information (in German) can be found at http://forum.openstreetmap.org/viewtopic.php?id=30676 Best regards Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists)

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

Openrailwaymap April 2015