Mit der Übertragung der Aufgaben des Baus, Unterhalts und der Verwaltung der Bundesautobahnen von Landesverwaltungen zur Autobahn GmbH des Bundes ging auch die Verantwortung für die Liegenschaften an die Autobahn über.

Für die Verwaltung der Liegenschaften wurde bei vielen Bundesländern die Software GE/ Office Liegenschaften eingesetzt. Auch die Autobahn plante frühzeitig, diese Software später einzusetzen. Im Rahmen des Projektes „SAP-Umsysteme“ wurde die Einführung und damit auch die Datenmigration von den Bundesländern zur Autobahn geplant und durchgeführt. Für die Migration der Daten aus den Liegenschaftsverwaltungen der Bundesländer zur Autobahn wurde das OKSTRA-Format verwendet.

Der Vorgang wurde schrittweise durchgeführt. In den Bundesländern erfolgte die Selektion der relevanten Daten, das Erzeugen von Grundlagen für spätere Migrationstest und der eigentliche Export in das OKSTRA-Format. Die Daten wurden zur Autobahn übertragen und dort importiert. Nach dem Import wurden mit Hilfe von Migrationstests die Vollständigkeit und Korrektheit der Daten verifiziert.

Nicht alle Bundesländer nutzten zur Verwaltung der Liegenschaften GE/Office Liegenschaften und konnten keine Daten im OKSTRA-Format liefern. Die Daten dieser Länder wurden als Excellisten geliefert. Gerade hier zeigte sich der Vorteil eines allgemeingültigen Standards für den Datenaustausch, da hier für jede Excellisten Aufwand entstand.

Insgesamt wurde die Datenmigration von den Bundesländern zur Autobahn über das OKSTRA-Format erfolgreich abgewickelt.

Der Fachvortrag zur Veranstaltung ist im Volltext verfügbar. Das PDF enthält alle Bilder und Formeln.

1 Hintergrund

1.1 Die Autobahn GmbH des Bundes

Seit 1. 1. 2021 werden die Bundesautobahnen und andere Bundesfernstraßen durch Die Autobahn GmbH des Bundes gebaut, geplant, betrieben und erhalten. Bis zu diesem Zeitpunkt erfolgte dies durch die Landesverwaltungen.

Zu den Aufgaben im Bereich des Unterhaltes gehört auch die Verwaltung der Liegenschaften der Bundesautobahnen und anderer Bundesfernstraßen.

1.2 GE/Office Liegenschaften

Für die Verwaltung der Liegenschaften (Flurstücke im Besitz der Bundesstraßenverwaltung) wurde bei zwölf Bundesländern GE/Office Liegenschaften (LV) eingesetzt. Die LV wurde durch die Bundesanstalt für Straßenwesen (BASt) und die Bundesländer im Rahmen einer Bundeslizenz beschafft. Die Autobahn GmbH des Bundes ist diesem Pflegeverbund beigetreten und plante frühzeitig die LV ebenfalls einzusetzen.

Die LV ist eine Software aus dem Hause AKG Software GmbH. Die Daten der .NET-Anwendung liegen in einer zentralen Datenbank (MS SQL-Server oder ORACLE). Verwaltet werden in der LV die Flurstücke des Bundes und weitere abhängige Daten wie bspw. Grundbücher oder Pachtverträge. Der folgende Screenshot zeigt die LV mit der integrierten GIS-Anbindung auf Basis von ArcGIS Runtime für .NET:

Bild 1: GE/Office Liegenschaften

Mit Hilfe der LV können die täglichen Arbeiten des Liegenschaftsverwalters wie die Verwaltung von Pachten, die Prüfung von entbehrlichen Flächen oder Bearbeitung von Gebühren, aber auch wichtige jährliche Auswertungen wie die Vermögensrechnung für das Bundesministerium der Finanzen und die Abfragen für das Bundesministerium für Digitales und Verkehr durchgeführt werden.

Bild 2: Ausgabe der Vermögensrechnung

1.3 SAP-Umsysteme

Im Zuge des Aufbaus der Autobahn GmbH wurde eine Gruppe von Programmen mit SAP-Bezug zu einem Projekt SAP-Umsysteme zusammengefasst. Diese Gruppe umfasst die Programme MaViS, iTWO und die Produktfamilie GE/Office. Wobei hier die Produktfamilie GE/Office die Programme GE/Office Grunderwerb, GE/Office Liegenschaften und GE/Office seven umfasst. Mit Start der Autobahn Anfang 2021 wurden hiervon GE/Office Grunderwerb und GE/Office Liegenschaften in den produktiven Betrieb übernommen.

Im Rahmen dieses Projektes wurde die Einführung der LV bei der Autobahn geplant und durchgeführt. Eine besondere Herausforderung stellte dabei die Datenmigration dar. In diesem Dokument wird die Datenmigration aus den Bundesländern in die LV bei der Autobahn beschrieben.

1.4 OKSTRA als Transportmedium und notwendige Erweiterungen

1.4.1 OKSTRA als Transportmedium

Für diese Datenmigration wurde frühzeitig das OKSTRA-Format als Transportmedium festgelegt.

Grundsätzlich stellte sich einigen Beteiligten die Frage, warum nicht einfach die kompletten Datenbanken von den Ländern an die Autobahn übergeben werden, da die Struktur der Datenbanken in der Quelle und am Ziel deckungsgleich sind. Diese Überlegung vernachlässigt aber die Tatsache, dass in den Datenbanken nicht nur die Flurstücke der Autobahnen, sondern auch der Bundes- und Landes- bzw. Staatsstraßen verwaltet werden. Diese Flurstücke sollten üblicherweise nicht an die Autobahn übergeben werden. Zusätzlich sollten bei der Übergabe an die Autobahn in den Datenbanken bei den Ländern auch die abgegebenen Flurstücke gekennzeichnet werden. Dies wäre bei einer Übergabe der Datenbanken nicht möglich gewesen.

Es wurde daher ein Datenformat benötigt, das es erlaubt die Daten bei den Ländern zu exportieren und bei der Autobahn zu importieren. An der Stelle fiel die Wahl sehr schnell auf das OKSTRA-Format. Hintergrund der Entscheidung waren folgende Überlegungen.

• Eine Exportschnittstelle war in der LV bereits integriert und Teil der Pflegeversion, die bei den Ländern im Einsatz ist. Damit war zum einen bereits die technische Infrastruktur und zum anderen auch schon ein Teil der notwendigen Implementierung vorhanden.
• Im OKSTRA-Format waren weite Teile der notwendigen Strukturen für die Datenübertragung bereits vorhanden. Nichtsdestotrotz waren Erweiterungen notwendig. Diese werden weiter unten näher erläutert.
• Der Hersteller der LV die AKG Software Consulting GmbH verfügte über langjährige Erfahrung mit dem OKSTRA-Format und der OKLABI Klassenbibliothek.

1.4.2  Änderungsantrag A0136

1.4.2.1 Allgemeines

In Hinblick auf die geplante Datenmigration über das OKSTRA-Format, in Kenntnis der noch nicht vollständigen Ausprägung der LV-Daten im OKSTRA und der generellen Forderungen den OKSTRA für alle relevanten LV-Daten zu ertüchtigen, wurde bereits zu einem früheren Zeitpunkt eine Erweiterung des OKSTRA-Formates für LV beantragt.

Die bis zu diesem Zeitpunkt vorliegende Umsetzung der Liegenschaftsdaten im OKSTRA basierte in weiten Teilen auf dem Datenbankschema der Vorgängerversion der LV der LV6. Mit dem Änderungsantrag A0136 – Ergänzung von Objekten im Schema Liegenschaftsverwaltung vom damaligen Leiter der Fachgruppe GE/Office der Antrag gestellt, die notwendigen Änderungen am Schema S_Liegenschaftsverwaltung vorzunehmen. Der Antrag wurde genehmigt und umgesetzt.

1.4.2.2 Beispiel Vermögensgruppen zum Flurstück

An einem konkreten Beispiel der Vermögensgruppen zum Flurstück soll im Folgenden erläutert werden, warum der oben genannte Änderungsantrag für die Datenmigration zur Autobahn von großer Bedeutung war. Oben wurde die Vermögensrechnung des Bundes erwähnt und die Ausgabe mit einer Abbildung verdeutlicht. Die Ausgabe der Vermögensrechnung basiert auf den Vermögensgruppen zum Flurstück. In der ursprünglichen Umsetzung des OKSTRA und auch der LV6 waren zwei Angaben je Flurstück bezüglich der Vermögensgruppe möglich: Verknüpfung einer konkreten Vermögensgruppe und die boolsche Angabe dass weitere Vermögensgruppen vorhanden sind. Dies ist bei den Flurstücksdetails im OKSTRA-Format 2.018 zu sehen:

Bild 3: Vermögensgruppe im OKSTRA 2.018

In der LV wurde die Eingabe der Vermögensgruppe erweitert. Es wurde die Möglichkeit geschaffen, dass je Flurstück beliebig viele Vermögengruppen verknüpft und zusätzlich die Fläche angegeben werden kann.

Bild 4: GE/Office Liegenschaften – Angabe von Vermögensgruppen

Mit der Umsetzung des oben genannten Änderungsantrages im OKSTRA-Format 2.019 war es möglich auch im OKSTRA alle angegebenen Vermögensgruppen inklusive der Flächen zu übertragen. Hierfür wurde im Schema S_Liegenschaftsverwaltung die Objektart LV_Flurstueckdetails_Vermoegensgruppe als Verknüpfung zwischen den Flurstückdetails und den Vermögensgruppen ergänzt.

Bild 5: Verknüpfung Flurstücksdetails und Vermögensgruppen im OKSTRA 2.019

Neben der beschriebenen Erweiterung wurden auch noch andere Details beispielsweise bei den Gebühren oder Pachtdaten ergänzt, die es erlaubten, die Daten besser zu migrieren.

1.5 Ablauf der Datenmigration – allgemein

Die Migration wurde durch einen mehrstufigen Prozess durchgeführt, der im Folgenden beschrieben wird. Dabei ist zu beachten, dass die einzelnen Stufen von unterschiedlichen Akteuren durchgeführt wurden. Erkennbar ist dies an den Klammertexten bei den Überschriften.

1.5.1  Auswahl der relevanten Daten in der LV (Bundesland)

Wie oben bereits erwähnt, enthielten die Datenbank bei den Bundesländern nicht nur Flurstücke der Autobahnen, sondern auch der Bundes- und Landes- bzw. Staatsstraßen. Abhängig davon welche Flurstücke an die Autobahn übergeben werden sollten, musste im ersten Schritt eine Auswahl der relevanten Flurstücke erfolgen. Dies war im Rahmen der LV über den erweiterten Filter und die Straßenklasse möglich. Je nachdem, ob das jeweilige Bundesland auch die Bundestraßen an die Autobahn abgeben hat, war der Filter auf die Autobahn-Flurstücke oder zusätzlich auf die Bundesstraßen-Flurstücke anzuwenden. Im Folgenden ist eine Abbildung des Filters für den Fall der Abgabe der Autobahnen und Bundesstraßen dargestellt.

Bild 6: Erweiterter Filter Flurstücke der Autobahnen und Bundesstraßen

Nachdem der Filter erstellt wurde, konnten die relevanten Flurstücke geladen werden.

1.5.2 Ausgabe von Flurstücksdatenblättern für die Migrationstests (Bundesland)

Bei einem solch komplexen Prozess wie er hier beschrieben ist, können selbstverständlich Fehler auftreten. Um diese zu entdecken und korrigieren zu können, war es unvermeidlich, dass auch Tests durchgeführt wurden. Ziel der Tests war die Sicherung der Vollständigkeit und Korrektheit der Daten. Für die Sicherung der Korrektheit bietet sich der Einsatz von Stichprobentests an. Im konkreten Fall war es hierfür notwendig, dass auch auf Seite der Quelle, also bei den Bundesländern, Dokumente erzeugt wurden, die dann mit den Daten im Ziel verglichen werden konnten.

Daher war der nächste notwendige Schritt das Erzeugen von Flurstücksdatenblättern für zufällig ausgewählte Flurstücke aus der Liste der relevanten Flurstücke. Beim Flurstücksdatenblatt handelt es sich um ein Druckerzeugnis im PDF-Format, das in der LV direkt für einzelnes Flurstück erzeugt werden kann und alle wesentlichen Eigenschaften eines Flurstückes enthält. Im Folgenden ist ein Auszug eines beispielhaften Flurstückblattes dargestellt:

Bild 7: Flurstücksdatenblatt

Um eine sinnvolle Grundlage für die Tests zu haben, sollten je Bundesland mindestens vierzig Flurstücksdatenblätter geliefert werden.

1.5.3 Export der Daten in das OKSTRA-Format (Bundesland)

Nach der Auswahl der Flurstücke und Ausgabe der Flurstücksdatenblätter konnte der eigentliche Export in das OKSTRA-Format durchgeführt werden.

Innerhalb der LV wurde hierfür ein Assistent genutzt, der den Anwender schrittweise durch den Export führt. Um die vorher ausgewählte Menge von relevanten Flurstücken und nicht den gesamten Datenbestand zu exportieren, musste auf der ersten Seite des Assistenten die Option „Flurstücke aus aktueller Suchliste ausgeben“ gewählt werden.

Bild 8: Export OKSTRA Seite 1

Auf der zweiten Seite des Assistenten mussten weitere Details für den Export eingestellt werden. Hierbei von besonderer Bedeutung war die Option „Im/Exportstatus auf „Abgegeben an Autobahn“ setzen“. Diese Option wurde bei der finalen Migration gesetzt und sorgte dafür, dass die relevanten Flurstücke in den Datenbanken bei den Bundesländern markiert wurden. Im Programm selbst werden Flurstücke mit diesem Status optisch hervorgehoben und es besteht die Möglichkeit gezielt nach diesen Flurstücken zu suchen.

Bild 9: Export OKSTRA Seite 2

Nachdem die Einstellungen getroffen wurden, konnte der eigentliche Export durchgeführt werden. Am Ende des Vorgangs wurde eine Zusammenfassung mit den wichtigsten Details gezeigt.

Als Ergebnis des Vorgangs entstanden verschiedene Dateien:

• GZ-Datei mit den OKSTRA-Daten,
• PRT-Datei mit dem Protokoll des Exports,
• ZIP-Datei mit den Anlagen.

In der Protokoll-Datei wurden wichtige Ereignisse und Fehler dokumentiert. Zusätzlich wurde der Export so erweitert, dass am Ende der Protokolldatei ein Mengengerüst ausgegeben wird. Dieses Mengengerüst war Grundlage für die Sicherung der Vollständigkeit der Daten.

In der LV können zu den einzelnen Objekten (Flurstücke, Grundbücher, usw.) beliebig Dateien abgelegt werden. Diese Dateien werden als Anlagen bezeichnet. Bei der Migration sollten diese auch übertragen werden. Beim Export werden die Anlagen für die relevanten Objekte gesammelt und in einem Archiv zusammengefasst.

1.5.4 Übertragung der Daten zur Autobahn (Bundesland, Autobahn, AKG)

Nachdem die Daten exportiert waren, konnten diese zur Autobahn übertragen werden. Dies geschah auf verschiedenen Wegen (SharePoint, FTP oder Ähnliches).

1.5.5 Import der OKSTRA-Daten (AKG)

Nach einer grundsätzlichen Prüfung der Vollständigkeit der gelieferten Dateien konnte auf dem Zielsystem der Autobahn der Import der Daten erfolgen. Wie der Export erfolgte auch der Import schrittweise über einen Assistenten. Im ersten Schritt musste die GZ-Datei ausgewählt werden. Nach der Auswahl wurde die Datei interpretiert und eine Vorschau des Inhaltes angezeigt.

Bild 10: Import OKSTRA Seite 1

Nach der Sichtprüfung der Vorschaudaten konnten die Daten geladen werden. Bei diesem Prozess wurden die Daten geprüft. Teil dieser Prüfung war bspw. die notwendigen Gemarkungen in der LV Datenbank zu suchen. Auf der dritten Seite des Assistenten wurde das Ergebnis der Gemarkungsprüfung angezeigt.

Bild 11: Import OKSTRA Seite 3

Da die Gemarkungskataloge in der LV bei der Autobahn sehr umfangreich und vollständig waren, kam es bei der finalen Datenmigration zu keinen wesentlichen Auffälligkeiten.

Erst nachdem alle notwendigen Gemarkungen vorhanden waren, konnte der eigentliche Import durchgeführt werden. Bei diesem Vorgang wurden die Daten in der Datenbank der LV abgelegt. Wurden durch das Bundesland auch Anlagen geliefert, so wurden diese beim Import direkt verarbeitet und korrekt abgelegt. Am Ende des Imports wurde eine Zusammenfassung erzeugt. Zusätzlich wurde beim Import wie auch beim Export ein Protokoll geschrieben. Auch dieses Protokoll enthielt ein Mengengerüst der Daten.

1.5.6  Ausgabe von Flurstücksdatenblättern für die Migrationstests (Autobahn, AKG)

Wie oben beschrieben sollte auf Basis von Stichprobentests die Korrektheit der Daten belegt werden. Im Quellsystem wurden hierfür Flurstücksdatenblätter erzeugt und an die Autobahn übergeben. Nach dem Import der Daten bei der Autobahn wurden für die gleichen Flurstücke auch im Zielsystem Flurstücksdatenblätter erzeugt.

1.5.7 Migrationstests (Autobahn, AKG)

Nachdem der eigentliche Import erfolgreich abgelaufen war, wurden die oben bereits erwähnten Migrationstests durchgeführt. Grundlage hierfür war jeweils ein Excelprotokoll, in dem die einzelnen Schritte beschrieben waren und die Ergebnisse dokumentiert werden konnten. Getestet wurde auf Vollständigkeit und Korrektheit.

Die Vollständigkeit wurde über die Mengengerüste in den Protokollen des Ex- und Imports durchgeführt. Bspw. wurde die Anzahl der exportierten Flurstücke mit der Anzahl der angelegten Flurstücke verglichen. Vergleiche dieser Art wurden mit sechs Kennzahlen durchgeführt, die es erlaubten, einen guten Rückschluss auf die Vollständigkeit zu ziehen:

An der Stelle traten allerdings auch Diskrepanzen auf, die es zu klären galt. Beispielsweise wurden durch ein Bundesland Flurstücke eines benachbarten Bundeslandes aus dem gemeinsamen Grenzbereich geliefert. Beim Import des zweiten Bundeslandes wurden diese Flurstücke nicht erneut angelegt und daher stimmten an der Stelle die Anzahl der exportierten und angelegten Flurstücke nicht überein. Derartige Probleme wurden geprüft und für die zukünftige Nachvollziehbarkeit auch in den Excelprotokollen abgelegt.

Die Korrektheit der Daten wurde über die Flurstücksdatenblätter bestätigt. Hierzu wurde jeweils das passende Paar aus dem Quell- und Zielsystem geöffnet und sechs Vergleichswerte extrahiert. Konkret waren dies folgende Werte:

Auch bei diesen Vergleichen kam es an einzelnen Stellen zu Diskrepanzen, die es zu prüfen galt. Beispielsweise waren die Texte bei den Grundbüchern nicht deckungsgleich, wenn nicht alle Flurstücke des Quellgrundbuchs relevant waren. Damit variierte die Anzahl der Flurstücke auf dem Grundbuch und damit auch die Vergleichswerte. Auch diese Probleme wurden geprüft und mit der Begründung in den Excelprotokollen abgelegt.

Nach erfolgreichem Abschluss der Prüfungen auf Vollständigkeit und Korrektheit war der Vorgang der Datenmigration im Zielsystem erfolgreich abgeschlossen.

1.5.8 Vermögensrechnung 2020 (Bundesland)

Am Ende des letzten Jahres, in dem die Verwaltung durch die Bundesländer erfolgte (konkret 2020), mussten die Flurstücke noch in der Vermögensrechnung enthalten sein. Der finale Export für die Datenmigration war zeitlich jedoch deutlich früher. Die Flurstücke wurden daher beim Export noch nicht historisch gesetzt, da sie ansonsten nicht in der Vermögensrechnung enthalten gewesen wären.

1.5.9 Abgegebene Flurstücke im Quellsystem historisch (Bundesland)

Nachdem die Vermögensrechnung 2020 durch die Bundesländer erzeugt wurde, konnte der finale Schritt erfolgen. Die abgegebenen Flurstücke konnten historisch gesetzt werden. Hierfür wurde über den oben erwähnten Status nach den abgegebenen Flurstücken gesucht und diese wurden dann historisch gesetzt. So sind sie in den Datenbanken der Länder noch als Historie sichtbar, erschienen bei der Vermögensrechnung 2021 als Abgabe und tauchen nun nicht mehr in Auswertungen auf.

2 Projektphasen

Die Datenmigration wurde in insgesamt drei Phasen durchgeführt. Zwei Testläufen und der finalen Migration. Ziel der Testläufe war zum einen etwaige Fehler in den Schnittstellen zu finden und zum anderen alle Beteiligten im Vorgehen zu schulen.

2.1 Projektphase 1 – 1. Testlauf

Der erste Testlauf der Datenmigration wurde im Frühjahr 2020 durchgeführt.

Oben wurde die Erweiterung des OKSTRA-Schemas für die Daten der LV erläutert. Diese Erweiterung stand beim 1. Testlauf noch nicht zur Verfügung, daher wurde dieser Lauf noch auf der Basis von OKSTRA 2.017 durchgeführt.

Dieser erste Lauf erfolgte auf Basis von OKSTRA 2.017. Im Rahmen dieses Testlaufes konnten zum einen die richtigen Ansprechpartner bei den Ländern gefunden und zum anderen das Vorgehen geübt werden.

Bei diesem Testlauf konnten bereits die ersten Herausforderungen erkannt und die Ursachen behoben werden. Ein Beispiel hierfür waren falsche Gemarkungsschlüssel. Im engen Austausch mit den Bundesländern wurden die Fehler besprochen und teilweise Korrekturen an den Daten in den Quelldatenbanken vorgenommen.

2.2 Projektphase 2 – 2. Testlauf

Für den zweiten Testlauf wurde die Schnittstelle auf das OKSTRA-Format 2.019 erweitert. Auf dieser Basis konnte testweise eine Datenmigration durchgeführt werden, die schon sehr nah an der finalen Migration war. Hier war die wesentliche Herausforderung, dass für den Export eine neue Version der LV ausgeliefert und bei den Ländern installiert werden musste. Aber auch bei diesem Testlauf traten andere Herausforderungen auf, bei denen es gut war, dass diese vor der finalen Migration gelöst werden konnten.

2.3 Projektphase 3 – Finale Datenmigration

Die finale Migration wurde am Ende des Jahres 2020 durchgeführt. Mit diesem Vorgang wurden die relevanten Flurstücke und ihre abhängigen Daten von den Bundesländern an die Autobahn übergeben. Die Daten wurden bei den Bundesländern exportiert und auf Seite der Autobahn in die LV importiert.

Bis auf wenige Ausnahmen erfolgte dies im November und Dezember 2020, so dass die Daten zum produktiven Start der Autobahn im System der Autobahn verfügbar waren. Im Folgenden ist das Mengengerüst der produktiven Datenbank mit Stand vom 24.02.2021 dargestellt.

2.4 Migrationstests

Nachdem die Daten von den Bundesländern in die produktive LV übernommen wurden, wurden diese auf Vollständigkeit und Korrektheit geprüft. Die Prüfung auf Vollständigkeit erfolgte durch einen Vergleich der exportierten und importierten Mengengerüste, die von der Schnittstelle protokolliert wurden. Die inhaltliche Korrektheit wurde anhand von Stichprobentests mit den Flurstücksdatenblättern durchgeführt. Hierfür wurden im Zielsystem zu den gleichen Flurstücken ebenfalls Flurstücksdatenblätter erzeugt und diese dann mit den mitgelieferten verglichen.

Die Ergebnisse wurden in vorbereiteten Excellisten dokumentiert.

3 Herausforderungen und Workarounds

3.1 Anlagen

In der LV können zu konkreten Flurstücken, Grundbüchern, Personen, Pachtdaten, Gebühren und Fortführungsnachweisen beliebig Dateien (beispielsweise Bilder oder Dokumente) abgelegt werden. Diese Dateien werden als Anlagen bezeichnet. Für die relevanten Daten sollten diese Anlagen auch an die Autobahn übertragen werden.

Dabei war die wesentliche Herausforderung, dass das OKSTRA-Format dies nicht vorsah. Daher musste ein Weg gefunden werden, um dies zu realisieren.

Vereinfacht gesagt wurden die Dateien beim Export gesammelt und in ein Zip-Archiv verpackt. Die Ablage in dem Archiv erfolgt in einer Ordnerstruktur, die sich aus der Kategorisierung und Datenbank-ID zusammensetzt. Damit diese Struktur später ausgewertet und die Objekte im Zielsystem korrekt verknüpft werden konnten, war es notwendig, dass die Datenbank ID der Objekte aus dem Quellsystem mit übertragen wurden. Hierfür wurde die OKSTRA-ID der Objekte verwendet.

3.2 Nachlieferungen

Auch wenn die Lieferung im Rahmen von verschiedenen Testläufen geübt wurde, kam es Anfang 2021 zu Konstellationen, wo noch Daten nachgeliefert werden mussten. Diese wurden durch Lieferung von kleinen OKSTRA-Dateien realisiert, die wie auch bei der eigentlichen Migration eingelesen wurden. Hier wurden nur Flurstücke angelegt. Waren einzelne Flurstücke schon vorhanden, wurden diese nicht aktualisiert.

3.3 Fremdsysteme – Excellisten

Nicht in allen Bundesländern wurde GE/Office Liegenschaften zur Verwaltung der Liegenschaften eingesetzt. In den Bundesländern kamen andere Softwaresysteme, die jedoch alle keine OKSTRA-Export-Schnittstelle haben. Um die Daten dennoch zur Autobahn migrieren zu können, wurden in den Systemen Excellisten erzeugt, die in der LV importiert wurden. Allerdings wurde hierfür kein standardisiertes Format genutzt. Der Aufbau der Excellisten war in den einzelnen Bundesländern unterschiedlich. Daher musste je Bundesland/Format ein extra Import entwickelt, dokumentiert und getestet werden. Je Format entstand hier ein deutlicher Mehraufwand. Zusätzlich war auch hier je Format eine Abstimmung mit dem Bundesland für Fehlerkorrekturen und Anpassungen notwendig.

Ein Nachteil der Excellisten war auch, dass die Daten in Excel im Vergleich zum OKSTRA-Format keine Formatvorgaben hatten. Dies bedeutete in der Folge, dass bei der Implementierung besonderes Augenmerk auf die Überprüfung gelegt werden musste. Dies wiederum führte ebenfalls zu einem erhöhten Aufwand.

4 Fazit

Mit Hilfe des OKSTRA-Formates war es möglich, die Daten aus den Liegenschaftsverwaltungen der Bundesländer nahezu verlustfrei zur Autobahn zu migrieren, und diese hatte damit zum Produktionsstart bereits eine solide Datenbasis für die Arbeit mit der LV.

Bei der Umwandlung in und von einem Transportformat treten selbstverständlich auch Verluste auf und bestimmte Daten können nicht transportiert werden. Allerdings lässt sich nach knapp einem Jahr produktiver Arbeit mit der LV sagen, dass die Daten gut bei der Autobahn angekommen sind.

Besonders beim Import der Excellisten wurde der Vorteil eines standardisierten Datenformates, wie der OKSTRA es ist, deutlich. Hätte mit allen sechszehn Bundesländern ein Import über nicht standardisierte Excelliste erfolgen müssen, wäre die Datenmigration im verfügbaren Zeitrahmen nicht möglich gewesen.