Ein erster Blick auf Aufzugsdaten: Erste Daten von der Bahn
Berlin, 02.11.2015 – Wie unlängst angekündigt hatte die Deutsche Bahn die Öffnung erster Datensätze als „echtes" Open Data in Aussicht gestellt, was nicht ohne Echo blieb:
@okfde @_stk wooot! For real? Party to celebrate? Champagne? @OKFN
— Pieter Colpaert (@pietercolpaert) October 23, 2015
@_stk @pietercolpaert nur Aufzuege? Naja... Irgendwo muss man ja anfangen :)
— Tristram Gräbener (@tristramg) October 23, 2015
@tristramg @_stk @pietercolpaert
No realtime status and position about these elevators?
Very disappointing
— Thomas (@somoht) October 23, 2015
Nun haben die Mühlen gemahlen, und wir können einen kleinen Einblick geben, welche Daten rund um Aufzüge die DB AG vor hat freizugeben, welche Features vorhanden sind – und welche fehlen. Um gleich einmal Hands-on damit etwas anfangen zu können, haben wir vorab einige Auszüge aus den Daten bekommen, die wir auch schon in einer abendlichen Telefonsession mit @Nakaner aus der OpenRailwayMap-Community mit dem Ist-Stand verglichen haben.
Besonderheiten und Caveats
Eines fällt schon bei unserem kleinen Auszug auf: Die vielen verschiedenen Datenfelder sind recht unterschiedlich gepflegt. Bei manchen Datensätzen (siehe das Beispiel Neu-Ulm) sind beinahe alle Felder eingepflegt und auch korrekt, wie die händische Vermessung vor Ort ergab. Anderenorts kann es schon einmal vorkommen, dass bis auf Grunddaten wie die Equipmentnummer, Bahnhof und Baujahr so gut wie nichts dokumentiert ist – inklusive fehlender Koordinaten.
Spannend wird auch die Frage, die wir mit der DB gerade diskutieren, welche der Merkmale passenderweise als Unique Identifier dienen sollen. An jedem Aufzug ist für die Benutzer*innen sichtbar eine Herstellernummer angebracht, die in Verbindung mit dem Hersteller eindeutig ist. Darüber hinaus existiert im Datensatz noch die DB-konzernweit eindeutige Equipmentnummer, die analog zum Hamburger Vorschlag in OSM mitgetaggt werden könnte, um die Verknüpfung zur „Echtwelt" zu schaffen.
Die Koordinaten sind dann noch einmal eine ganz spezielle DB-Spezialität. Auf den ersten Blick ist das simples DHDN/Gauß-Krüger Zone 3 – wie wir aber mittlerweile erklärt bekamen, ist das ein eigenes DB-CRS, innerhalb dessen auch Koordinaten außerhalb der Zone 3 in GK3 passend gemacht worden seien. Die Ausschnitte, die wir mit eigener Ortskenntnis vergleichen konnten, schwankten zwischen besser als metergenauer Lagetreue und systematischen Lagefehlern von rund fuenf Metern. Die DB möchte die Koordinaten im Laufe der nächsten Wochen passend umtransformieren, wird aber auch die Originalkoordinaten veröffentlichen.
Egal, welche Koordinaten in welchem Format: Die Bahn hat aus den Fehlern Dritter gelernt und möchte auf keinen Fall mit einem automatischen Import die OSM zerschießen. Deswegen ist es volle Absicht, der Community so umfangreich wie möglich „echte" offene Daten (bald auch mit dem lange geforderten Betriebsstellenverzeichnis!) zur Verfügung zu stellen.
Was fehlt
Neben den unterschiedlichen Pflegeständen bei Koordinaten und sonstigen Datenfeldern fehlen manche Angaben selbst bei vollständig erfassten Anlagen. Leider nur eingeschränkt sind beispielsweise Rückschlüsse auf die Barrierefreiheit der Aufzüge möglich. Über die Kabinenabmessungen und Türbemaßung – sofern vorhanden – lassen sich zwar Rückschlüsse auf die Eignung für Rollstuhlfahrer*innen nach DIN 18040 ziehen. Informationen über taktile Bedienelemente, Brailleschrift und Stockwerkansagen für blinde und sehgeschädigte Personen (DIN EN 81-70) sind jedoch momentan überhaupt nicht vorhanden. Auch fehlen Informationen, ob der Fahrstuhl durchgängig benutzt werden kann oder nur innerhalb bestimmter Betriebszeiten.
Ausblick, und: Was will die Community?
Das aktuelle Ziel der Bahn ist, noch vor dem #dbhackathon am 11.12. in Berlin eine rudimentäre Alpha-Version einer API für die Aufzüge bereitzustellen. Mittelfristig sollen über diese API alle Aufzüge eines Bahnhofs oder einer Bounding Box abgefragt werden können – inklusive ihres Betriebszustands, d.h. ob sie gerade funktionieren oder ob eine Störung vorliegt. Idealerweise sollte so jedem Aufzug auch ein URL in der OpenStreetMap zugeordnet werden können, um den Betriebszustand abzufragen. Spannend ist auch die Frage, wie ein gemeinsamer Weg aussehen könnte, die derzeit noch fehlenden Koordinaten und IDs gemeinsam zu ergänzen. Die Bahn ist auch daran interessiert, wie das OSM-Mappingschema für Aufzüge gegebenenfalls gemeinsam erweitert werden könnte.
Nachdem es auch Mapper*innen bei der Bahn gibt, ist der Vorschlag für die Erweiterung des Aufzug-Taggingschemas folgender:
opening_hours=*
– Betriebszeiten des Aufzugsref:elevator_machineid=*
– die Herstellerkennung des Aufzugs, der in Verbindung mit dem Hersteller eindeutig sein sollteoperator=*
– Betreiber des Aufzugsref:elevator_operatorid=*
– eindeutiger Schlüssel des Aufzugbetreibers für die Anlage (siehe Hamburger Vorschlag)contact:website=URL
– hier beispielsweise ein Link zur Echtzeit-API
Da die DB dankenswerterweise den bewährten Weg gehen möchte, kleine Schritte in Absprache mit der Community zu gehen, anstatt große Würfe zu versuchen und am Ende ohne Flughafen dazustehen: Wir freuen uns über euren Input!
Zu den Autoren: Stefan Kaufmann (Twitter) mag Züge und braucht endlich eine Warnweste, damit er ohne Argwohn zu erregen nachts Bahnhofsfahrstuhlkabinen nachvermessen kann.
Walter Palmetshofer arbeitet bei der OKF beim ODINE Open Data Incubator for Europe Projekt und fährt gern mit Zügen durch die Landschaft.
Titelbild: DB-Daten (Dreiecke) über der OSM. OSM-Daten © OSM-Mitwirkende