Ein grundlegendes Problem vieler Daten im Bahnkontext ist die Verortung ausschließlich über Kilometrierung und die (teils redundante) Datenführung in verschiedenen Systemen, ohne klare Benennung des führenden Systems, wechselseitige Validierung der Daten, Schlüssellisten, Plausibilisierung, etc.
Diesem Missstand kann aus unserer Sicht nur mit einem konsolidierten Anlagenkataster begegnet werden. Idealerweise stellt dieses mittelfristig das führende System für alle raumbezogenen Daten dar. Ist dies nicht möglich, so muss dieses Kataster über automatisierte ETL-Prozesse befüllt werden. Im Rahmen dieser Befüllung können Inkonsistenzen aufzeigt werden, so dass diese im führenden System korrigiert bzw. nachgepflegt werden können.
Gleichzeitig bietet ein Anlagenkataster die einfache Möglichkeit, alle Objekte mit echter (geographischer Lage) zu verorten bzw. zu beschreiben. Mobil ins Feld mitgenommen erleichtern diese Daten ein gezieltes Anfahren der Anlage, gleichzeitig können die Anlagen über absolute Lage direkt mit einander in Beziehung gesetzt werden.
Mit unserem Projekt haben wir versucht zu zeigen, wie ein solches Anlagenkataster aussehen kann und was ein solches Kataster leis-ten kann. Wir haben es geschafft die Daten mit geographischen Daten zu versehen, diese recherchierbar zu machen, diverse Datenfehler transparent aufzuzeigen und diese in einer mobilen App flexibel bereitzustellen.
2. Unsere Challenge (18:00 – 21:00)
Lassen sich Lagefehler im Gleis mit
bestimmten Parametern anderer,
räumlich verorteter Objektklassen
statistisch korrelieren?
Ok, das lässt sich mit den vorhandenen Daten wohl nicht
realisieren, auf jeden Fall nicht in der jetzt verfügbaren
Zeit…
Zeit für einen Hudle!
Disy Informationssysteme GmbH09.05.2015
2
3. Unsere Challenge (21:00 – Ende)
Lasst uns ein kleines Anlagenkataster
bauen! Die Inhomogenität der Daten
schreit doch danach.
Mist. Mist. Mist.
Was sind dass denn für Daten, bzw. Formate?
0,000000000000001+E-17 für eine Kilometrierung? „m2“ und ähnliches im
Spaltennamen der sqlite-Datenbank? „&“ als normaler Text der DB?
Und wie bitte kann ein Gebäude 541,8 km lang sein?
Disy Informationssysteme GmbH09.05.2015
3
4. Unsere (Zwischen-)Challenge (22:00 – 08:00)
Wie bekommen wir die Daten in eine
„echte“ Geodatenbank?
Und wenn wir dabei sind, was findet
sich denn sonst noch alles an „Müll“ in
den Daten?
Disy Informationssysteme GmbH09.05.2015
4
5. Wie bringt man die Daten nach Oracle (unsere Welt)?
5
Disy Informationssysteme GmbH09.05.2015
Anpassen in sqlite
Laden mit RazorSQL
6. Kreative Daten – Pflegen oder wegwerfen
Gebäude (SAP GB)
-> 45 Gebäude die lt. Kilometrierung > 500 m lang sind, Rekord 541,8 km
-> 35 Einträge in VON_M > 99
-> 458 Gebäude, die laut H_KM_STATION mehr als 500 m von der
Kilometrierung entfernt liegen (Daten richtig interpretiert?)
Tunnel (SAP TU)
-> 3 Tunnel, die lt. Länge mehr als 500 m von der Kilotrierungslänge abweichen
(keine Kilometrierungssprünge)
Alle vier Shapefiles
-> Komplett identische Sachdaten (auch die Kilometrierung!), aber
unterschiedliche Geometrien
-> diverse Schreibfehler, sowohl in Sachdaten als auch Attributnamen (keine
Schlüsselisten!)
6
Disy Informationssysteme GmbH09.05.2015
7. Anlagenkataster – Wie sind wir vorgegangen
7
Disy Informationssysteme GmbH09.05.2015
• Dynamisches Abrücken von
Anlagenarten, die nicht im
Gleiskörper liegen
• Bereitstellung zur Recherche
(z.B. alle Weichen eines
Bautyps)
• Darstellung in der Karte
• Neupositionierung auf
Luftbilder o.ä.
• Berechnung der Stationierungen in der Datenbank
14. Team MET
14
Disy Informationssysteme GmbH09.05.2015
Eva Kramer
eva.kramer@disy.net
Markus Beck
markus.beck@disy.net
Torsten Brauer
torsten.brauer@disy.net