Deutsche bahn.com

hatten wir es bereits angesprochen: Uns liegt am Herzen, dass Ihr die von uns bereitgestellten Daten auch sinnvoll nutzen könnt. Bei einigen der Daten, die wir veröffentlicht haben, fehlen Geokoordinaten. Bei Aufzügen liegt dies mitunter daran, dass die Geoinformation aus einem unter Umständen lange zurückliegenden Bauprojekt stammt, in dem der Aufzug – meist neben anderem – errichtet wurde, die Geoinformation nach Abschluss des Bauprojektes für die anschließende Instandhaltung des Aufzugs aber nicht mehr benötigt wird. Daher verwalten wir diese Geokoordinaten in unseren internen Systemen bislang nur optional, was dazu führt, dass es sie für Aufzüge mal gibt und mal nicht.

Wir planen demnächst den Betriebszustand aller Aufzüge in Bahnhöfen über eine Open API abfragbar zu machen. Damit Karten-Apps diese API sinnvoll nutzen können, bekommen die Geokoordinaten für Aufzüge eine neue Bedeutung, d.h. nun benötigen wir sie, und das schnell, um die API bald veröffentlichen zu können. Hier wollen wir OSM in’s Spiel bringen, denn wir haben gesehen, dass in vielen Bahnhöfen die Aufzüge in OSM bereits gemappt sind, somit in OSM Geokoordinaten dafür existieren.

Natürlich ist uns nicht entgangen, dass nach der Veröffentlichung der Bahnhofsadressdaten ein Crowdsourcing von Geodaten über OSM dazu entstanden ist - und ja, einige von uns haben auch bei diesem Bahnroulette mitgespielt, damit es schneller voran geht ☺:

Der Ansatz ist gut und ließe sich womöglich übertragen auf die Geokodierung von Aufzugsstandorten. Für Teilnehmer des DB Hackathon am 11.12. wollen wir deshalb eine Alpha-Version der neuen Aufzüge-Live-API bereitstellen und diskutieren, wie diese API zweckmäßig weiter gestaltet werden soll, und was man mit den Zustandsdaten der Aufzüge alles machen kann.

Was meint ihr:

1. Welche Anforderungen hat ein Software-Entwickler an die Aufzüge-API, um dagegen vernünftig etwas entwickeln zu können?

2. Wir möchten bei OSM eine Erweiterung des bestehenden OSM-Aufzug-Taggingschemas als Proposal einbringen. Wir haben uns dazu einen betreiberunabhängigen Ansatz überlegt, um auch andere Verkehrsunternehmen zu motivieren, die Daten ihrer Aufzugsanlagen in OSM zu mappen. Kern des Vorschlags ist es, einen – ja, leider! - Fremdschlüssel einzuführen, über den man zu einem in OSM gemappten Aufzug den Betriebszustand beim jeweiligen Betreiber (sofern eine API dazu anbietet) in Echtzeit abfragen kann. Das wäre ein Puzzleteil eines künftigen Fundaments für barrierefreies Routing mit OSM-Daten. Was haltet Ihr davon?

3. Und so sieht unser Vorschlag zum Aufzugs-Tagging aus:

• brand=* – Hersteller
• contact:website=* – URL zur Statusabfrage
• maxweight=* – zulässiges Höchstgewicht (in Tonnen)
• operator=* – Betreiber (z.B. HVV, BVG, DB Station&Service AG, …)
• ref:elevator_machineid=* – Fabriknummer/Herstellernummer (ergibt zusammen mit brand=* eine in der Regel eindeutige und am Aufzug dranstehende Kennzeichnung, Format aber unstrukturiert)
• ref:elevator_operatorid=* – Fremdschlüssel des Aufzugsbetreibers (ergibt zusammen mit operator=* eine eindeutige Kennzeichnung, nutzbar zur Verlinkung mit einer API des Betreibers)
• opening_hours=* – Öffnungs-/Betriebszeiten – das wären z.B. die Öffnungszeiten des Bahnhofs, falls dieser nicht 24h geöffnet ist.

Zusätzlich gibt es folgende Vorschläge, die auf der Tag-Seite derzeit aufgeführt sind:

• Die Angabe einer Störungshotline (momentan noch nicht in unserem Datensatz Aufzüge enthalten) – contact:phone=*
• Sprachansagen für die Stockwerke: speech_output=* bzw. speech_output:de=* – derzeit leider auch noch nicht in unserem Datensatz Aufzüge enthalten.

Was haltet Ihr davon? Wie sollte man es machen?

Im Rahmen des #3DBHackathon am 11.12. in Berlin wollen wir versuchen auch Raum zu geben für eine Diskussion dieser Fragen für diejenigen, die an dem Thema interessiert sind.