Die Deutsche Bahn macht Open-Data – Noch vor kurzer Zeit hätten das viele als Aprilscherz aufgefasst. Doch es hat sich etwas getan: Die Deutsche Bahn wird demnächst ein Open-Data-Portal starten.

Um eines vorweg klarzustellen: Wer jetzt eine große Anzahl veröffentlichter Datensätze erwartet hat, der wird enttäuscht sein. Es sollte aber bedacht werden, dass ein großer Konzern nicht von heute auf morgen den Hebel von "strenggeheim" auf "frei und offen" umlegen kann. Die DB muss erst selbst Erfahrungen mit offenen Daten machen, sowohl hinsichtlich technischer als auch lizenzrechtlicher Aspekte. Für den Anfang wird die DB kleine Häppchen veröffentlichen – die Liste der Betriebsstellen mit den Kürzeln nach Ril 100 sowie Informationen zu Aufzügen. Glücklicherweise wählt die DB dafür eine relativ offene und gebräuchliche Lizenz, die CC-BY.

Dieser Schritt wird im Blogpost der OKFN wie folgt kommentiert: "Vorbei scheinen die Zeiten, in denen die Community nur über geschickte Hacks oder eigene Erfassung an Daten des größten deutschen Eisenbahnunternehmens kam und dabei auch noch Abmahnungen riskierte, wie vor drei Jahren bei OpenPlanB". Dazu möchten wir anmerken, dass die Reaktion der DB auf die eigenmächtige Verbreitung von Fahrplandaten der Hafas-CD im JSON-Format im Jahr 2012 durch OpenPlanB relativ milde ausfiel. Dass die DB sich seither bezüglich Open-Data zurückgehalten hat, verwundert nach dieser Aktion nicht. Die Veröffentlichung der Konvertierungs-Software allein (was OpenPlanB auch getan hat), wäre nicht so eindrucksvoll, aber legal gewesen.

Als OpenStreetMap-Aktive verfolgen wir einen anderen, legalen Ansatz, um Behörden und Unternehmen in Richtung Open-Data zu lenken – das Crowdsouring. Wir wollen im Bahnbereich noch einmal erreichen, was OSM schon für Geobasisdaten erreicht hat. Dort haben ursprüngliche Monopolisten/Oligopolisten, nämlich Vermessungsämter, Here, TomTom & Co. nicht mehr die alleinige Hoheit über die Geodaten. Die Open-Data-Skepsis und überteuerte Gebühren der Vermessungsverwaltungen und ihrer Aufsichtsbehörden haben uns in Deutschland sogar geholfen. Man wollte und will die Einnahmen nicht aufgeben und hat die preis- und qualitätsbewussten Nutzer der OSM-Community überlassen. Die anfangs weiße OSM-Landkarte hat die Mapper förmlich angezogen und heute haben oft die Staaten, die in Sachen Open-Data nicht so fortschrittlich waren/sind, die aktiveren und größeren Communitys.

Dasselbe geschieht in Deutschland gerade im Bahnbereich noch einmal. Da sich die DB bei Open-Data bislang zurückgehalten hat, haben eine Handvoll Freiwillige vor drei Jahren begonnen, selbst die deutsche Eisenbahninfrastruktur noch einmal neu zu erfassen.

Ein Interesse an diesen Daten besteht auch. Wenn man die Aufrufe der OpenRailwayMap seit Januar 2015 nach Providern sortiert, aus deren Netzen sie stammen, nimmt der DB-Konzern mit etwa 10% der Aufrufe den fünften Platz ein, vor ihm liegen nur Telekom-, Vodafone, Kabel-Deutschland- und Telefonica-Kunden. Gespräche mit DB-Mitarbeitern bestätigen das. In manchen Abteilungen scheint die Nutzung der OpenRailwayMap stark verbreitet zu sein. Sie bietet mit einer Kartendarstellung, die die DB ihren Mitarbeitern nicht anbietet, einen Überblick. Dazu kommt noch die gegenüber manchen DB-eigenen Geodatenanwendungen deutlich modernere Benutzeroberfläche (dort sehen die GUIs teilweise noch wie vor zehn bis fünfzehn Jahren aus).

Nachdem in den vergangenen Jahren unsere Anfragen bezüglich einer Datenfreigabe bzw. Datennutzungserlaubnis von der DB ablehnend oder gar nicht beantwortet wurden, freut es uns um so mehr, dass die DB mittlerweile auf die OpenRailwayMap-Community zugeht und nach Möglichkeiten einer Kooperation sucht.

Wir freuen uns über das Open-Data-Angebot der DB, aber überflüssig wird die Erfassung von Eisenbahndetails in OpenStreetMap damit nicht. Erstens hat die DB bis jetzt nur einen kleinen Datensatz angekündigt, zweitens kann die DB mit ihrem Open-Data-Portal nicht das leisten, was ein großes Crowdsourcing-Projekt wie OpenStreetMap – einen einzigen Datensatz, der alles enthält. Nicht nur Bahndetails, sondern auch Straßen, Points of Interest usw. Damit wird Datennutzern das aufwendige Mergen von Datensätzen erspart und sie haben nur noch einen Datenlieferant und nur noch eine Lizenz, die beachtet werden muss.

Open-Data nützt nicht nur der Allgemeinheit, sondern vor allem dem DB-Konzern selbst. Ohne eigenen Nutzen wäre die freiwillige Veröffentlichung von Daten nämlich kaufmännisch nicht zu vertreten. Bei der DB ist es derzeit üblich, dass die eine Konzerntochter der anderen Gebühren für die Nutzung von Geodaten zahlt – oder gleich OSM verwendet, weil das die unbürokratischere Lösung darstellt. Mit Open-Data wird die Datennutzung innerhalb des Konzerns vereinfacht und der Kreativität sind weniger Schranken gesetzt.

Wer also mehr offene Daten schaffen will, sollte nicht nur Forderungen stellen, sondern selbst aktiv werden und mit einem eigenen Crowdsourcing-Projekt die Daten erfassen. Statt um Datensätze zur Pünktlichkeit und offiziellen Zugriff auf Zugradar und RIS (Reisenden-Informationssystem) zu bitten, könnte man z.B. auch per Crowdsourcing die aktuellen Standorte von Zügen erfassen. Die resultierenden Daten wären dann unabhängig und frei. Bekannte technische Unzulänglichkeiten der DB-Systeme könnte man damit auch umgehen. Und wenn dann nach einiger Zeit eine brauchbare Datenbasis zusammengekommen ist (man wird nicht alle Züge damit erfassen können, da in Deutschland manche Züge auch fast leer durch die Gegend fahren), kommen die Anwendungen und die Aufmerksamkeit aus Fachkreisen (Bahnfans, Bahnangestellte usw.) wahrscheinlich von alleine. Mit eigenen Daten schafft man Unabhängigkeit. Wer keine hat, macht sich von Unternehmen und Behörden abhängig.

An einer Stelle müssen wir das Posting von Stefan Kaufmann und Walter Palmetshofer korrigieren. In ihrem Blogpost schreiben sie, dass "die Zeiten […] der eigene Erfassung" vorbei seien. Das ist unabhängig vom Umfang des Open-Data-Angebot der DB leider nicht korrekt. Die DB ist schließlich zwar der bedeutenste Infrastrukturbetreiber in Deutschland, jedoch nicht der einzige. Neben der DB gibt es noch eine Reihe nicht-bundeseigener Eisenbahn-Infrastrukturunternehmen, die heutzutage ca. 18 % des deutschen Eisenbahnnetzes betreiben. Ohne Wertung seien hier Regiobahn, AVG, SWEG und DRE genannt. Von den Daten ausländischer Bahnen ganz zu schweigen. Doch selbst wenn sämtliche Bahnunternehmen Daten freigeben würden, wäre die OpenRailwayMap bzw. die Erfassung von Eisenbahndaten in OpenStreetMap keineswegs überflüssig. OpenStreetMap bzw. OpenRailwayMap übernehmen die Funktion einer Datenbank, in der Daten aus verschiedenen Quellen gesammelt, in einem einheitlichen Format vorgehalten werden und durch Freiwillige gepflegt und angereichert werden. Unser Anspruch ist es, eine eigene Datenbasis zu schaffen. Das OpenStreetMap-Projekt hat schließlich bewiesen, dass eine eigene Datenbasis detaillierter und aktueller sein kann als jegliche existierende Quellen.

Auch dieses Jahr bietet die Deutsche Bahn wieder den Deutschlandpass an. Da Alexander (rurseekatze) und Michael (Nakaner) diesen Sommer die Zeit dazu haben, werden sie etwa ein bis zwei Wochen lang Ostdeutschland bereisen, um Eisenbahninfrastruktur zu mappen. Unsere Ziele: Bahnhöfen und Streckenabschnitte, wo

• seit 2012 ein ESTW (elektronisches Stellwerk mit neuen Signalen) in Betrieb ging
• seit 2012 größere Um-/Ausbauten stattfanden
• in den nächsten zwei Jahren ein ESTW in Betrieb gehen wird oder ein Umbau ansteht.

Auf der französischen uMap-Instanz haben wir eine Karte mit den Zielen und den Gründen veröffentlicht.

Das Jahr 2012 ist als Grenze festgelegt, da die meisten Bing-Luftbilder in diesem Jahr oder später aufgenommen worden sind. Die Bing-Luftbilder eignen sich zum Mappen der Gleisanlagen. Derzeit läuft noch eine Zielsuche im Eisenbahnforum Drehscheibe-Online.

Die Reise wird zwischen dem 14. und 31. August stattfinden. Der genaue Zeitraum und Reiseweg ist noch nicht festgelegt.

Wenn neben dem Umbaumapping noch Zeit bleibt, möchten wir von diversen Nebenbahnen in der Gegend Signale und Höchstgeschwindigkeiten mappen (das wäre dann eine Neuerfassung und keine Aktualisierung).

Da wir wahrscheinlich nicht dazukommen werden, alles selbst in OSM einzutragen, werden wir die Videos (ggf. ohne Ton), Fotos, Notizen, GPS-Tracks und Wegpunkte veröffentlichen.

Da das Budget begrenzt ist, sind wir als Studenten auf Übernachtungsangeboten bei Privatleuten angewiesen, die uns (wir bringen Schlafsäcke + Isomatten mit) eine Nacht lang beherbergen möchten. Da wir während der Reise keine festen Termine haben, sind wir über jedes Angebot froh und werde die Reise anhand der angebotenen Übernachtungsmöglichkeiten ausrichten. Wir sind auch an Übernachtungsangeboten interessiert, die nicht direkt in der Nähe unserer Ziele liegen. Ein bis zwei Stunden Anreise von der Übernachtung zum Mappingort sind kein Problem, schließlich haben wir den Deutschlandpass und können so oft IC/EC/ICE fahren, wie wir wollen.

Im Voraus vielen Dank für alle Übernachtungsangebote.

Die Nutzung der OpenRailwayMap auf mobilen Geräten ist jetzt noch komfortabler: Die für iOS und Android erhältliche App OsmAnd bietet nun eine integrierte Unterstützung für die OpenRailwayMap. Mit nur wenigen Handgriffen lassen sich die verschiedenen Layer der OpenRailwayMap als Overlays hinzufügen. Eine Anleitung im OSM Wiki erklärt, wie das geht.

Damit können nun Funktionen genutzt werden, die die mobile Webseite nicht bieten kann: Unter anderem das beliebige Ausrichten der Karte etwa in Fahrtrichtung oder die Anzeige der eigenen Position. Besonders interessant ist auch die beliebige Kombination mit weiteren Hintergrundkarten wie zum Beispiel Luftbildern. Eine Einschränkung gibt es allerdings: Die Overlays werden dynamisch geladen, was eine Internetverbindung voraussetzt. Eine Möglichkeit zur Offline-Nutzung wäre also wünschenswert, ist momentan allerdings noch nicht realisiert. Dies hat folgende Gründe:

Die Erzeugung von fertig herunterladbaren Offline-Karten benötigt weitere Serverressourcen und Bandbreite, die zur Zeit nicht zur Verfügung stehen. Daran wird sich auf absehbare Zeit erstmal nichts ändern, allerdings bietet das offene Datenmodell von OpenStreetMap die Möglichkeit, selbst Offlinekarten zu erzeugen. Die dazu notwendigen Schritte sind im OSM-Wiki dokumentiert.

Derzeit besteht allerdings das Problem, dass ein entsprechender OpenRailwayMap-Kartenstil fehlt, um die Karte im gleichen Stil wie die OpenRailwayMap darzustellen. Leider müssen diese Kartenstile eigens für OsmAnd geschrieben werden, da die im MapCSS-Format existierenden Kartenstile der OpenRailwayMap nicht unterstützt werden. Das bedeutet eine Menge Arbeit, vor allem aber erfordert auch die kontinuierliche Synchronisation mit den MapCSS-Stylesheets einigen Arbeitsaufwand. Eine Alternative wäre die Entwicklung eines Tools, das die MapCSS-Styles in das OsmAnd-Format umwandeln kann. Das würde sehr viel manuelle Arbeit ersparen und auch sicherstellen, dass die Online- und Offline-Karten möglichst gleich aussehen. Für beide Aufgaben sind Unterstützer, denen die OpenRailwayMap auf Mobilgeräten besonders am Herzen liegt, gerne gesehen.

Am 20. und 21. März fand in Frankfurt der erste Hackathon unter dem Namen "DB Open Data-Train Challenge" statt, am 8. und 9. Mai soll in Berlin mit der DB Infrastructure Challenge der zweite Hackathon, diesmal mit dem Fokus auf Infrastruktur stattfinden.

Wer an diesen Veranstaltungen teilnimmt, bekommt einen kleinen Datensatz (historische Daten) zur Verfügung gestellt, die Formatdokumentation gibt es schon ein paar Tage vorher. Soweit nicht ungewöhnlich, interessant wird es allerdings bei den Teilnahmebedingungen: Teilnehmer des Hackathons dürfen die Daten nach der Veranstaltung nicht weiterverwenden, sprich er oder sie hackt für die Katz. Da die Anwendungen meist auf den Datensatz zugeschnitten sind, sind sie nach dem Hackathon somit weitgehend nutzlos.

Am Ende der Veranstaltung werden die Projekte der Teilnehmer prämiert, der Erstplatzierte bekommt einen Preis, der erste und zweite Verlierer einen Trostpreis. Ruhm und Ansehen sind somit das Einzige, was den Teilnehmern nach der Veranstaltung bleibt.

Bereits auf der Veranstaltungswebsite ist ersichtlich, wozu die Veranstaltung dient. Die Teilnehmer sollen Software entwickeln, um das Auftreten von Gleislagefehler vorhersagen. Während beim ersten Hackathon Tools für Fahrplansoll- und -echtzeitdaten entwickelt wurden, ist die Zielgruppe von Gleislagefehler-Analysetools deutlich geringer. Statt interessanter Daten werden für die aktuelle Veranstaltung also nur unkritische Datensätze bereitgestellt, mit denen außer Gleisbauern kaum jemand etwas anfangen kann. Wer bei diesem Hackathon mitmacht, hackt nicht für sich und die Allgemeinheit (worum es bei Open-Data gehen sollte), sondern für ein Unternehmen, das bei dieser Veranstaltung Code und Ideen abgreifen möchte. Dies sollte den Teilnehmern bewusst sein.

Auf der anderen Seite verfügt die DB über viele für die Öffentlichkeit interessante Daten, die ohne Probleme als "richtiges" Open-Data freigegeben werden könnten. Beispiele dafür sind das Betriebsstellenverzeichnis und das Infrastrukturregister. Die Daten sind bereits jetzt öffentlich sichtbar, die Webseite bietet die entsprechenden Daten an.

Man bekommt den Eindruck, dass die DB den Begriff Open-Data lediglich als Marketingbuzzword verwendet, um sich modern und dynamisch zu präsentieren. Auf diese Weise möchte man sich ein wenig das Image eines Startups verpassen, in der Hoffnung, damit entsprechende innovative Entwickler anzulocken.

Fazit: Nicht überall da, wo Open-Data draufsteht, ist auch Open-Data drin. Das vorliegende Beispiel zeigt, dass man vor der Teilnahme genauer hinsehen sollte, welchen Bedingungen man sich unterwirft. Weder sind die Daten frei, noch dürfen sie unbeschränkt verbreitet werden. Bloß der Nutzungszweck während des Hackathons ist nicht beschränkt. Wer sich nicht in eine gewisse Abhängigkeit von Unternehmen begeben möchte, für den sind Projekte wie OpenStreetMap weiterhin die erste Wahl. Bei solchen nachhaltigen Quellen können Entwickler wirklich sichergehen, dass eine Anwendung auch noch nach dem Hackathon nutzbar bleibt. Und vor allem, dass die Arbeit nicht umsonst war, denn dafür ist die investierte Zeit einfach zu schade.

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.

Am Wochenende des 9. bis 11. Januar 2015 waren Alexander (rurseekatze) und Michael (Nakaner) auf dem FOSSGIS-Hackweekend im Linuxhotel in Essen. Der FOSSGIS e.V. ist der deutsche OpenStreetMap-Förderverein für freie GIS-Software. Das Linuxhotel ist ein Hotel für Schulungen zu Open-Source-Software, das an Wochenenden von Open-Source-Communities zu günstigen Preisen für Hackweekends u.ä. gemietet werden kann.

Während Alex im Laufe des Wochenendes eine JOSM-Objektvorlage für Österreich erstellte, widmete sich Michael den kleineren Dingen. Der Signallayer zeigt künftig Bahnübergangsüberwachungssignale (Bü 0/1), die Sv-Signale der Hamburger S-Bahn¹ und Sh 2-Tafeln. Die Icons für Ks-Signale wurden durch neue Icons ersetzt. Um das Hp 0 von den Hp 0-Icons der Hl-, H/V- und Sv-Lichtsignalsysteme unterscheiden zu können, wurde die Bedeutung der Farben bei Ks-Signalen geändert. Hp 0 (oben im Schirm) steht künftig für ein Ks-Mehrabschnittssignal, Ks 1 für ein Ks-Hauptsignal und Ks 2 für Ks-Vorsignal.

Auch am Infrastrukturstil verbesserte Michael einige Sachen. Künftig werden die Namen von Tunnels und Brücken dargestellt, wenn sie als tunnel:name=* bzw. bridge:name=* getaggt sind. Straßenbahnen werden erst ab Zoomstufe 10 gerendert, da sonst die Karte in Ballungsräumen zu unübersichtlich ist. Industriegleise werden etwas schmäler dargestellt.

Wie in mehreren Bugreports gefordert, wurde der Höchstgeschwindigkeitslayer verbessert. Künftig wird die ehemahls bzw. künftig zulässige Höchstgeschwindigkeit stillgelegter und in Bau befindliche Gleise dargestellt. Abgebaute Strecken und Strecken in Planung werden künftig nicht mehr dargestellt.

Bereits seit einigen Wochen werden außerdem die Gleise im Signallayer zur besseren Orientierungsmöglichkeit als graue Linien dargestellt.

Bitte beachtet, dass diese Änderungen noch nicht auf den Liveserver übertragen wurden und somit momentan auch noch nicht auf der Karte sichtbar sind. Dies wird so schnell wie möglich nachgeholt.

Wer sich dafür interessiert, was auf dem Hackweekend neben der OpenRailwayMap, sei auf einen Blogartikel auf der Homepage des FOSSGIS e.V. verwiesen.

Wir bedanken uns beim FOSSGIS dafür, dass wir im Rahmen des Hackweekends gemeinsam die OpenRailwayMap voranbringen konnten und freuen uns schon auf das nächste Mal. Das nächste Hackweekend mit Beteiligung der OpenRailwayMap ist das Hackweekend im Februar in der Geofabrik in Karlsruhe.

¹ nur, wenn railway:signal:combined:states=* getaggt ist und das Signal Hp 0 oder Sv 0 anzeigen kann

Der Signallayer stellt ab sofort auch Kombinations- und Vorsignale des Hl-Systems der Deutschen Reichsbahn dar (Beispiel).

Die Implementierung hat sich aufgrund der vielen Signalbilder deutlich aufwendiger gestaltet als bei den H/V-Signalen. Beim H/V-Signalsystem haben wir entschieden, aufgrund der geringen Icongröße (sonst wird zu viel von den Icons verdeckt) nur das Hauptsignal darzustellen, auch wenn am selben Mast (oder wenige Meter davor) noch ein Vorsignal hängt. Damit reduzierte sich die mögliche Anzahl an Signalkombinationen erheblich. Bei H/V-Signalen können wir mit drei Icons für Licht- und drei für Formhauptsignale alles darstellen.

Zuerst einmal eine kurze Erläuterung des Hl-Signalsystems für Leute, denen das Verständnis anfangs schwer fällt. Beim Hl-System ist das nicht so einfach. Es vereint Vor- und Hauptsignalfunktionen in einem Schirm und hat bis zu fünf Lampen. Manche Kombinationssignale haben auch noch zwei zusätzliche Lichtstreifen zur Signalisierung der Geschwindigkeiten 60 und 100 km/h. Signalbilder mit blinkenden Lampen können in statischen Kartenkacheln nicht dargestellt werden. Somit entfallen schon einmal die Signalbilder Hl 4, Hl 5, Hl 6a, Hl 6b, Hl 7, Hl 8, Hl 9a und Hl 9b.

Die oberen Lampen übernehmen die Vorsignalfunktion (Fahrt erwarten, 100 km/h erwarten, 40/60 km/h erwarten, Halt erwarten). In der Mitte sitzt die rote Lampe für Hp 0 (es gibt noch ein Ersatzrot unten rechts). Die gelbe Lampe unten links leuchtet, wenn ab dem Signalstandort nicht Fahrt mit Höchstgeschwindigkeit (im Westen Hp 1) oder Langsamfahrt (im Westen Hp 2) gilt. Leuchte diese gelbe untere Lampe, so bedeutet das Langsamfahrt mit 40 km/h. Mit einem gelben oder grünen Lichtstreifen darunter kann das zu 60 bzw. 100 km/h angehoben werden.

Aber nun zurück zur Karte. Die Icons sollten, wie auch bei den H/V-Signalen, dem Kartennutzer anzeigen, welche Signalbilder das Signal anzeigen kann. Wenn in den OpenStreetMap-Daten nicht hinterlegt ist, welche Signalbilder das Signal anzeigen kann, wird Hp 0 in der Hl-Variante (rotes Licht in der Mitte des Signalschirms) dargestellt. Grundsätzlich wird nur das Tag railway:signal:main:states bzw. railway:signal:combined:states ausgewertet. Ob es sich um ein Block-, Einfahr-, Zwischen- oder Ausfahrsignal handelt, ist irrelevant.

Blocksignale können nur Hl 1, Hl 10¹ und Hp 0 anzeigen (anders ausgedrückt: Sie können kein Hl 2, Hl 3a und Hl 3b anzeigen). Sie werden als Hl 1 (grünes Licht/Signal ohne Vorsignalfunktion) bzw. als Hl 10 (gelbes Licht/Signal mit Vorsignalfunktion²) dargestellt.

Wenn der Zusatzschirm für die Lichtbalken nicht installiert ist, kann das Signal nicht Hl 2 und Hl 3b anzeigen. Es wird dann bei Signalen ohne Vorsignalfunktion Hl 3a (oben grünes, unten gelbes Licht) und bei Signalen mit Vorsignalfunktion Hl 12a (oben gelbes, unten gelbes Licht) angezeigt.

Wenn der Zusatzschirm für den Lichtbalken zwar installiert ist, aber nur einen gelben Lichtstreifen anzeigen kann (die grünen Lampen fehlen dann), wird Hl 3b (oben grünes, darunter gelbes Licht, unten gelber Balken) bei Signalen ohne Vorsignalfunktion und Hl 12b (oben gelbes, darunter gelbes Licht, unten gelber Balken) bei Signalen mit Vorsignalfunktion angezeigt.

Wenn der Zusatzschirm grüne und gelbe Lichtbalken anzeigen kann, wird Hl 2 (oben grünes, darunter gelbes Licht, unten grüner Balken) bei Signalen ohne Vorsignalfunktion und Hl 11 (oben gelbes, darunter gelbes Licht, unten grüner Balken) bei Signalen mit Vorsignalfunktion angezeigt.

Bei Hl-Vorsignalen wird Hl 1 mit dem Signal Ne 2 (Vorsignaltafel) gekennzeichnet.

Jetzt bleiben nur noch zwei Eisenbahnsignalsysteme übrig, die die OpenRailwayMap nicht darstellt – das Sk-System (Signalkombination, Augsburg–Donauwörth) und das Sv-System (noch bei der Hamburger S-Bahn im Einsatz). Wenn du auch das Signalsystem deines Landes (wir rendern derzeit nur österreichische Trapeztafeln, da diese mit den deutschen identisch sind) auf der OpenRailwayMap sehen möchtest, dann stelle uns bitte Folgendes zur Verfügung:

• deutsch- oder englischsprachige Beschreibung des Signalsystems
• geeignete Icons im SVG-Format
• Vorschläge für Renderingregeln (muss nicht gleich schon als MapCSS-Code implementiert sein)

¹ nur bei Hl-Signalen in deren Bremsweg ein Signal mit Hauptsignalfunktion steht, erkennbar an railway:signal:main=hl am Signal

² erkennbar am gelben Dreieck auf dem Mastschild

Seit letztem Freitag laufen die täglichen Datenupdates wieder ohne Probleme, nachdem es vorher für einige Wochen keine oder nur unregelmäßige Updates gegeben hatte.

Der Aktualisierungsprozess konnte leider nicht wie geplant auf die Augmented Diffs der Overpass API umgestellt werden, weil das Format dafür momentan nicht geeignet ist, sodass die bisherige Toolchain erstmal beibehalten wird. Der dafür notwendige Speicherplatz wurde durch eine Änderung des RAID-Levels der beiden SSDs geschaffen. Statt wie bisher als RAID-1 sind diese nun als RAID-0 verbunden, was den doppelten Speicherplatz und etwas höhere Performance bietet und gleichzeitig keine Mehrkosten verursacht hat.

Den einzigen Nachteil stellt die höhere Anfälligkeit gegen Plattenausfälle dar, jedoch sehe ich dies erstmal als verschmerzbar an, da auf dem Server nur sehr wenige Daten liegen, die nicht noch woanders gesichert sind. Diese Daten lassen sich auch problemlos regelmäßig auf einen anderen Rechner sichern und bei einem Totalausfall und anschließender Neuinstallation des Systems wieder einspielen.

Langfristig wäre aber dennoch eine zusätzliche herkömmliche Festplatte wünschenswert, um komfortabel vollständige Backups des Systems ablegen und bei einem Ausfall das System wiederherstellen zu können. Das kostet aber wieder zusätzliches Geld...

Vom 24. bis 26. Oktober 2014 fand bei User spth in Bad Nauheim das zweite OpenRailwayMap-Aktiventreffen statt. Es ist als Fortsetzung des Mappingwochenendes im Juli in Köln zu sehen. Taggingfragen, die damals aus Zeitgründen nicht geklärt werden konnten, standen nun auf der Tagesordnung, ebenso mittlerweile aufgetauchte Fragen.

Die beiden anderen Teilnehmer, Michael (Nakaner) und Alex (rurseekatze), nutzten die Anreise zum Mappen. Während Michael extra einen Umweg von Kalsruhe über Heilbronn und die Hessische Odenwaldbahn fuhr und dort GPS-basiert Daten erfasste, filmte Alex die Strecken um Düsseldorf und Köln, solange sein ICE nicht zu schnell fuhr.

Das genaue Protokoll ist im OpenStreetMap-Wiki verfügbar. Im Folgenden die wichtigsten Ergebnisse des Treffens:

Am Freitagabend wurde u.a. über die Abgrenzung von Straßen-, Stadt-, Voll- und U-Bahn diskutiert. Zum Tag railway=narrow_gauge ist unsere Meinung, dass dies ein veraltetes Synonym für railway=rail ist. Umtaggen nützt nichts und wird nicht beabsichtigt.

Wenn Gleise verschlungen sind, empfehlen wir das Mappen aller betroffenen Gleise als einzelne Ways und das Taggen der Abschnitte mit railway:interlaced=yes. Für Begegungsverbote mangels Gleisabstand (wenn es keine Gleisverschlingung ist) wird das Tag railway:passing_prohibited=left/right/yes/both eingeführt. Damit endete der Freitagabend.

Am Samstagmorgen gingen die Diskussionen weiter. Entegen des Grundsatzes, dass ein Gleis nicht sowohl mit usage=* als auch mit service=* getaggt sein darf, wird zur Unterscheidung zwischen Nebengleisen von Industriebahnen und normalen Nebengleisen künftig die Kombination service=* + usage=industrial erlaubt sein.

Für die Gesetze/Verordnungen der deutschen Bundesländer zu Klein- und Anschlussbahnen wurden Werte für den Schlüssel workrules=* definiert, die dem Protokoll entnommen werden können. Auch für die Meterlast und Achslast gibt es jetzt neue Tags – meter_load=* und axle_load=*.

In der Frage, was als Höchstgeschwindigkeit (maxspeed=*) getaggt werden soll, wenn für unterschiedliche Fahrzeugtypen unterschiedliche Höchstgeschwindigkeiten gelten (z.B. Neigetechnik vs. keine Neigetechnik oder Fahrzeuge mit/ohne Wirbelstrombremse), wurde keine Einigung erzielt.

Wenn auf Oberleitungsmasten eine Speiseleitung mitgeführt wird, kann man die Masten mit power=catenary_mast taggen. Dieses Tag kann man auch für O-Busse und elektrische Schiffe benutzen. Neue Tags wurden auch für Einspeisungen aus der Speiseleitung, Überbrückbarkeit von Trennstellen per Schalter, versenkbare Mittelstromschienen, Schrankenwärterposten, Blockstellen, Anschlussstellen eingeführt.

Wir sind der Meinung, dass das Tag railway=station für U-Bahnhöfe nicht richtig ist und analog zu Straßenbahnhaltestellen durch railway=subway_station ersetzt werden sollte. Eine Diskussion im OpenStreetMap-Forum wurde mittlerweile angestoßen.

Am Samstagnachmittag wurde zur Abwechslung zu Fuß ein wenig entlang der Main-Weser-Bahn nach Gambach und Gießen gemappt.

Da das Tag railway=owner_change immer häufiger auch für Betreiberwechsel (z.B. DB Netz/Albtal-Verkehrsgesellschaft) und nicht, wie ursprünglich mal gedacht, für Betreiberwechsel an Staatsgrenzen, wird das Tag railway=border eingeführt.

Neu sind auch Tags für die in Russland gebräuchlichen Fahrbahnsperren zur Bahnübergangssicherung und für die in England gebräuchlichen Tore. Wenn ein Andreaskreuz vorhanden ist, kann crossing:saltire=yes getaggt werden. Der Key crossing:supervision beschreibt die Überwachung (Schrankenwärter, Kamera, Gefahrenraum-Freimeldeanlage usw.) und crossing:activation wie der Bahnübergang eingeschaltet wird. Auch für die Schließdauer eine Bahnübergangs gibt es nun Tags.

Am Sonntag wurden für Straßenbahnsignale und die Signale der Berliner U-Bahn Tags erfunden. In Zuge dessen wurde neue Keys eingeführt. Weichensignale trägt man als railway:signal:switch=* ein. Die Einführung von Straßenbahnsignalen wurde als Anlass genutzt, das Tagging für LZB-Signale zu überarbeiten.

Kurz vor Ende des Treffens am Sonntagnachmittag wurden noch Tags für diverse Einrichtungen in Betriebswerken erfunden, z.B. WC-Entsorgungsanlagen.

Wie auch auf der Hinfahrt wurde auch auf der Rückfahrt gemappt. Michael hat den Abschnitt Friedberg–Frankfurt (Main) Hbf und weiter Richtung Heidelberg gefilmt, bis es ab Weinheim-Lützelsachsen zu dunkel wurde und der Akku leer war, Alex hat Teile der linken Rheinstrecke zwischen Mainz und Koblenz gefilmt, solange es die Lichtverhältnisse zuließen.

Der Streik der Gewerkschaft der Lokomotivführer hat Alexander Matheisen (rurseekatze) nicht abgehalten, zum OpenStreetMap-Hackweekend der Geofabrik in Karlsruhe zu kommen. Gemeinsam mit Michael Reichert (Nakaner) wurde an den Kartenstilen der OpenRailwayMap gearbeitet.

Im Geschwindigkeitslayer werden künftig alle Gleise ohne maxspeed-Tag als graue Linien gerendert, die Karte erscheint künftig nicht mehr so lückenhaft. Alle Gleise werden erst ab der Zoomstufe gerendert, ab der sie auch im Infrastruktur-Layer erscheinen. Somit verschwinden in hohen Zoomstufen die blauen Linien langsam befahrbarer Straßenbahngleise und auch Nebengleise in Bahnhöfen, die mit service=* getaggt sind, stören künftig nicht mehr in niedrigen Zoomstufen. Daneben wurden Darstellungsfehler behoben, wodurch teilweise auch die Maxspeed-Informationen von Straßen auf der Karte auftauchten. Außerdem werden Streckengeschwindigkeiten nun nur noch auf aktiv genutzten Gleisen angezeigt. Es wird aber überlegt, ob etwas stillgelegte oder im Bau befindliche Strecken doch angezeigt werden sollten und durch einen helleren Farbton kenntlich gemacht werden.

Der Signallayer hat in Deutschland ebenfalls eine Erweiterung erfahren. Hp-Formsignale werden künftig mit neuen, realistischeren Icons gerendert. Für Hauptsignale gilt: Wenn in den Daten hinterlegt ist, welche Signalbilder das Signal anzeigen kann (railway:signal:main:states), dann wird das Signalbild Hp 2 (Langsamfahrt) dargestellt, wenn das Signal Hp 2 anzeigen kann. Wenn das Signal nicht Hp 2 anzeigen kann, wird Hp 1 (Fahrt) gerendert. Wenn in den Daten keine Angaben über die möglichen Signalbilder hinterlegt sind, wird Hp 0 (Halt) angezeigt.

Auch Vr-Form- und Vr-Lichtvorsignale werden künftig mit neuen Icons gerendert. Bei den Lichtsignalen ist das schon seit einigen Tagen der Fall. Wenn ein Signal Vr2 (Langsamfahrt erwarten) anzeigen kann, dann wird Vr 2 Symbol dargestellt. Wenn es nicht Vr 2 anzeigen kann, wird Vr1 (Fahrt erwarten) angezeigt. Ist keine Information über die möglichen Signalbilder hinterlegt, wird Vr 0 (Halt erwarten) dargestellt. Bei Formvorsignalen wird das Icon um ein Ne 2 (Vorsignaltafel) ergänzt, um sie von Wärtervorsignalen unterscheiden zu können. Zusätzlich werden Lichtvorsignalwiederholer wie in der Realität durch ein weißes Zusatzlicht gekennzeichnet.

Neue Icons für Hp-Lichthauptsignale der Bundesbahn und die Hl-Signale der Reichsbahn sind auch gezeichnet, aber noch nicht in den Kartenstil integriert worden, was aber sicherlich in den nächsten Tagen erfolgen wird. Gerade beim komplizierten Hl-System müssen noch geeignete Darstellungsregeln gefunden werden.

Hätte die OpenRailwayMap eine Audioausgabe, würde es nun auf mancher Nebenbahn läuten und schellen. Die Anzeige von Pfeif- und Läutetafeln (Bü 4, Pf 1, Pf 2, Bü 5) ist jetzt integriert. Das Icon für Trapeztafeln (Ne1) wurde neu gezeichnet. Auch Haltepunkttafeln (Ne 6) sind nun zu sehen. Haltetafeln (Ne 5) werden schon seit einigen Tagen dargestellt, wenn auch angebrachte Zusatztafeln wie "200 m" noch nicht auf der Karte visualisiert werden.

Die Icons für Schutzsignale (Sh 0/Sh 1, Hp 0/Sh 1) sind neu gezeichnet worden und werden bald in den Stil integriert werden. Bald folgen außerdem noch die Bahnübergangsüberwachungssignale (Bü 0/Bü 1).

Alle verwendeten neuen Icons entstammen Michaels Sammlung railway-signals, wurden aber aus optischen Gründen teilweise vereinfacht (z.B. Formvorsignale, Hp-Lichthauptsignale, Bahnübergangsüberwachungssignale).

Aber auch ein anderer Teilnehmer des Hackweekends hat eine Überraschung für uns parat gehabt. Arndt Breschede, der Entwickler des Android-Fahrradrouters BRouter (Webinterface, Google Play), hat ein sehr einfach gehaltenes Routingprofil für Eisenbahnen geschrieben. Noch berechnet es Routen über alles, was Schienen hat, egal ob Tram oder Eisenbahn, biegt an Weichen spitz ab und fährt gern im Gegengleis. Wer Zeit und Lust hat, darf das Profil gerne erweitern. Eigene Routingprofile können bei BRouter-Web über das Eingabefeld unten links verwendet werden. Ein besonderes Feature von BRouter, ist die Fähigkeit No-Go-Areas zu definieren, was man bei der Bahn "Streckensperrung" nennt. Vielleicht integrieren wir mal einen Bahnrouter auf Basis des BRouter in die OpenRailwayMap.

Das von Alexander eigentlich geplante Mapping der linken Rheinstrecke musste leider ausfallen, da die eingesetzten Wagen einerseits keinen GPS-Empfang zuließen, andererseits wegen Streikausfällen so überfüllt waren, dass kein Fensterplatz mehr frei war.

Beim Erfassen von Eisenbahndaten in OpenStreetMap hatte ich in der Vergangenheit immer wieder mit den typischen Taggingfehlern zu tun. Eines Tages stieß ich dann eher zufällig auf die Möglichkeit, den Validator von JOSM mit MapCSS-ähnlichen Regeln zu erweitern.

Nun habe ich eine solche Prüfregel-Datei für JOSM erstellt. Sie enthält eine erste Auswahl typischer Taggingfehler, aber ich habe auch noch eine lange Liste weiterer Fehler, die ich nach und nach hinzufügen möchte.

Wahrscheinlich sind jedem Eisenbahnmapper ebenfalls schon einmal typische Taggingfehler begegnet. Daher wäre es schön, wenn andere Mapper weitere Prüfregeln beisteuern könnten. Die einfachste Möglichkeit wären Pull Requests, Vorschläge per E-Mail sind aber ebenfalls willkommen.

Seit einigen Tagen werden praktisch alle deutschen Geschwindigkeitssignale auf der Karte angezeigt. Wechselt man in die Ansicht der Streckengeschwindigkeiten, so erscheint vielerorts bereits eine große Anzahl von Signalen. Die Zs 3(v) Lichtsignale werden noch nicht angezeigt, was in Hinblick auf mehrere darstellbare Ziffern schwierig ist. Über mögliche Umsetzungen einer Darstellung wird nachgedacht. Ebenfalls fehlen noch die Signale für vorübergehende Langsamfahrstellen (Lf 1/2 und 1-5). Da solche Langsamfahrstellen in der Regel aber auch nicht in der OpenRailwayMap eingetragen werden, sollte dies aber keinen größeren Nachteil darstellen.

Ein Beispielgebiet, in dem bereits fast alle Geschwindigkeitssignale erfasst wurden, ist hier zu sehen. Die Sichtbarkeit der Signale auf der Karte dürfte für viele Mapper ein Anreiz sein, diese zu erfassen.

Demnächst werden im Signallayer weitere Icons ergänzt bzw. die bestehenden Icons durch schönere Symbole ersetzt.

An dieser Stelle vielen Dank an die fleißigen Icon-Zeichner Michael und Consti!

Vom Freitag, den 11. bis Sonntag, den 13. Juli 2014 fand in Köln das erste OpenRailwayMap-Mappingwochenende (mit Taggingdiskussion) statt. Es diente dem Austausch der Eisenbahnmapper und der Diskussion über Ergänzungen und Veränderungen am Eisenbahn-Taggingschema. Mit Emrah Kutlu war auch ein Vertreter von Mentz DV dabei.

Der Freitagabend begann locker im Lokal K in Köln-Ehrenfeld mit dem Eintrudeln und einer Vorstellungsrunde der Teilnehmer. Themen waren die Öffentlichkeitsarbeit der OpenRailwayMap und der Gewinnung neuer Mapper (insbesondere von bahninteressierten Nichtmappern als Bahnmapper). Im Anschluss stellte jeder Teilnehmer seine Mappingtechniken vor.

Der Samstagvormittag begann mit dem Frühstück im Lokal K, welches in eine Vorstellung von Mentz DV und deren Nutzung von OSM-Daten überging. Es zeigte sich, dass manches, was man bisher eher aus Spaß mappte, doch sinnvoll war. Emrah klärte darüber auf, dass auch das Mappen von Sitzbänken sinnvoll ist. Es ermöglicht ein besseres Routing im Rollator-Modus, wo die Existenz von Sitzbänken zum Ausruhen die Routenfindung beeinflusst.

Bei der Vorstellung diverser Eisenbahnroutingfehler erklärten wir ihm die Tags service=*, usage=* und maxspeed=*. Auch der Bedarf eines Tags für die Regelfahrtrichtung wurde dabei offensichtlich. Die Regelfahrtrichtung ist die Richtung, in die ein Gleis normalerweise befahren wird (bei zweigleisigen Strecken in Deutschland in der Regel das rechte Gleis in Fahrtrichtung). Wenn auf einer zweigleisigen Strecke vor und nach einer Kurve die Möglichkeit besteht, das Gleis zu wechseln, so könnte ein Router über das kurveninnere Gleis routen, auch wenn das das Gegengleis ist und mit dieser Fahrt andere Zugfahrten blockiert werden würden. Deshalb werden Gegengleisfahrten in der Praxis in der Regel nicht geplant.

Am Samstagnachmittag wurden die Diskussionen für eine Mappingaktivität unterbrochen. Von Köln West aus fuhren Consti, Alex, Michael und Emrah nach Euskirchen. Emrah verlies die Gruppe dort und fuhr zwecks Heimreise zum Flughafen, der Rest fuhr weiter nach Bad Münstereifel und über Euskirchen wieder zurück nach Köln. Zwei Mapper spazierten von Köln West über die Südbrücke und die Hohenzollernbrücke zum Hauptbahnhof.

Die Fahrt von Köln nach Euskirchen fand in einem Dieseltriebwagen der Baureihe 628 der Südostbayernbahn statt. Mangels GPS-Empfang (außer direkt an der Tür und am Faltenbalg) wurde reines Video- und Fotomapping ohne Georeferenzierung betrieben, auch wenn die Strecke ab Hürth-Kalscheuren nicht elektrifiziert ist. In Euskirchen wurde in die Regionalbahn nach Bad Münstereifel umgestiegen. Die Strecke nach Bad Münstereifel ist eine nicht elektrifizierte Nebenbahn. In Bad Münstereifel blieben wir sitzen und fuhren mit demselben Zug zurück nach Euskirchen. Diese Fahrt fand in einem Diesel-Talent (Baureihe 644/944 und 643.2) statt, in dem überall sehr guter GPS-Empfang bestand. So war es möglich, georeferenzierte Fotos aufzunehmen. Alex fotografierte fast jedes Signal und Consti ging seiner Leidenschaft nach – Fahrscheinautomaten samt Automatennummer für seine Fahrkartenautomatenkarte erfassen. Beim Wenden in Bad Münstereifel lies der Triebfahrzeugführer freundlicherweise den Vorhang zum Führerstand offen, sodass das Fotografieren nach hinten durch den Führerstand möglich war.

In Euskirchen wurde nicht der RE genommen, sondern die 30 Minuten später fahrende RB nach Köln abgewartet. In der Zwischenzeit wurde mittels Fotomapping der Bahnhof und seinen Vorplatz genauestens dokumentiert. Alex fotografierte mit einem 70–300 mm-Teleobjektiv vor allem Signale, Signalnummern und entfernt liegende Objekte im Gleisvorfeld, während Michael mit einem 18–105-mm-Objektiv Übersichtsfotos erstellte. Auch das Bahnhofsgebäude und der Vorplatz wurden gemappt. Zum Leidwesen von Consti hatten die zwei Automaten der Stadtwerke im Busbahnhof keine Nummer.

Der Bahnhof Euskirchen bekommt gerade neue Ks-Signale und ein Elektronisches Stellwerk (EStW). Die neuen Signale sind noch nicht alle aufgestellt, die schon aufgestellten, sind noch mit Ungültigkeitskreuzen gekennzeichnet. Da die alten H/V-Signale wohl nicht mehr lange stehen werden, werden direkt die neuen Ks-Signale eintragen. Eventuell werden die neuen Signale sogar schon vor ihrer Inbetriebnahme in der Karte zu sehen sein. Die Ergebnisse der Mappingtour in die Eifel sind derzeit noch nicht in OpenStreetMap eingetragen. Das folgt noch.

Nach der Ankunft im Lokal K wurden die Taggingdiskussionen fortgesetzt. Die Ergebnisse können dem Protokoll entnommen werden. Gegen 20:00 Uhr stieß mit jotpe ein lokaler Mapper hinzu. Kurz nach Mitternacht beendeten wir die Taggingdiskussionen und fuhren in die Ferienwohnung ins Belgische Viertel.

Consti und Peter reisten am nächsten Morgen direkt von der Ferienwohnung aus ab, Alex und Michael fuhren wieder ins Lokal K, wo sie auf spth aus dem Raum Frankfurt (Main) trafen. Zu dritt wurde bis etwa halb Sechs am Abend noch ein Großteil der Taggingdiskussionsthemen abgearbeitet. Hervorzuheben ist hier die ORM-Meinung zum Mappen von Bahnhöfen als Fläche. Es wurde die Umstellung diverser Eisenbahninfrastruktur-Tags entschieden, die derzeit noch kaum verwendet werden und deren Key- oder Valuewahl sehr ungünstig war.

Das ausführliche Protokoll ist im OSM-Wiki zu finden.

Das Lokal K stellt für solche Treffen eine geeignete und empfehlenswerte Örtlichkeit dar. Wir bedanken uns bei den Kölner Wikipedianern für die Gastfreundschaft. Wenn eine Dusche vorhanden wäre, würde es sogar als Übernachtungsmöglichkeit in Betracht kommen.

Es ist geplant, ein zweites Treffen zu veranstalten, um noch offene Fragen zu klären. Dieses Treffen wird vermutlich etwas zentraler in Deutschland oder im Raum Frankfurt am Main stattfinden.

Die Webseite unter openrailwaymap.org ist nun auch in Französisch, Niederländisch, Portugiesisch, Schwedisch und Ukrainisch verfügbar.

Außerdem wurden die Übersetzungen in Deutsch, Polnisch, Russisch, Spanisch, Tschechisch und Vietnamesisch aktualisiert, wodurch Fehler behoben und bislang fehlende Zeichenketten ergänzt werden.

Die Gruppe der Eisenbahnmapper innerhalb von OSM wird immer größer und das Projekt OpenRailwayMap wächst immer weiter. Daher ist es nun an der Zeit, sich einmal persönlich kennenzulernen.

Dafür planen wir ein Mappingevent, dessen Ziel es ist, eine schlecht erfasste Gegend gemeinsam möglichst vollständig zu erfassen. Dazu würde man in kleinen Gruppen ausschwärmen, um Bahnstrecken abzufahren und kleinere Gebiete zu Fuß zu erkunden. Daneben sollen bei dieser Veranstaltungen aber auch Neulinge an das Thema herangeführt werden. Und auch das gegenseitige Kennenlernen und Austauschen sollte nicht zu kurz kommen.

Derzeit sind wir noch in der Planungsphase und klären, wann und wo das Event stattfinden soll. Den aktuellen Stand der Planung sowie weitere Infos findet man im OSM-Wiki und bei einer Abstimmung.

Damit eine solche Veranstaltung jedoch stattfinden kann, brauchen wir genügend Teilnehmer. Ich hoffe auf reges Interesse!

Nach einem Update werden nun alle Geschwindigkeitswerte für das Rendering des Maxspeed-Layers berücksichtigt, statt wie bislang nur Werte in Schritten von 5 km/h. Dies sorgte bei abweichenden Geschwindigkeitwerten dafür, dass solche Strecken nicht auf der Karte gezeichnet wurden. Davon waren vor allem Linien in Großbrittanien betroffen, bei denen die Werte in km/h statt mph angegeben wurden und sich durch die Umrechnung ungerade Werte ergaben.

Ab sofort ist die OpenRailwayMap auch mit einem eigenen Account auf Twitter vertreten. Dort findet man Infos über neue Funktion der OpenRailwayMap, Bahnmapping und interessante Orte auf der Karte.

Ab sofort ist es einfacher, die OpenRailwayMap auf Smartphones und Tablets zu nutzen: Besucht man openrailwaymap.org mit einem mobilen Endgerät, wird man automatisch auf eine mobile Version umgeleitet. Unter m.openrailwaymap.org kann man die Weiterleitung auf die mobile Seite erzwingen, um sie auch auf dem Desktop aufrufen zu können.

Die mobile Webseite ist - abgesehen von der Hintergrundkarte - vollständig an Retina-Displays angepasst.

Damit steht einer Nutzung unterwegs nichts mehr im Wege, vorausgesetzt man hat eine Internetverbindung. Dank der Möglichkeit, die eigene Position per Geolocation API anzufragen, lässt sich etwa aus dem Zug heraus der eigene Standort auf der Karte mitverfolgen. Auch die Frage, ob der eigene Zug gerade vor einem Blocksignal steht, lässt sich damit leicht beantworten.

Das Taggingschema der Signale wurde umgestaltet: Das allgemeine Taggingschema ist im Bereich der Signale von länderbezogenen Infos befreit worden, dafür wurden nun Seiten zum länderspezifischen Tagging angelegt, auf denen sich detaillierte Infos zum Tagging in den einzelnen Ländern finden. Dies ist übersichtlicher und vermeidet eine Vermischung von internationalen und länderspezifischen Taggingregeln. Nach und nach soll diese Aufteilung für das gesamte Taggingschema umgesetzt werden.

Da es vermehrt auch bahninteressierte Mapper aus dem nicht-deutschsprachigen Raum gibt, ist es nun überfällig, das Taggingschema auch ins Englische zu übersetzen.

Als Kopie der deutschen Seite wurde vor ein paar Tagen die englische Seite für das Taggingschema angelegt.

Für eine einzelne Person ist die Übersetzung dieser umfangreichen Seite in absehbarer Zeit jedoch kaum möglich. Daher würde ich mich über Hilfe bei der Übersetzung freuen. Je mehr Leute helfen, desto schneller ist die Übersetzung abgeschlossen. Das hilft nicht nur den anderssprachigen Mappern, sondern auch mir - wenn ich mich nicht mit der Dokumentation beschäftigen muss, kann ich mich mehr der technischen Weiterentwicklung widmen.

Die Webseite unter openrailwaymap.org ist nun auch in Dänisch, Polnisch, Russisch und Spanisch verfügbar.

Außerdem wurden die Übersetzungen in Deutsch, Englisch, Griechisch, N'ko, Slowenisch, Tschechisch und Vietnameisch aktualisiert, wodurch Fehler behoben und bislang fehlende Zeichenketten ergänzt werden.

Das Rendering der Signalicons wurde angepasst. Bisher bestand das Problem, dass viele Signale nicht oder erst in hohen Zoomstufen zu sehen waren, weil sie mit benachbarten Icons überlappten. Dieses Phänomen trat vor allem in größeren und gut erfassten Bahnhöfen auf. Es verwirrte die User, weil auf den ersten Blick nicht alle eingetragenen Signale zu sehen waren und die Auswahl, welche Signale nun angezeigt werden, willkürlich erfolgte.

Dieses Verhalten wurde nun korrigiert, sodass nun wirklich alle eingetragenen Signale auf der Karte gezeichnet werden. Zwar überlappen sich nun einige Signale mit benachbarten Signalen, jedoch ist nun für den User direkt erkennbar, wie vollständig die Daten sind.

Daneben wurden am Renderer einige Verbesserungen vorgenommen, sodass es nicht mehr zu abgeschnittenen Symbolen an Kachelrändern kommen sollte.

Hinweis: Die Änderungen werden erst nach einem automatischen Neurendern der Tiles auf der Karte sichtbar.

Die Kartendarstellung wurde modifiziert, sodass nun auch Streckennamen auf der Karte erscheinen, die mit dem Tag name=* erfasst wurden.

Hinweis: Die Änderungen werden erst nach einem automatischen Neurendern der Tiles auf der Karte sichtbar.

Die Darstellung der Streckengeschwindigkeiten wurde dahingehend angepasst, dass nur noch allein der Geschwindigkeitswert über die Renderingreihenfolge entscheidet. Sprich: Schnellfahrstrecken überdecken Strecken mit langsameren Geschwindigkeiten. Bislang wurden auch die Tags tunnel=*, bridge=* und layer=* für die Renderingreihenfolge berücksichtigt, was jedoch für unerwartete Ergebnisse sorgte, weil etwa eine Hochgeschwindgkeitsstrecke in einem Tunnel trotz ihrer höheren Geschwindigkeit von langsameren Strecken überdeckt wurde. Nun werden diese Tags im Maxspeed-Layer vom Renderer ignoriert.

Hinweis: Die Änderungen werden erst nach einem automatischen Neurendern der Tiles auf der Karte sichtbar.

Wir sind erfolgreich auf einen leistungsfähigeren Server umgezogen. Die immer weiter wachsenden Datenmengen, die ansteigenden Userzahlen und die vielen neuen Funktionen hatten dies erfordert.

Der neue Server hat die folgende Hardwareausstattung:

• 2x 240 GB SSD
• 16 GB RAM
• 1x Xeon Quadcore 2,4 GHz

Das bedeutet eine wesentliche Leistungssteigerung gegenüber dem bisherigen Server, der folgende Hardwareausstattung hatte:

• 1x 80 GB HDD
• 2 GB RAM
• 1x Dualcore CPU 2,4 GHz

Damit sollte sich die Karte und die Suchfunktion nun leicht flüssiger anfühlen, vor allem aber wird der Server nun deutlich entlastet. Allerdings ist auch noch etwas Feintuning der Datenbank notwendig, um die neue Hardware optimal auszunutzen.

Für alle bahninteressierten Mapper, Anwender und Entwickler der OpenRailwayMap steht nun eine Mailingliste zur Verfügung.

Ab sofort gibt es den offiziellen RSS-Feed zur OpenRailwayMap. Hier wird in Zukunft über neue Features und den Entwicklungsprozess berichtet.