Direkt zum Inhalt | Direkt zur Hauptnavigation | Direkt zu den weiterführenden Informationen

Migration

Daten und Formate

Um welchen Dateityp handelt es sich bei einem „NAS“-Auftrag?

Hierbei handelt es sich um eine XML-Datei bzw. eine Sammlung (Konvoi) von XML-Dateien je „Auftrag“ (NAS = Normbasierte Austauschschnittstelle). Diese Bezeichnung ist „belegt“ durch das AdV bzw. die Katasterverwaltung im Allgemeinen; daher wird im LISA-Umfeld die Bezeichnung LISA-GML verwendet (GML = Geography Markup Language). GML beruht auf dem Standard XML und ist eine Sprachdefinition, mit der geometrische Daten beschrieben werden.

Auch bei der NAS handelt es sich grundsätzlich um ein GML-Format, analog zu „LISA-GML“ könnte man die NAS auch als „AdV-GML“ bezeichnen. Entscheidend ist nämlich zusätzlich, in welchem Modell die geometrischen Daten beschrieben sind.

Werden Liegenschaften aller Nutzer (Bundeswehr, Bund zivil, Land) in einer gemeinsamen Geodatenbank gespeichert?

Ja.

Welche Liegenschaftsdaten sind an das BAIUDBw abzugeben? In welchem Format erfolgt die Datenabgabe?

Es sind die Daten zu allen im Land geführten Bundeswehr-Liegenschaften abzugeben; die Abgabe erfolgt als File-Geodatabase (FGDB). Über technische Details zur Erstellung dieser FGDB informiert das Dokument „Datenabgabe mit LISA LM DBSync <VersNr.>“, welches dem jeweiligen Programmpaket zum LISA DBSync beiliegt.

Auch mit Einführung des LISA LM 2018 wird sich das Abgabeformat an das BAIUDBw zunächst nicht ändern. Hier ist bis auf Weiteres ein Parallelbetrieb von LISA LM 2015 und LISA LM 2018 notwendig.

Welche Bedeutung hat das EDBS-Format sowie die Software EDBS Reader im LISA LM-Umfeld?

Der EDBS Reader, in einigen Abbildungen und Tabellen noch aufgelistet, hat im LISA LM-Umfeld keine Bedeutung mehr. Ursprünglich war EDBS als Standardschnittstelle für die Bestandsdaten vorgesehen. Da über das EDBS-Format aber keine z-Koordinaten transportiert werden können, hierzu aber entsprechende Anforderung bestand, wurde dieser Ansatz verworfen und ein direkter Import von GIAP-Verfahren umgesetzt.

Datenmigration

Welchen Zwecken dient die Konvertierung der Bestandsdaten (neben der Datenlieferung an das BAIUDBw)?

Die Konvertierung der Bestandsdaten aus dem ALK-GIAP mit der LISA Migrationsanwendung dient nicht ausschließlich dem Zweck, BAIUDBw im geforderten Format beliefern zu können (auch wenn hierauf momentan die höchste Priorität liegt). Die Konvertierung ist auch Grundvoraussetzung für den Einsatz der neuen (Fach-)Auskunftssysteme unter der neuen Basissoftware.

Schließlich ist die (wiederholte) Konvertierung auch als notwendige Vorstufe für die finale Migration zur Einführung der neuen Bearbeitungssysteme zu sehen (sukzessive Qualifizierung der LISA1-Daten). Mit nur einem Migrationslauf wird für die allermeisten Datenbestände KEIN verlustfreier Übergang in die neue Datenhaltungskomponente ArcGIS Server gelingen!

Schreibt die Migrationsanwendung bei Auftreten von Fehlern Meldungen in die Protokolldateien?

Im Rahmen der Konvertierung/Migration werden alle Arbeitsschritte protokolliert. Bei Auftreten von Fehlern werden entsprechende Meldungen in die Protokolldateien geschrieben. Anhand der Protokolle soll der Anwender in die Lage versetzt werden, die Qualität und Quantität (Vollständigkeit) der Ergebnisse zu bewerten.

Wie ist das Handling mit den im Primärdatenbestand (ALK-GIAP) enthaltenen Katasterdaten (ALK-Daten) bei der Konvertierung?

Die ALK-Daten aus den Folien 001 bis 099 werden nicht mehr in das neue LISA-Datenmodell übernommen (d. h. es erfolgt keine Konvertierung in den ArcGIS Server).

Wie werden in der ArcSDE des ArcGIS Server Höheninformationen gespeichert?

In der ArcSDE (Spatial Database Engine des ArcGIS Server) werden die Geodaten des LISA in so genanntem 2,5D gespeichert. Dies bedeutet, dass zu jedem Stützpunkt der Geometrietypen Fläche, Polylinie, Punkt neben x- und y-Wert auch eine z-Koordinate gespeichert wird sowie je Geoobjekt einmalig das Höhenbezugssystem. Diese z-Koordinate wird zwar im System geführt, es erfolgt aber (derzeit) keine dreidimensionale Darstellung. Hierzu wäre die kostenpflichtige ArcGIS-Extension 3D Analyst erforderlich.

Es ist zu beachten, dass in den Verarbeitungsprozessen des LISA die gespeicherten z-Werte nicht bei evtl. erforderlichen Transformationen verwendet werden, also damit kein dreidimensionaler Transformationsansatz verfolgt wird.

Werden Höhen, die als Textobjektteil gespeichert sind, automatisch als z-Koordinate umgesetzt?

Nein. Die textlichen Höheninformationen müssen skriptgestützt in z-Werte konvertiert werden.

Gibt es eine automatische Bestandsdatenaktualisierung?

Nein. Die Datenaktualisierung im Rahmen der Konvertierung (Überführung der Primärdaten in einen Sekundärdatenserver) erfolgt stets über

1. Löschen aller Daten einer „Migrationseinheit“ im Server
2. Konvertieren der aktualisierten Primärdaten zur selben „Migrationseinheit“ (komplett, nicht NUR die geänderten Objekte!)

Wie viele Migrationseinheiten bzw. welche Objektmengen sollten maximal in einem Migrationsauftrag verwaltet werden?

Im Rahmen der zentralen Migration wurden problemlos ca. 25 Migrationseinheiten in einem Migrationsauftrag eingebunden und auch im Batchbetrieb konvertiert. Es können auch mehr als 25 Migrationseinheiten in einem Auftrag verwaltet werden. Entscheidend ist, wie viele Migrationseinheiten letztendlich im Batchbetrieb konvertiert werden, da der Umfang Auswirkungen auf die Notwendigkeit des anschließenden Housekeeping-Prozesses hat (siehe Frage „Was sind die Kriterien, um das sogenannte Housekeeping durchzuführen?“).

Die Angabe einer Objektmenge ist nicht möglich, da keine Aussage getroffen werden kann, wie lange die Konvertierung einer bestimmten Anzahl von Objekten oder einer bestimmten Größe eines Ausgangsverfahrens dauert.

Wie viele und welche Zeichen darf die Migrationseinheit besitzen?

Im Datenbankmodell wird die Migrationseinheit in der Tabelle „S_ALLOBJECTS“ als „GEBID“ vom Typ „VARCHAR2(255)“ geführt, d. h. es wären maximal 255 alphanumerische Zeichen zulässig. Die weitere Beschränkung der zulässigen Zeichen erfolgt durch die Anwendung selbst. In der Oberfläche / im Dialog „LISA2 Migration - Migrationseinheit" sind maximal 30 alphanumerische Zeichen zulässig.

Wenn LISA1 und LISA LM auf unterschiedlichen Servern installiert wurden, gibt es dann eine ständige Kommunikation zwischen der Migrationsanwendung und ADMIN?

Nein, während der Migration gibt es nur am Anfang einmalig eine Kommunikation mit ADMIN. Einige Angaben zur Liegenschaft aus dem ADMIN werden dem Migrationsauftrag/-ergebnis als Attribut angefügt.

Können die LISA LM-Daten erst ab der Einführung der (Fach-) Auskunftssysteme gesichtet werden?

Nein, die Sichtung der Daten kann unmittelbar nach erfolgter Konvertierung mit der dann aktuellen Auslieferung des LISA View (wie im Einführungsworkshop LISA LM demonstriert) erfolgen. LISA View wird dabei zunächst im Wesentlichen ein vorkonfiguriertes ArcMap-Projekt sein, das eine BFR-konforme Sicht auf die Geodaten ermöglicht.

Beim Einlesen der Fehlerprotokolle in den GIAP sind bei der Abfrage des Koordinatensystems bisher nur die Werte GK oder UTM zulässig. Wie muss man sich bei Soldnerkoordinaten verhalten?

Bei Vorliegen eines Verfahrens mit Soldnerkoordinaten kann sowohl GK als auch UTM eingegeben werden, um die entsprechende Position zur Fehlermeldung in der Grafik anzuzeigen.

Wird bei der Funktion <Objektnamenmigration> die Info-Art überprüft (Vorgabe 16) und ggf. korrigiert?

Bei der Objektnamenmigration des GEO TOP wird auch eine fehlerhafte Info-Art bei sonst korrekter LISA-GUID korrigiert. Hierbei ist zu beachten, dass im Protokoll kein Hinweis auf diese Korrektur aufgeführt wird. Daher muss nach erfolgter Objektnamenmigration das ALK-GIAP-Verfahren immer gespeichert werden, um die Korrekturen zu übernehmen.

Geschieht eine Transformation von Höhen?

Nein. Die Höhen werden nur als Wert übernommen. Umrechnungen der Höhen finden grundsätzlich nicht statt.

nach obennach oben
Lisa-Newsletter
Aktuelle Informationen zu LISA