Openrailwaymap

openrailwaymap@openrailwaymap.org

1 participants
307 discussions

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

Schweizer Tagging, neue Keys notwendig (Teil 1)
by Michael Reichert 07 Apr '15

07 Apr '15

Hallo, ich habe ein Taggingschema für schweizer Signale weitestgehend fertiggestellt. https://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Tagging_in_Switzerland Als Präfix habe ich mich für CH-FdV:* entschieden. Signale, die nicht in der Fahrdienstvorschrift erwähnt werden, sondern z.B. nur bei der SBB, BLS und SOB eingesetzt werden (die drei haben gemeinsame Ausführungsbestimmungen zu den Fahrdienstvorschriften) werden mit CH-SBB:* getaggt. Es ist noch nicht ganz fertig, einige Signale fehlen noch, da ich mir bei denen kein Tagging einfiel. Bei anderen Signalen habe ich nicht verstanden, wozu die da sind, da werdet ihr wohl noch in den Eisenbahnforen entsprechende Threads finden. Meine Quellen waren: FdV: http://www.bav.admin.ch/grundlagen/03514/03533/03649/index.html?lang=de&dow… AB FdV Infrastruktur der SBB, BLS und SOB: http://www.sbb.ch/content/dam/sbb/de/pdf/sbb-konzern/sbb-als-geschaeftspart… *Bahnhofsanfangtafel und Bahnhofendtafel* http://xover.mud.at/~invisible/mirror/sig/asr/desigchvers1.html#sig:ch:bahn… Die Bahnhofanfangstafel hängt am Einfahrsignal, die Bahnhofendetafel auf dessen Rückseite und trägt ein Bahnhofskürzel. Sie dient der Orientierung. Da es bei der DB kein Äquivalent dazu gibt, haben wir noch keinen Key für solche Orientierungstafeln. Ich schlage vor, dass wir railway:signal:station_entry=CH-FdV:267 für die Bahnhofanfangtafel railway:signal:station_exit=CH-FdV:268 für die Bahnhofsendetafel Beschriftung als railway:signal:station_entry:caption=* bzw. railway:signal:station_exit:caption=* *Neigungsanzeiger* In der Schweiz gibt es Neigungsanzeiger (zumindest habe ich die auch auf Hauptstrecken [1] vor etwa sechs Jahren, als ich in der Schweiz war noch gesehen). Sie geben bei Neigungsänderungen die neue Neigung und die Länge des folgenden Abschnitts an. http://xover.mud.at/~invisible/mirror/sig/asr/desigchvers1.html#sig:ch:neig… Mein Vorschlag: railway:signal:incline=CH-FdV:269 bei Steigungsanfang Tag|railway:signal:incline=CH-FdV:270 bei Gefälleanfang railway:signal:incline=CH-FdV:271 bei Beginn der Horizontalen railway:signal:train_protection:form=sign railway:signal:incline:lengt=<Länge des geneigten Abschnitts in Meter> railway:signal:incline:incline=<Neigung des geneigten Abschnitts in Promille>, z.B. railway:signal:incline:incline=10 ‰ für den Beginn einer 10-Promille-Steigung oder railway:signal:incline:incline=-35 ‰ für den Beginn eines 35-Promille steilen Gefälles railway:signal:incline:incline=0, wenn es sich um Signal Nr. 271 handelt *Straßenbahnbetrieb* In den FdV gibt es Signale, wenn ein Zug in den Strassenbahnbereich fährt oder ihn verlässt. Wir haben dafür keine Tags. An den Systemwechsel BOStrab/ESBO bei RNV (Mannheim–Weinheim–Heidelberg und Ludwigshafen–Bad Dürkheim) und AVG (Heilbronn, Karlsruhe, Wörth, Bad Wildbad) gibt es noch keine Tags dafür. Mein Vorschlag: railway:signal:workrules_change_distant=CH-FdV:216.1 (Vorsignal für Strassenbahnbereich) railway:signal:workrules_change=CH-FdV:216 (Anfangssignal für Strassenbahnbereich) railway:signal:workrules_change=CH-FdV:216.2 (Endsignal für Strassenbahnbereich) railway:signal:workrules_change:form=sign *Lokwechselsprechstellen* sind Fernsprecher, die man vom Führerstand einer Lok aus erreichen kann, ohne absteigen zu müssen. Sie werden im Rangierdienst eingesetzt. Es wird zwischen Lokwechselsprechstellen unterschieden, die obligatorisch benutzt werden müssen und solchen, deren Benutzung optional ist. railway=phone allein finde ich etwas mager. *Straßenbahnsignale* Für die Straßenbahnfahrsignale würde ich gerne die Hauptsignalfunktion railway:signal:main:function=tram_crossing einführen. Weitere Taggingfragen folgen in einer zweiten Mail. Viele Grüße Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists)

2 4

Tagging "errors" at California/Railroads at OSM wiki
by Michael Reichert 01 Apr '15

01 Apr '15

Hi Steve, I have read the wiki page https://wiki.openstreetmap.org/wiki/California/Railroads and found some tagging issues. *railway=abandoned/disused/razed* Could you please add abandoned:railway=rail/light_rail/tram/narrow_gauge/…, disused:railway=rail/light_rail/tram/narrow_gauge/… and razed:railway=rail/light_rail/tram/narrow_gauge/…. We as OpenRailwayMap developers plan to support abandoned:railway=*, disused:railway=* and razed:railway=* in near future because a simple railway=disused does not tell the data user if it was a normal railroad or a tram or a monorail. That's why we suggest to tag both railway=disused/abandoned/razed AND disused/abandoned/razed:railway=rail/tram/narrow_gauge/… *usage=freight* It is right that usage=freight is deprecated. But changing all usage=freight to usage=industrial is wrong. usage=freight is the old tag for railway:traffic_mode=freight. There are lots of not-industrial railway lines which are only used by freight trains. usage=industrial is intended as a seperate railway line which is used inside a large factory. For example, the tracks at BASF works in Ludwigshafen are tagged usage=industrial. The same applies for the railway lines (they are no public railway lines, called Nord-Süd-Bahn and Hambachtalbahn) between brown coal mines and the power plants west of Cologne. http://www.openrailwaymap.org/?lang=de&lat=49.50955024276502&lon=8.45938682… http://www.openrailwaymap.org/?lang=de&lat=51.001522273512734&lon=6.6595602… *service=spur* service=spur is intended to be used on tracks from a station to a neighbouring company. Usually these tracks are no independent railway lines and shorter than a mile. http://www.openrailwaymap.org/?lang=de&lat=51.8868887265603&lon=12.22359895… *light rail, tram and subway* There are no hard criteria to differentiate between light rails, trams and subways. We developed a criteria catalogue which should support tagging decisions at Bad Nauheim Meeting in October 2014. https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Aktiventreffen_2014_2#li… Did you understand the ORM tagging page at OSM wiki the wrong way (i.e. we should improve this page)? 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

Baustellen / construction works
by Michael Reichert 29 Mar '15

29 Mar '15

Hallo, heute bin ich zwischen Dresden und Berlin über zwei Fälle von übertriebenem Baustellenmapping gestoßen. In Rangsdorf wird derzeit der Bahnhof grundlegend umgebaut. Einer von uns Eisenbahnmappern hat den Bahnhof im Februar 2014 auf den aktuellen Stand gebracht [2], mittlerweile ist dort aber alles wieder ganz anders. Züge verkehren nicht mehr über die Westseite, sondern über die Ostseite. http://www.openrailwaymap.org/?lang=de&lat=52.294838871126345&lon=13.434165… Alter Bauzustand: http://www.drehscheibe-online.de/foren/read.php?4,6523067 Neuer Bauzustand: http://www.drehscheibe-online.de/foren/read.php?3,7335849,7338342#msg-73383… Ein weiteres Beispiel ist die Sperrung des Richtungsgleises Dresden -> Berlin zwischen Elsterwerda und Hohenleipisch. Dieses soll dem note-Tag zufolge im Januar 2014 gesperrt gewesen sein, worauf der Mapper es in railway=disused umgetaggt hat. Mittlerweile wird es wieder befahren, andernfalls wäre dieses Bild wohl nicht so entstanden: http://www.mapillary.com/map/im/4pMS1HbskyzGOdyGLE6QHw Mein Bitte daher an alle Mapper: Bitte mappt baubedingte Änderungen nur, wenn ihr die Strecke im Auge behalten könnt (d.h. regelmäßig die Strecke befahrt). Es sollte auf der Schiene diesselben Grundsätze wie beim Mappen von Straßenbaustellen gelten. Ich persönlich habe für mich entschieden, keine Geschwindigkeitsbeschränkungen zu mappen, die durch Lf 1, Lf 2 und Lf 3 angeordnet werden, zu erfassen. Sie sind meist temporärer Natur. Ich mappe sie nur, wenn ich relativ sicher weiß, dass mit einer Besserung (Aufhebung der Langsamfahrstelle) nicht zu rechnen und von einem Ersetzen dieser Schilder durch Lf 6/Lf 7 zu rechnen ist. Ich weiß, die Strecke Berlin–Dresden ist ein Fall für sich, denn dort stehen in den kommenden zwei Jahren noch umfangreiche Bauarbeiten ins Haus (u.a. eine 18-monatige Vollsperrung für den Ausbau auf 200 km/h, bei der anscheinend kein Schotterstein auf dem anderen bleibt). [1] Der Verursacher dürfte sich hoffentlich angesprochen fühlen. :-) Viele Grüße Michael [1] 18 Monate rechtfertigen ein railway=construction + construction=rail. [2] Bei den Routenrelationen stehen noch einige Nacharbeiten an, die ich noch im Rahmen der Umstellung des RE 7 Wünstorf-Waldstadt–Berlin–Dessau [3] auf PTv2 erledigen werde. [3] Diese Linie hat zwischen Wünstorf-Waldstadt und Zossen bis Dezember SEV, weshalb ich sie auf den Abschnitt Zossen–Dessau einkürzen werden. Neun Monate sind lang genug. -------------------------------------------------------------- *English summary* Hi, The email above is a complaint about a mapper (he is the only one I discovered) who mapps construction works on railway lines. Just because he sees construction works on a track while passing them by train, he changes the affected track from railway=rail to railway=construction/disused. But he did not update the data later. I think that we should use the same guideline as road mappers do: Only map construction works using tags like railway=construction if the construction works require a couple of months (at least 6). We should also not map speed limits which are caused by short construction works. I myself only map construction works along railway lines if I regularly use this railway line and can ensure updates. 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)

2 1

Thoughts about importing a whole country's (NL) railway data
by Michael Reichert 29 Mar '15

29 Mar '15

*TL;DR* I myself (one of the OpenRailwayMap developers) absolutely oppose a proposed railway import in the Netherlands. Dear Jeroen, dear readers of Imports and OpenRailwayMap mailing list, I have heard and read that you tried to import railway data in the Netherlands. I myself (one of the developers of OpenRailwayMap) am against importing railway data. OpenStreetMap is not a 0-Euro data center for geodata. OSM is a project where /people/ collect data and care for it. Because the Netherlands already have mapped railway lines, you have to preserve the objects' history if you import railway data. This makes an mechanical import is nearly impossible. That's why I suggest you to do it differently. Set up a WMS or TMS offering some of the data. The WMS/TMS can be used at JOSM. The mappers can use this service if they improve a railway line or station. They correct/improve existing data and preserve the objects' history. We have several of these "WMS imports" in Germany and Austria. Usually a state surveying authority allowed us to use their WMS service to derive data. Some examples are City of Berlin, City of Hamburg, State of North Rhine-Westphalia or basemap.at in Austria. Mappers usually derive geometry of objects from these services while adding additional data which they surveyed in field. This type of import would be much slower but better in the long term. People only start mapping if they see a (nearly) blank map or missing data. This effect has worked perfectly in Russia (where there seems supposedly be no better map) and Germany. At the moment German railway mappers experience the same effect at detailed railway mapping (speed limits, signals, milestones, …). Deutsche Bahn (Germany's national railway company) refuse to publish any piece of data. I have found some newbies, who started mapping a few months ago and did railway edits from day 1, for the last months while mapping railway stuff. This happens if people miss data. If you import all data, you won't get such a large community. People only care for the data they mapped themself ("their own things"). They will keep these data up-to-data. If you imported these data, they cannot/won't do it because they did not map it and did not join OSM. Railway infrastructure is changing day by day (like highway infrastructure does this, too). You need a large number of mappers if your data shall be up-to-data. My suggestion: Set up an WMS service which offers a rendering of all tracks and milestones of ProRail (maybe different colours for different track types). You should think about a tagging scheme before starting signal mapping in the Netherlands. Every country has a different railway signalling system. Best regards Michael (Nakaner) PS Sorry for starting a new thread. I joined the list after the initial discussion about this import. -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists)

3 2

← Newer
1
...
20
21
22
23
24
25
26
...
31
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

Openrailwaymap