INTERN Informatives für unsere Beschäftigten 3/2008

Transkript

1 Hessisches Landesamt für Bodenmanagement und Geoinformation INTERN Informatives für unsere Beschäftigten 3/2008 ALKIS - Realisierung für Hessen

2 ALKIS- Realisierung für Hessen

3 Inhalt Inhalt Vorwort Dr. Hansgerd Terlinden 3 Rechts- und Verwaltungsvorschriften Martin Hinderer 4 Geschäftsprozessmodell,Hessen Franz Adam 8 Die Vor-Ort-Lösung zu ALKIS Klaus Bischof, Ute Leddin, Volker Merdan, Dorothea Padberg und Ralf Pauly 10 Zusammenarbeit mit der Grundbuchverwaltung Klaus Eisenhuth und Dorothea Padberg 26 DV-System Friedhelm Geitz 30 Erfahrungen aus 5 Jahren Vormigrationsarbeiten Reinhard Limmert und Roland Peter 35 Migration nach ALKIS (Produktionsmigration) Reinhard Limmert 39 Transformation in das Lagebezugssystem ETRS89/UTM Bernhard Heckmann 44 Einrichtung und Führung von AFIS Bernhard Heckmann 48 ATKIS - Migration und Modellierung im AAA-Modell Karl-Heinz Kullmann 52 Synergien zwischen ALKIS und ATKIS im AAA-Modell Mario Friehl, Karl-Heinz Kullmann und Reinhard Limmert 56 Abkürzungsverzeichnis Redaktionsteam 62 2

4 Vorwort Vorwort Dr. Hansgerd Terlinden Liebe Leserinnen, liebe Leser, wir stehen kurz vor der Migration der Geobasisdaten der Hessischen Verwaltung für Bodenmanagement und Geoinformation (HVBG) nach ALKIS, AFIS und ATKIS. Für die HVBG hat die Migration der bisherigen Geobasisdaten in das AAA- Datenmodell eine herausragende strategische Bedeutung. Mit der Erledigung dieses fachpolitischen Arbeitsauftrages sind wir für die Zukunft gut gerüstet. Ein besonderes Augenmerk liegt dabei auf den Daten des Liegenschaftskatasters, die von den Ämtern für Bodenmanagement (ÄfB) nach ALKIS überführt werden. Die hierzu erforderliche DVtechnische Systemumgebung haben wir inzwischen so weit entwickelt, dass wir Sie nunmehr mit diesem zweiten INTERN-Themenheft darüber informieren. Der Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bundesrepublik Deutschland (AdV) ist es hervorragend gelungen, mit dem AAA-Datenmodell eine gesamtheitliche Sicht auf die Geobasisdaten zu entwickeln. Damit hat sie den Weg für eine völlige Neuausrichtung der GIS-Komponenten zur Führung von Geobasisdaten geebnet. Zur DV-technischen Realisierung der AAA-Vorgaben sind zwei Komponenten zu entwickeln: der AAA-Desktop zur dezentralen Erhebung und Qualifizierung von Fortführungsdaten sowie die Datenhaltungskomponente (DHK) mit Auskunfts- und Präsentationskomponente (APK) zur zentralen Speicherung der Geobasisdaten und Belieferung unserer Kunden mit den daraus abgeleiteten Produkten. Mit dem AAA-Desktop haben wir die Philosophie der AdV in konsequenter Weise umgesetzt. Der AAA-Desktop wurde völlig neu entwickelt und bildet das zentrale DV-Werkzeug für alle Anwendungen in der HVBG zur Führung von ALKIS, AFIS, ATKIS und LEFIS. Die technische Anbindung an das Elektronische Grundbuch zur automatisierten Aktualisierung der Bestandsdaten auf beiden Seiten stellt dabei einen besonderen Fortschritt dar. In diesem Heft kommen vorwiegend die Systemspezialistinnen und Systemspezialisten des AAA-Desktops zu Wort. Sie befassen sich im Schwerpunkt mit der technischen Realisierung und Bereitstellung der GIS-Werkzeuge. Daneben werden weitere unverzichtbare Aspekte zur Einführung von ALKIS beleuchtet, wie beispielsweise die Neuausrichtung der Systemarchitektur und die landesweite Datenqualifizierung als Basis für die Migration. Das zweite, zentrale Element der ALKIS- Entwicklung, die DHK und APK, ist auf den Weg gebracht. Die technische Realisierung hierzu werden wir in einem nachfolgenden Heft veröffentlichen. Die Einführung von ALKIS bedeutet eine immense Herausforderung für unsere Verwaltung. Alle Beteiligten in diesem Entwicklungsprozess haben durch ihr unermüdliches Engagement und ihre hohe Professionalität dazu beigetragen, dass dieser Paradigmenwechsel erfolgreich abgeschlossen wird. Was Ende des letzten Jahrhunderts noch als Vision galt, ist dann Realität. An dieser Stelle danke ich ganz herzlich allen Beschäftigten der HVBG sowie allen externen Beteiligten, die sich in diesem komplexen Entwicklungsprozess so vorbildlich engagiert und ihn zum Erfolg geführt haben. Mit dieser Veröffentlichung möchten wir Sie, liebe Leserinnen und Leser neugierig auf,alkis in der Praxis machen. In diesem Sinne empfehle ich Ihnen:,Lesen Sie los. Ihr Präsident des Hessischen Landesamtes für Bodenmanagement und Geoinformation 3

5 Rechts- und Verwaltungsvorschriften Rechts- und Verwaltungsvorschriften Martin Hinderer 4 1 Das Hessische Vermessungs- und Geoinformationsgesetz (HVGG) und ALKIS Hochentwickelte und wirtschaftlich leistungsfähige Gesellschaften sind in immer stärkerem Maße auf aktuelle und bedarfsgerechte Geoinformationen sowie Dienstleistungsangebote rund um die nicht vermehrbare Ressource,Grund und Boden angewiesen. In diesem Umfeld nimmt das öffentliche Vermessungswesen über seine traditionelle Zuständigkeit für das amtliche Raumbezugssystem, das Liegenschaftskataster und die amtliche Geotopographie hinausgehend eine exponierte Stellung ein, indem es die Bezugsgrundlage (Geobasis) für vielfältige raumbezogene Fachinformationssysteme bereitstellt und den Aufbau von Geodateninfrastrukturen koordinierend und moderierend unterstützt. Da die alte gesetzliche Grundlage aus dem Jahr 1992 dieser neuen Programmatik und erweiterten Aufgabenstellung nicht mehr gerecht wurde, hat die Hessische Landesregierung im Mai 2007 einen Gesetzentwurf in den Hessischen Landtag eingebracht. Das daraufhin verabschiedete,hessische Gesetz über das öffentliche Vermessungs- und Geoinformationswesen (Hessisches Vermessungs- und Geoinformationsgesetz - HVGG) ist mit Jahresbeginn 2008 in Kraft getreten und begründet ein modernes Mandat für das öffentliche Vermessungswesen. Innerhalb dieses neu definierten Aufgabenspektrums kommt der Umstellung der Datenbanken des Raumbezugssystems, des Liegenschaftskatasters und der Geotopographie auf das von der Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bundesrepublik Deutschland (AdV) entwickelte bundeseinheitliche AFIS-ALKIS-ATKIS- Modell (AAA-Modell) eine besondere Bedeutung zu. Diese Migration schafft für die Geodateninfrastrukturen auf allen Verwaltungsebenen einen nach aktuellen internationalen Standards entwickelten Nukleus, der zukunftsweisend und für die Modellierung von Geodaten anderer Fachdisziplinen beispielgebend ist. Das öffentliche Vermessungswesen in Hessen leistet damit seiner Basisfunktion entsprechend einen maßgebenden Beitrag zum Aufbau von Geodateninfrastrukturen. Das AAA-Modell ist im HVGG zwar nicht unmittelbar vorgeschrieben. Angesichts der Beschlusslage in der AdV bedingt jedoch die in 2 Abs. 1 HVGG begründete Pflicht, auf eine in den Grundzügen länderübergreifend einheitliche Wahrnehmung der Aufgaben im öffentlichen Vermessungswesen hinzuwirken, zwangsläufig die Umstellung auf das AAA- Modell, so wie es der Kabinettsausschuss,Verwaltungsreform und Verwaltungsinformatik im Jahr 2002 in Auftrag gegeben hat. Auch die mit der Umstellung gekoppelte Einführung des neuen Koordinatenreferenzsystems ETRS89/UTM erfährt durch das HVGG mit der Vorschrift nach,bundeseinheitlich definierten Bezugssystemen ( 5 Abs. 1 HVGG) eine normative Absicherung. Darüber hinaus setzt das HVGG auch neue Akzente für die im Liegenschaftskataster zu führenden Inhalte und deren Qualitätssicherung. So wurde im Interesse der Aktualität des Gebäudenachweises das Einmessungsverfahren deutlich gestrafft und auf die liegenschaftsrechtlich bedeutsamen Gebäude beschränkt. Dahinter steht die Überzeugung, dass eine Kernmenge, deren Qualität mit den verfügbaren Ressourcen nachhaltig garantiert werden kann, insbesondere auch aus der Nutzersicht vorteilhafter ist als eine große Bandbreite von Objektarten, für die keinerlei Aussichten auf einen vollständigen und aktuellen Nachweis bestehen. Diese Philosophie wird auch bei der Erarbeitung der begleitenden Verwaltungsvorschriften konsequent beibehalten.

6 Rechts- und Verwaltungsvorschriften 2 Der hessische Objektartenkatalog für ALKIS In den Objektartenkatalogen für AFIS, ALKIS und ATKIS hat die AdV abschließend alle relevanten Informationen zum geodätischen Raumbezug, zum Liegenschaftskataster und zur Geotopographie aus fachlicher Sicht in so genannten Fachobjekten strukturiert. Der Objektartenkatalog für ALKIS enthält insofern alle in der Bundesrepublik denkbaren Informationen für das Liegenschaftskataster und ist darüber hinaus mit dem Datenmodell von AFIS und ATKIS semantisch harmonisiert. In Verfolgung der in Abschnitt 1 skizzierten Philosophie wurde aus dem Gesamtspektrum des AdV-Objektartenkatalogs für ALKIS eine Teilmenge ausgewählt und in einem hessischen Objektartenkatalog für ALKIS dokumentiert. Dieser Katalog beschreibt damit den künftigen Inhalt des Liegenschaftskatasters in Hessen und wird wesentlicher Gegenstand einer Anweisung zur Einrichtung und Führung des Liegenschaftskatasters sein (vgl. Abschnitt 4). Ausgangspunkt für die Festlegung der künftig in Hessen relevanten Basisinformationen war der von der AdV beschlossene ALKIS-Grunddatenbestand, auf dessen Führung sich alle Länder als Mindestumfang gleichermaßen verpflichtet haben. Mit diesem Grunddatenbestand wird den Forderungen überregionaler Nutzer auf länderübergreifend einheitliche Inhalte und Strukturen des Liegenschaftskatasters Rechnung getragen. Für die Definition des darüber hinausgehenden Inhalts des hessischen Objektartenkatalogs für ALKIS waren mehrere Aspekte maßgebend. Zum ei- nen sollen im Liegenschaftskataster nur noch Basisinformationen geführt werden, die bei realistischer Betrachtung der verfügbaren Methoden und Ressourcen flächendeckend, vollständig und aktuell nachgewiesen werden können. Der hessische Objektartenkatalog für ALKIS enthält daher beispielsweise keine Reliefformen oder Grenzeinrichtungen. Zum anderen wurden auch Inhalte berücksichtigt, für deren Führung eine gesetzliche Verpflichtung besteht (z. B. Bodenschätzungsergebnisse) oder die zur Organisation gemeinsamer Datenerhebungsprozesse für ALKIS und das ATKIS-Landschaftsmodell und zur Ausschöpfung entsprechender Synergien notwendig sind (dies betrifft insbesondere die Gebäude und die Tatsächliche Nutzung). Schließlich wird auf die nachrichtliche Führung von Fachinformationen anderer Verwaltungen verzichtet (z.b. Schutzgebietsflächen), die in dortigen Datenbanken gespeichert sind und bereits heute im Sinne der Geodateninfrastruktur gemeinsam mit den Geobasisdaten des Liegenschaftskatasters präsentiert werden können. Eine Folge der zuvor beschriebenen Grundsätze ist beispielsweise, dass im Bereich der Gebäude die Informationen u. a. zur Gebäudefunktion, zur Lage des Gebäudes zur Erdoberfläche sowie zur Anzahl der Geschosse bei Hochhäusern unmittelbar in ALKIS geführt werden. Neu wird im Liegenschaftskataster die Beschreibung überlagernder Tatsächlicher Nutzungen sein (z. B. Straße über Fließgewässer, Fließgewässer unter Weg). Zu diesem Zweck ist es künftig notwendig, die beiden Bauwerke,Brücke und,durchlass im Liegenschaftskataster zu führen. 3 Die Liegenschaftsdatenerhebungsanweisung (LEA) Mit der Einführung von ALKIS im Liegenschaftskataster sind weitreichende Veränderungen in den Geschäftsprozessen verbunden. Dies betrifft auch den Erhebungsprozess für die Fortführung, der den Vermessungsstellen nach 15 Abs. 2 HVGG obliegt. Mit der Anweisung zur Erhebung von Daten für das Liegenschaftskataster (Liegenschaftsdatenerhebungsanweisung - LEA) sollen auch die bisherigen Vorschriften für diesen Bereich (insbesondere Katastervermessungsanweisung und Katasterpunktanweisung) den durch ALKIS vorgegebenen Rahmenbedingungen angepasst werden. Die wesentlichen Regelungsinhalte der kommenden LEA werden nachfolgend skizziert: Die LEA wird im Einzelnen vorgeben, welche Geometrieund Sachdaten insbesondere in Übereinstimmung mit dem hessischen Objektartenkatalog für ALKIS im Rahmen des Erhebungsprozesses (z. B. bei der Einmessung von Gebäuden) erfasst werden. Das ETRS89/UTM - Zone 32 mit dem geozentrisch gelagerten Referenzellipsoid GRS80 wird als amtliches Raumbezugssystem für die Lagekoordinaten vorgegeben. Die Umrechnung in den Lagestatus 100 (homogenes Landesnetz im Potsdam-Datum mit Bessel- Ellipsoid und Gauß-Krüger- Abbildung) ist bei Bedarf über einen landesweit einheitlichen Transformationsansatz möglich. Das ETRS89/UTM bildet ein wichtiges Element beim Aufbau der Geodateninfrastrukturen innerhalb der Europäischen Gemeinschaft. 5

7 Rechts- und Verwaltungsvorschriften Die LEA bestimmt ferner, dass die Realisierung des geodätischen Lagebezugssystems vorrangig durch den Hochpräzisen Echtzeit-Positionierungsservice von SAPOS (SAPOS-HEPS) erfolgt. Nur wo SAPOS-HEPS nicht uneingeschränkt verfügbar ist (z. B. in eng bebauten Ortslagen), soll sich die Dichte und die Genauigkeit des vorzuhaltenden AP- Feldes nach der Charakteristik des betreffenden Gebiets und nach den einsetzbaren Vermessungsverfahren richten. Möglichst alle der Führung des Liegenschaftskatasters dienenden Erhebungsdaten sollen in die ALKIS-Bestandsdaten überführt werden, so dass eine redundante Archivierung in anderen Systemen (z. B. digitales Rissarchiv) weitestgehend entbehrlich ist. mit der Erstellung des Fortführungsentwurfes. In diesem sind die Erhebungsdaten durch die Vermessungsstelle im ALKIS-konformen Datenformat digital aufzubereiten. Die LEA regelt darüber hinaus, wie zu verfahren ist, wenn am Ende des Erhebungsprozesses ausnahmsweise kein digitaler Fortführungsentwurf steht und welche zusätzlichen Dokumente als Bestandteil der Vermessungsschriften noch einzureichen sind. Die LEA lässt Raum für nähere Regelungen u. a. zur Flächenberechnung und zur Homogenisierung der Grundrissdaten in ALKIS, die das Hessische Landesamt für Bodenmanagement und Geoinformation in Form von Richtlinien herausgeben kann. 4 Die Anweisung für die Einrichtung und Führung des Liegenschaftskatasters Die Anweisung für die Einrichtung und Führung des Liegenschaftskatasters wird u. a. folgende Regelungen enthalten: Was den Inhalt des Liegenschaftskatasters angeht, wird die Anweisung auf die spezifischen Bestimmungen des hessischen Objektartenkatalogs für ALKIS verweisen. Darüber hinaus werden Regeln zur Bezeichnung und Beschreibung von Objekten des Liegenschaftskatasters enthalten sein, soweit sich diese Regeln nicht bereits aus der LEA ergeben. 6 Die nach den Regeln der LEA durch Liegenschaftsvermessungen erzeugten Lagekoordinaten sollen grundsätzlich den alleinigen Zahlennachweis bilden. Es wird vorgeschrieben, dass die Metainformationen zur Qualität der Lage- und Höhendaten künftig durch Attribute zur Herkunft (z. B. gerechnete Lagekoordinate aus Liegenschaftsvermessung, Höhe aus Nivellement), zur Genauigkeitsstufe (in Abhängigkeit von der Standardabweichung der Punktlage oder Punkthöhe) und zur Vertrauenswürdigkeit (kontrolliert, nicht kontrolliert) beschrieben werden. Die technischen Regeln u. a. zur Grenzuntersuchung, zur Bestimmung neuer Grenzpunkte und zur Gebäudeeinmessung sind weitgehend in die LEA integriert. Da die LEA dem Erhebungsprozess für ALKIS gewidmet ist, endet ihr Regelungsradius Die Anweisung wird auch vorschreiben, dass in ALKIS eine Vollhistorie geführt wird. Ferner wird die Anweisung die Prozesse bestimmen, nach denen die von den Vermessungsstellen vorgelegten Vermessungsschriften in das Liegenschaftskataster - insbesondere die ALKIS-Bestandsdaten - einfließen. 5 Die Verwaltungsanweisung Liegenschaftskataster (VAL) Die bereits zum 1. Januar 2008 in Kraft getretene Anweisung zu den Verwaltungsverfahren und sonstigen Verwaltungsmaßnahmen im Liegenschaftskataster (Verwaltungsanweisung Liegenschaftskataster - VAL) enthält u. a. die bislang geltenden Regeln zum Mitteilungsverfahren. Die Vorschrift ist hinsichtlich dieses Bereichs jedoch bereits auf die ALKIS- Terminologie angepasst, in

8 Rechts- und Verwaltungsvorschriften dem sie für die Dokumentation der Veränderungen am Flurstücksbestand bereits die neuen Begrifflichkeiten des Fortführungsnachweises und der daraus abgeleiteten Fortführungsmitteilung verwendet. Darüber hinaus legt sie fest, welche Fortführungsanlässe (bisher: Fortführungsarten) im Sinne von 11 HVGG eine unmittelbare Rechtswirkung nach außen entfalten und insofern eine Fortführungsmitteilung an rechtlich Betroffene erfordern. Durch die Führung der Vollhistorie in ALKIS (vgl. Abschnitt 4) können die Fortführungsnachweise aus dem ALKIS-Datenbestand jederzeit wieder reproduziert werden. Aus diesem Grund ist es künftig nicht mehr erforderlich, Fortführungsnachweise auch dauerhaft in analoger Form zu archivieren. Es genügt eine ergänzende Dokumentation in der Verfahrensakte, welche Adressaten zu welchem Zeitpunkt eine Fortführungsmitteilung erhalten haben. 7 Die Verwaltungskostenordnung für den Geschäftsbereich des Hessischen Ministeriums für Wirtschaft, Verkehr und Landesentwicklung (VwKostO-MWVL) In der VwKostO-MWVL werden für die Ausgaben aus der ALKIS-Datenbank die entsprechenden Gebührentatbestände geschaffen. Dies gilt sowohl für die digitalen (z. B. im NAS-Format) als auch für die analogen Datenbankausgaben (Liegenschaftskarte, Liegenschaftsbeschreibung). 6 Die Datenbanknutzungsanweisung (DBNA) Wie in der ebenfalls bereits zum 1. Januar 2008 in Kraft getretenen Anweisung für die Nutzung der Datenbanken des öffentlichen Vermessungswesens (Datenbanknutzungsanweisung - DBNA) bestimmt ist, richten sich Inhalt und Darstellung analoger Ausgaben aus dem Liegenschaftskataster nach den einschlägigen Festlegungen in ALKIS (Signaturenkatalog). 7

9 Geschäftsprozessmodell Hessen Geschäftsprozessmodell,Hessen Franz Adam 8 1 Definition,Geschäftsprozess Ein Geschäftsprozess ist eine Folge von Schritten (oder ein Rezept), um ein Geschäftsresultat zu erzielen. Im Gegensatz zum Projekt wird der Prozess öfter (immer wieder) durchlaufen. Ein Geschäftsprozess kann auch Teil eines anderen Geschäftsprozesses sein oder andere Geschäftsprozesse enthalten bzw. diese anstoßen. Geschäftsprozesse gehen oft über Abteilungen und Betriebsgrenzen hinweg und gehören zur Ablauforganisation eines Betriebs (siehe Wikipedia). 2 Einleitung Für die Erarbeitung der Geschäftsprozesse zur Führung und Aktualisierung des Liegenschaftskatasters im ALKIS- Modell wurde in Hessen der PG ALKIS die Unterprojektgruppe Geschäftsprozesse (UPG-GP) zugeordnet. Diese ist mit Mitgliedern aus den Abteilungen 1 (Liegenschaftsdaten), 2 (Flurneuordnung) und 3 (Datenerhebung, Georeferenzierung) der ÄfB sowie der Abteilungen II (Kataster, Flurneuordnung) und III (Geoinformation, Geodatenmanagement) des HLBG besetzt. Je nach Bedarf werden weitere Fachkräfte in die konzeptionellen Entwicklungsarbeiten mit einbezogen. 3 Vorgehen und Entscheidungen der UPG-GP Nach Auswertung aller vorliegenden Informationen und sorgfältiger Abwägung aller Vor- und Nachteile kam die UPG zu der Entscheidung, die Geschäftsprozesse nicht als Workflow wie in Nordrhein- Westfalen (NRW), sondern auf der Basis einer Integrierten Vorgangsbearbeitung zu beschreiben. Diese Entscheidung berücksichtigt insbesondere folgende Aspekte: Die hohe, ganzheitliche Arbeits- und Fachkompetenz unserer Mitarbeiterinnen und Mitarbeiter soll unbedingt weiter genutzt und gefördert werden. Das eigenverantwortliche und selbständige Erarbeiten von Lösungen durch unsere Mitarbeiterinnen und Mitarbeiter soll auch weiterhin gestärkt werden. Treten Fehler- und Ausnahmesituationen auf, dann sollen die Mitarbeiterinnen und Mitarbeiter möglichst flexibel reagieren und das Problem einer Lösung zuführen. Abläufe innerhalb der Geschäftsprozesse (besonders in der Einführungsphase) können noch relativ schnell und flexibel angepasst werden. Unter Berücksichtigung der im AAA-Modell vorgegebenen Anlassarten und auf der Grundlage der oben stehenden Entscheidung wurden dann die folgenden Geschäftsprozesse für die Leistungsbeschreibung des AAA-Desktop Hessen (02. Juli 2004) erarbeitet: Zerlegung (ALKIS) Personen- und Bestandsdaten (ALKIS) Berechnung des ordnungsnummernbezogenen Abfindungsanspruches (LEFIS). Neben der Beschreibung der Geschäftsprozesse waren schon in einer relativ frühen Entwicklungsphase des AAA- Desktops Hessen auch Vorgaben zur Zugriffssteuerung auf die lokale Datenhaltung (LDM) durch Rollen- und Berechtigungsfestlegungen zu treffen. Im Beschluss wurden dazu folgende Rollen definiert: Administration (z. B. zur Verwaltung der Datenbank, Verwaltung der Rollen) Migration (z. B. zur Migration und Ersteinrichtung der Daten in ALKIS) Benutzung (z. B. zur Recherche in den AAA-Daten) Erhebung (zur Erhebung von Daten, die zu Fortführungen benötigt werden bis zur Erstellung des Fortführungsentwurfes) Qualifizierung (Prüfung der Fortführungsentwürfe und Treffen der Fortführungsentscheidung einschließlich des Anstoßes der Fortführung des LDM und der DHK)

10 Geschäftsprozessmodell Hessen Personen- und Bestandsdaten (Steuerung der Übernahme von Fortführungen des Grundbuches einschließlich der ggf. nötigen manuellen Eingriffe). Hierbei zeichnet sich bereits ganz deutlich die konsequente Berücksichtigung des Vier-Augen-Prinzips ab. Dieses kennt zum einen die Datenerhebung, die in vollem Umfang auch von den Vermessungsstellen übernommen werden kann. Auf der anderen Seite wird die Qualifizierung definiert, die ganz konsequent von der Erhebung getrennt und gegen diese abgegrenzt ist. Dieses Prinzip erlaubt es grundsätzlich nicht, dass Erhebungsarbeiten durch den Qualifizierer bearbeitet werden. Vielmehr muss der Qualifizierer einen Fortführungsentwurf an die Erhebung zurückgeben, wenn dieser nicht in das LDM und anschließend in die DHK übernommen werden kann. Die folgende Abbildung verdeutlicht noch einmal die vorstehenden Ausführungen. Sie zeigt die gesamte Prozesskette, vom Nutzen (Lesen) der Bestandsdaten, über die Erhebung - Messen und Erfassen vor Ort, die ggf. folgende häusliche Weiterverarbeitung bis hin zum Fortführungsentwurf. Daran schließt sich die Prüfung des Fortführungsentwurfs mit der Fortführungsentscheidung nach dem 4-Augen-Prinzip (Qualifizierung) und die Überführung des Fortführungsentwurfes in das LDM an. Von dort wird über Nacht die Fortführung der DHK vorgenommen, aus der dann je nach Geschäftsprozess automatisch der Fortführungsnachweis erzeugt wird. Die Freigabe des Fortführungsnachweises einschließlich der Auslösung des Mitteilungsverfahrens erfolgt dann durch das AfB. Zerlegung (Z) Grenzbereinigung (GB) Baulandumlegung (BU) Vereinfachte Umlegung (VBU) Grenzfeststellung (GF) Gebäudeeinmessung (GE) Durch die Erhebungsstelle AfB können des Weiteren noch die Prozessmodelle Flurbereinigung (Liegenschaftskataster) - FB Katastererneuerung - KE Führung Liegenschaftskataster - FL Fortführung der Katasterbuchdaten - FKB, ggf. mit der Ergänzung Verwaltung - W oder Vertretung - T Übernahme von Grundbuchdaten, Sondereigentum UGS Übernahme von Grundbuchdaten,Eigentümer UGE Übernahme von Grundbuchdaten,Grundstücke UGG Übernahme von Grundbuch daten,rechte UGR Übernahme von Grundbuchdaten,Anteile UGA beabeitet werden. 5 Ausblick Abbildung - Prozesskette zur Fortführung von ALKIS 4 Prozessmodelle für ALKIS Die folgende Aufzählung zeigt die zurzeit für ALKIS vorhandenen Geschäftsprozesse mit ihrer Bezeichnung und dem Kürzel. Zunächst werden die Prozessmodelle aufgeführt, die bei allen Erhebungsstellen vorkommen können: Das Geschäftsprozessmodell zur Führung und Aktualisierung von ALKIS kann von seiner Grundphilosophie her auch auf die künftigen Geschäftsprozesse in AFIS, ATKIS und LEFIS sowie auf weitere in der HVBG anfallenden Fachanwendungen (z.b. Wertermittlung, Bodenordnung, Unschädlichkeitszeugnisse) übertragen werden. Damit ist ein weiterer wichtiger Schritt in Bezug auf Standardisierung und Qualitätssicherung der Produkte und Dienstleistungen in der HVBG erreicht. 9

11 Die Vor-Ort-Lösung zu ALKIS Die Vor-Ort-Lösung zu ALKIS Klaus Bischof, Ute Leddin, Volker Merdan, Dorothea Padberg und Ralf Pauly 1 Der AAA-Desktop im Überblick Bereits in der Veröffentlichung,Der AAA-Desktop Hessen (vgl. Pauly - INTERN 2/2005) sind die Rahmenbedingungen und wichtigsten Anforderungen an den AAA-Desktop beschrieben. Die wesentlichen Merkmale aus der Systementscheidung für den AAA-Desktop (vgl. Abbildung 1) sind: Der AAA-Desktop ist das Werkzeug zur Migration der Datenbestände des Liegenschaftskatasters nach ALKIS und der Daten der Grundlagenvermessung nach AFIS. Der AAA-Desktop ist die Komponente zur Benutzung der Daten des AAA-Modells in Verbindung mit der Fortführung des Liegenschaftskatasters in den Prozessschritten,Erhebung und,qualifizierung. Unmittelbar im AAA-Desktop ist ein Lokales Datenmanagement (LDM) zur dauerhaften Speicherung aller ALKIS-Daten eines AfB realisiert. Mit Hilfe des LDM erfolgt in einer Nachtverarbeitung über die Nutzerbezogene Bestandsdatenaktualisierung (NBA) die Aktualisierung der Datenhaltungskomponente (DHK). Seit November 2004 wurden die vorgenannten Bestandteile des AAA-Desktop für die Geobasisdaten ALKIS iterativ auf den heutigen Stand gebracht. Einen wesentlichen Einfluss auf den jeweiligen Fortschritt hatten auch die verschiedenen Versionen der,dokumentation zur Modellierung der Geoinformationen des amtlichen Vermessungswesens, kurz GeoInfoDok (GID). Begonnen wurde bei der Konzeption mit der Version 3.0 und alle darauffolgenden Entwicklungen wurden an die jeweiligen Versionswechsel angepasst bis hin zur heutigen Produktionsversion 5.1.1_K2. Mit dem AAA-Desktop sollen auch die anderen Aufgaben im Zusammenhang mit den Geobasisdaten des AAA-Modells oder darauf basierender Fachmodelle, wie zum Beispiel das Landentwicklungsfachinformationssystem (LEFIS), bearbeitet werden können. Abbildung 1 - Komponenten der DAVID-Familie im Umfeld des AAA-Desktop 10

12 Die Vor-Ort-Lösung zu ALKIS 2 Das Migrationstool Ziel der Migration ist die Übernahme der heutigen Daten des Liegenschaftskatasters, basierend auf dem ALB und der ALK, nach ALKIS. Nach den Probemigrationen aller hessischen Gemarkungen sollen die Ausgangsdatenbestände soweit fehlerbereinigt sein, dass sie in der Produktionsmigration vollautomatisch nach ALKIS überführt werden können. Das Ergebnis der Migration ist ein NAS-Einrichtungsauftrag, der in das jeweilige LDM übernommen und gespeichert wird. Daran schließt sich die Aktualisierung der DHK an. Die erste Probemigration wurde von den ÄfB seit 2006 in den GeoInfoDok-Versionen 3.1 und 4.0 durchgeführt und ist abgeschlossen. Erfahrungen aus den Probemigrationen und weiteren Qualitätssicherungsmaßnahmen im HLBG wurden laufend in die Entwicklung einbezogen. In der Produktionsmigration wird ein vollautomatisierter Ablauf erfolgen. Nachfolgend werden die wichtigsten Migrationsschritte und Besonderheiten beschrieben. Übernahme der Ausgangsdaten Die Daten des ALB-Hessen, kurz ALBi-Daten, werden gemeindeweise in die Oracle-Datenbank eingelesen und dabei unmittelbar in die Struktur des AAA-Modells umgewandelt. Die Migration der Sachdaten und der nicht raumbezogenen Anteile der Flurstücke ist damit abgeschlossen. Danach erfolgt gemarkungsweise die Übernahme der ALK- Grundrissdaten (EDBS-Format) in ein DAVID-Projekt. Zu diesen Daten werden die Informationen aus der,virtuellen Folie 021 (Format SICAD-SQD) importiert. Nach der automatischen Flurbildung werden auch die zugehörigen ALK- Punktdaten (im EDBS-Format) in dieses DAVID-Projekt übernommen. Prüffunktionen für die Ausgangsdaten In diesem Prozessschritt werden vom Bearbeiter verschiedene Prüfungen auf die Ausgangsdatenbestände ausgeführt. Dieser Schritt ist notwendig, damit Restfehler in den Ausgangsdaten, wie z.b. unzulässige Überschneidungen von Linien oder Überdeckungen von Gebäudeobjekten aufgedeckt werden können. Ein besonderes Augenmerk wird auf die Übereinstimmung der Flurstücke im ALB und in der ALK gelegt. Um im folgenden Migrationsablauf Folgefehler zu vermeiden, müssen die Datenbestände bzgl. der vorhandenen Flurstückskennzeichen identisch sein. Automatische Migration In der automatischen Migration sind enthalten: die Ergänzung der Flurstücke aus der Migration des ALB mit den raumbezogenen Informationen, die Migration der Gebäude und Bauteile, die flächendeckende Erzeugung der Objekte der Tatsächlichen Nutzung aus den Informationen der,virtuellen Folie 21 und deren Aggregation (= Zusammenfassung benachbarter Objekte gleicher Objektart und zusätzlich gleicher Abbildung 2 - Automatische Migration Attribute) bis zur Flur und die Migration der öffentlichrechtlichen Festlegungen und der Bodenschätzung. Die Migration wird mit der Überführung der bereitgestellten Punkte der ALK (= Migration der Sollpunkte, ohne abgehende Geometrien) in die entsprechenden ALKIS-Objektarten und der Aggregation der öffentlich-rechtlichen Festlegungen abgeschlossen. Bei der Migration auftretende Fehler werden protokolliert und müssen in der Regel in den Ausgangsdaten behoben werden. Zum Abschluss werden die aus dem ALB migrierten Personen- und Bestandsdaten aus der Oracle-Datenbank dem DAVID-Projekt hinzugefügt. Einrichtungsauftrag erstellen Nach einer fachlichen Plausibilitätsprüfung auf Modellkonformität und Vollständigkeit über alle Projektdaten erfolgt die Ausgabe des Einrichtungsauftrages, noch im alten Koordinatenreferenzsystem (Hessischer Lagestatus 100). Einrichtungsauftrag - bereinigt - erstellen In ALKIS werden Geometrien unterschiedlicher Objektarten redundant gespeichert. Aus diesem Grund werden die vorhandenen,unechten Linienteilungspunkte aus den Objektarten der ALK automatisch entfernt. So werden z.b. Punkte von abgehenden Nutzungsarten- 11

13 Die Vor-Ort-Lösung zu ALKIS grenzen aus den Maschen der Flurstücke gelöscht und sind nur noch Geometriepunkte der Objekte der Tatsächlichen Nutzung. Im Verlauf einer Masche sind auf den Knickpunkten der Masche ausschließlich Grenzpunkte. Auch die richtige Bearbeitung aller Grenzen auf dem Rand der Bezirksgrundstücksdatenbank (BGDB) ist realisiert. Danach erfolgt die erneute Ausgabe des bereinigten Datenbestandes. Hierbei wird dann auch der Wechsel des Lagebezugssystems nach ETRS89_UTM32 mit dem Transformationstool LET-Hessen durchgeführt (vgl. Heckmann,Transformation in das Lagebezugssystem ETRS89/UTM ). Ausblick - Migrationstool In der Produktionsmigration wird das Migrationstool bis zur Ausgabe des Einrichtungsauftrages vollautomatisiert arbeiten. Mit Hilfe von Steuerdateien, die im Wesentlichen organisatorische Inhalte besitzen, ist dann eine bedienerlose Verarbeitung möglich. Der Bearbeiter muss nur noch bei vorher fest definierten Fehlerabbruchszenarien eingreifen und die Ausgabe der Daten manuell starten. Migration AFIS Im Rahmen einer weiteren Fachschale zum DAVID-Expertenplatz wird die Migration der Lagefestpunkte, der Höhenfestpunkte und der Schwerefestpunkte nach AFIS landesweit im HLBG ausgeführt (vgl. Heckmann,Einrichtung und Führung von AFIS ). Die Lageangaben für das Koordinatenreferenzsystem ETRS89_UTM32 stehen dazu bereits in den Quelldatenbanken zur Verfügung und brauchen daher nicht mit LET-Hessen erzeugt werden. 3 Die Erhebungs- und Qualifizierungskomponente (EQK) Begriffe und Definitionen Auf der Basis der von der Unterprojektgruppe (UPG),Geschäftsprozesse erarbeiteten Vorgaben für die Prozesskette zur Fortführung von ALKIS (vgl. Adam -,Geschäftsprozessmodell Hessen ) wurden bzw. werden die Komponenten zur Erhebung der Quelldaten und zur Qualifizierung der Fortführungsdaten entwickelt. Die Erhebung umfasst die Überführung der Quelldaten (= Messdaten unterschiedlichster Herkunft mit der Beschreibung der realen Welt) durch Erfassung, Berechnung, Digitalisierung und andere angebotene Methoden in das Datenverarbeitungssystem und deren Weiterverarbeitung unter Berücksichtigung der Regelwerke zur Aktualisierung des Liegenschaftskatasters. Die Erhebung endet mit dem digitalen Fortführungsentwurf (FE). Die Qualifizierung enthält die Überprüfung und ggf. Ergänzung der Erhebungsdaten, damit diese den Anforderungen an das Liegenschaftskataster entsprechen. Die Qualifizierung ist eine wichtige Methode des Qualitätsmanagements und endet mit der Ausführung des Fortführungsauftrags und der ggf. notwendigen Freigabe des Ergebnisses Fortführungsnachweis. Die Schritte in der Prozesskette werden durch eine angepasste Antragsverwaltung, basierend auf den Projektsteuerungsobjekten des AAA-Modells, begleitet. Eine Kopplung mit dem betriebswirtschaftlichen Abrechnungssystem SAP der Landesverwaltung ist nicht vorhanden. Innerhalb der Anwendung der EQK für ALKIS und insbesondere für die Nutzung des LDM sind verschiedene Rollen vorgesehen. Mit diesen Rollen sind Rechte an der Nutzung der ALKIS-Daten und Berechtigungen zur Fortführung der Daten verbunden. Diese Rollen begleiten die gesamte Prozesskette und sind ggf. auch für andere Applikationen nutzbar. Rolle Benutzung Diese Rolle ist für die Ausgabe von digitalen Bestandsdaten aus dem LDM vorgesehen. Sie besitzt keinerlei Fortführungsberechtigungen für ALKIS. Sie kann für externe Anwendungen mit einem Zugriff über einen WFS-Dienst verwendet werden. 12

14 Die Vor-Ort-Lösung zu ALKIS Rolle,Erhebung In der Rolle,Erhebung ist zunächst die Berechtigung der Rolle,Benutzung enthalten. Zusätzlich können mit dieser Rolle die Antragsobjekte fortgeführt, Reservierungen für Fachkennzeichen vorgenommen sowie geodätische Berechnungen und Veränderungen von fest definierten Objekten durchgeführt werden. Ein Anwender in der Rolle,Erhebung kann nicht die Rolle,Qualifizierung ausüben. Rolle,Qualifizierung Mit der Rolle,Qualifizierung können alle Bestandsdaten benutzt werden, ferner können mit Ausnahme der globalen Katalogdaten alle Objekte fortgeführt werden. Überzählige Reservierungen werden wieder freigegeben. Wesentlich ist auch die Freigabe des Fortführungsnachweises nach einer fehlerfreien Fortführung im LDM und der DHK. Ein Anwender in der Rolle,Qualifizierung kann nicht die Rolle,Erhebung ausüben, kann aber auch die Rolle,Personen- und Bestandsdaten übertragen bekommen. Rolle,Personen- und Bestandsdaten Mit dieser Rolle werden nach einer vorhergehenden Benutzung von Bestandsdaten (vgl. Rolle,Benutzung ) Veränderungen an Personen- und Bestandsdaten aus dem System,SolumSTAR der Grundbuchverwaltung (vgl. Eisenhuth / Padberg,Zusammenarbeit mit der Grundbuchverwaltung ) übernommen und das LDM wird direkt in einem Schritt fortgeführt. Das Liegenschaftskataster führt diese Daten nachrichtlich in Übereinstimmung mit dem Grundbuch als Sekundärnachweis, deshalb entfällt hier die Qualifizierung. Die Rollen werden durch entsprechende Maßnahmen im DV-System umgesetzt und der Benutzer bekommt bei der Anmeldung am System auch nur die ihm zugeordnete(n) Rolle(n) zur Auswahl angeboten. Somit gibt es innerhalb der Anwendung EQK verschiedene Ausprägungen: Erhebungskomponente (EK) für ALKIS: Werkzeuge zur Bearbeitung der Objektartenbereiche Flurstück, Lage, Punkte, Gebäude, Tatsächliche Nutzung, Bauwerke und Sonstige Anlagen, Gesetzliche Festlegungen, Bodenschätzung und ausgewählte Katalogeinträge, Erzeugung des Fortführungsentwurfes (FE), Qualifizierungskomponente (QK) für ALKIS: Übernahme der im Fortführungsentwurf (FE) gespeicherten Daten in die QK, Werkzeuge zur Aggregation von benachbarten Flächen gleicher Tatsächlicher Nutzung und für zugelassene Ergänzungen in der Präsentation (Erscheinungsbild der Karte), die Werkzeuge für Fortführung des LDM und die Beauftragung zur Ausgabe des Fortführungsnachweises sowie der Fortführungsmitteilungen, ALKISbuch: Werkzeuge zur Ergänzung, Korrektur und Fortführung der Personen- und Bestandsdaten, die aus den Schnittstellendaten der Grundbuchverwaltung übernommen wurden. Allen drei Ausprägungen ist eine Antrags- und Projektverwaltung inklusive steuerung, sowie Werkzeuge zur Benutzung und Präsentation der ALKIS-Bestandsdaten vorgeschaltet. Benutzung und Vorbereitung In den Rollen Erhebung und Qualifizierung beginnt die Prozesskette mit der Selektion aus den vorhandenen Bestandsdaten, der sogenannten Projektvorbereitung. Mit Hilfe von geometrischen Selektionsmöglichkeiten (Navigation mit WMS-Dienst, Eingabe von Koordinatenfenstern, Hochladen von XML-Dateien) oder fachlichen Auswahlkriterien (Suche nach Flurstück(en), Objekten mit bestimmten Kennzeichen) werden Selektionen in den Daten ausgeführt und anschließend in einem Grafikfenster präsentiert. Neben der Möglichkeit, weitere Selektionen auszuführen, um z.b. das zu bearbeitende Gebiet räumlich genauer abzugrenzen, wird hier auch die Überführung des Selektionsergebnisses in ein DAVID-Projekt zur späteren Bearbeitung angeboten. 13

15 Die Vor-Ort-Lösung zu ALKIS Antragsverwaltung und Prozesssteuerung Für die Prozessmodelle (vgl. Adam,Geschäftsprozessmodell Hessen ) wurde eine softwaretechnische Unterstützung entwickelt. Mit der Auswahl des Prozessmodells wird gleichzeitig der (identische) Hauptanlass der späteren Fortführung bestimmt (siehe Abbildung 3). Abbildung 3 - Benutzung, Antragsverwaltung und Antragskennzeichen 14

16 Die Vor-Ort-Lösung zu ALKIS Sollen innerhalb des Prozesses noch andere Aufgaben mit erledigt werden, so können jederzeit weitere Anlässe (= Werkzeugkästen) dem bestehenden Prozessmodell hinzugefügt werden. Allerdings gibt es dabei gewisse fachliche Beschränkungen, da bestimmte Anlässe nicht miteinander kombiniert werden sollen (vgl. Abbildung 4). Abbildung 4 - Zusammenstellung der Anlässe (Werkzeugkästen) Für alle Anträge wird nach festen Regeln ein Kennzeichen vergeben. Das Antragskennzeichen setzt sich zusammen aus den Informationen,Gemarkungsnummer (in der die Fortführung stattfindet),,kürzel für den Geschäftsprozess (ggf. ergänzt um die Kennung,beigebracht ),,Geschäftsbuchnummer (aus der SAP-Anwendung) und,name des Erhebungsprojektes (für DAVID). Neben diesem Kennzeichen wird für jeden Antrag auch die geometrische Abgrenzung des Antrages in Form des Antragsgebietes bestimmt. Das Antragsgebiet, das Antragskennzeichen und ein automatisch aus dem Fortschritt des Prozesses abgeleiteter,bearbeitungsstatus dienen in der Antragsverwaltung als Informationsquelle zu den aktuellen Fortführungsaktivitäten in der betroffenen Gemarkung. Mit Hilfe einer Checkliste werden die Vorgänge innerhalb der Prozesskette überwacht. Die Angaben Antrag, Antragsgebiet, Vorgang und Meilenstein zum Vorgang bzw. zum Antrag werden in den Objektarten des Basisschemas gespeichert. Für die Geschäftsfälle in der Rolle,Personen- und Bestandsdaten werden keine Anträge erfasst, aber die Fortführungsaktivitäten werden Hauptanlässen zugeordnet, die dann wiederum durch fest definierte weitere Anlässe ergänzt werden können. Diese Zusammenhänge werden innerhalb eines DAVID-Projektes verwaltet. Nach der Fortführung wird eine nach statistischen Merkmalen auswertbare Tabelle über die Geschäftsfälle aktualisiert. 15

17 Die Vor-Ort-Lösung zu ALKIS DAVID-Projekte Nach dem Start des DAVID- Projektes werden entweder die im Laufe der Vorbereitung bestimmten Gebiete per Benutzungsauftrag aktuell aus dem LDM geladen, oder man setzt die Bearbeitung auf dem letzten Stand des Projektes fort. Der Anwender erhält ein auf seine Situation abgestimmtes Menü, mit vielen allgemeinen Funktionen rund um die Bedienung des Systems. Mit Hilfe der Menüs können Voreinstellungen, wie beispielsweise die Größe des Fangkreises für die Selektion von Objekten in der Grafik, geändert werden. Außerdem kann zwischen verschiedenen Präsentationen wie,standard,,bearbeitung oder,nutzung Verkehr gewählt werden. Als Standardpräsentation ist die AdV-Standardausgabe,Liegenschaftskarte eingestellt. Neben den Menüs bietet DAVID die Möglichkeit, mit Symbolleisten zu arbeiten. Automatisch ist hier auch eine auf die Rolle bezogene Basis-Symbolleiste eingeblendet. Auf den Menüs der rechten Maustaste liegen die Funktionen zur Veränderung des Bildausschnittes, zum Vergrößern und Verkleinern der Darstellung sowie Funktionen zur Auswahl von Objektinformationen. Abbildung 5 - Standardpräsentation mit den aktivierten Werkzeugen Durch Aktivieren der Antragssteuerung bzw. verwaltung kann der gespeicherte Antrag gewählt werden. Hier stehen Werkzeuge zur Ergänzung der Anlässe, zur Reservierung von Fachkennzeichen (Punktnummer, Flurstücksnummer und Fortführungsnachweisnummer), zur Anzeige und Bearbeitung des Antragsstatus, zum Exportieren an das LDM, zum Versenden an eine antragstellende Vermessungsstelle und zum Schließen des Antrages zur Verfügung. 16

18 Die Vor-Ort-Lösung zu ALKIS 4 Erhebung Prozesse und Werkzeuge Die Funktion,Antrag bearbeiten in der Antragsverwaltung schaltet die zum aktuellen Antrag gewählten Anlässe und damit die Werkzeugkisten in Form jeweils einer Symbolleiste frei. Der Anwender kann diese Symbolleisten innerhalb des Programmfensters frei anordnen. Neben den gewählten Anlässen ist immer die Symbolleiste für die Ausführung der geodätischen Berechnungen mit VPR aktiv. Symbolleisten und Werkzeuge Die Symbolleisten sind immer nach dem gleichen Schema aufgebaut. Von links beginnend stehen die Funktionalitäten: Navigation der Symbolleisten dient zum Wechsel zwischen den Werkzeugen, ähnlich den Möglichkeiten einer Browsernavigation mit den Schaltflächen für Vor (Nächster Werkzeugkasten),,Home (Hauptanlass oder Basis) und Zurück (Vorheriger Werkzeugkasten). Bildveränderung dient der Veränderung und Verschiebung des Bildausschnittes, dem Vergrößern und Verkleinern des Bildes. Sie ist identisch mit der Belegung der rechten Maustaste, aber wichtig für Systeme ohne Möglichkeit der Anwendung der rechten Maustaste z.b. Systeme mit Touch-Screen-Bedienung. Punktobjekte ermöglicht das Einfügen, Lösen und Löschen von Punktobjekten in oder aus vorhandenen sonstigen Geometrieobjekten. Digitalisierung dient der Erhebung der Geometrieverläufe durch Kopieren von vorhandenen Geometrien, Identifizieren von Linienverfolgern und der freien Digitalisierung mit und ohne Berücksichtigung von Punkten (je nach Anlass). Objektbildung (NEU) dient der Bildung neuer Objekte. Objektbearbeitung ermöglicht die Korrektur (inkl. Löschen) und Aktualisierung vorhandener Objekte, insbesondere die Bearbeitung einzelner Attribute der Objekte. Präsentationsobjekte ermöglicht die Erhebung und Korrektur (inkl. Löschen) von Präsentationsobjekten zu den bereits vorhandenen Fachobjekten, sofern ein Präsentationsobjekt zulässig ist. Prüffunktionen feste Prüffunktionen, die sowohl in der Erhebung als auch in der Qualifizierung durchgeführt werden können. Sofern eine der Kategorien nicht benötigt wird, ist diese aus den Symbolleisten entfernt, die restlichen rücken nach links auf. Zerlegung eines Flurstücks Beispielhaft werden hier die Prozessschritte für die Zerlegung eines Flurstücks in zwei Teilstücke beschrieben. Reservierung von Punktkennzeichen für neue Grenzpunkte Mit Hilfe des Bildausschnittes um das zu zerlegende Flurstück wird das Gauß-Krüger-Kilometerquadrat (im Hessischen Lagestatus 100) ermittelt, in dem die neuen Grenzpunkte liegen. Intern erfolgt über die Näherungsformeln zur Umrechnung von ETRS89_UTM32-Koordinaten eine Lagerung des Gebietes im Koordinatenreferenzsystem DE_DHDN_3GK3_HE100. Die gewünschte Anzahl von Nummern für das Kilometerquadrat wird eingegeben, ein Reservierungsauftrag wird erstellt und das Reservierungsergebnis wird angezeigt. Reservierung von Flurstücksnummern für zwei Teilstücke Die Reservierung erfolgt entweder als Folgenummern zur Stammnummer des alten Flurstücks (Reservierung von Flurstücknennern) oder als neue Stammnummern (Reservierung von Flurstückszählern). Dazu wird die gewünschte Anzahl eingegeben und pro Nummerierungsbezirk ein Reservierungsauftrag erstellt. Das Reservierungsergebnis wird angezeigt. Bestimmung der Grenzpunkte Mit Hilfe der geodätischen Berechnungen in VPR werden die Koordinaten und die Qualitätsangaben der Punktorte berechnet und die Grenzpunkte gebildet. Es entstehen neue Punktobjekte, die aber in diesem Schritt bezüglich des Geometrieverlaufs der vorhandenen Flurstücksgrenzen noch keine Änderung bewirken. Behandlung der Punktobjekte Damit neue Flurstücke gebildet werden können, müssen die neuen Grenzpunkte die vorhandenen Flurstücksgrenzen,auftrennen. Die Grenzpunkte werden ausgewählt und der Geometrieverlauf wird über die neuen Grenzpunkte geführt. Dies gilt für alle beteiligten Flurstücke. Auf gleiche Weise können Grenzpunkte aber auch aus dem Geometrieverlauf zunächst gelöst und ggf. auch endgültig gelöscht werden. 17

19 Die Vor-Ort-Lösung zu ALKIS Digitalisierung des neuen Grenzverlaufes Neben der geradlinigen Verbindung zwischen zwei Grenzpunkten können auch kreisbogenförmige Verbindungsgeometrien digitalisiert werden. Objektbildung erstes neues Flurstück Mit einem Klick in die zu erzeugende Masche wird ein Prozess gestartet, der nacheinander das alte Flurstück als,historisch markiert, das zugehörige Präsentationsobjekt,Flurstücksnummer in anderer Weise präsentiert, die vorhandenen Flurstücksgeometrien und die neuen Grenzen zu einem Objekt zusammenfügt und vom Anwender die Auswahl des zu vergebenden Flurstückskennzeichens verlangt. bzw. einzelne Aktionen nicht ausgeführt (z.b. Historisieren des zu zerlegenden Flurstücks). Wenn alle neuen Flurstücke über der alten Fläche gebildet sind, entfällt auch die Markierung der,lücke im Datenbestand. Nach der Beendigung der Prozedur sind die Reservierungen als,benutzt gekennzeichnet und können nicht erneut verwendet werden. An den neuen Objekten können, je nach Situation, noch Ergänzungen in den Attributen vorgenommen werden. Es können über andere Anlässe noch weitere Veränderungen am Datenbestand ausgeführt werden, z. B. können über den Werkzeugkasten zur Lagebearbeitung die Relationen der Lage bearbeitet werden. Im Hintergrund ist bereits eine Flächenberechnung inkl. einer Qualitätsbetrachtung nach der neuen Richtlinie zur Flächenberechnung ausgeführt worden, und die Ergebnisse werden zur Auswahl angezeigt. Der Anwender muss dann noch über den Inhalt des Attributes,Amtliche Fläche entscheiden. Alle Relationen des alten Flurstücks (z. B. zur Lage, zum Eigentümer) werden zunächst auf das neue Flurstück übernommen. Mit der Bestätigung für die Objektbildung wird das Präsentationsobjekt,Flurstücksnummer an die Stelle gesetzt, an der das neue Flurstück zu Beginn des Prozesses markiert wurde. Die verbleibende Restfläche wird als,lücke markiert. 18 Objektbildung zweites neues Flurstück In der gleichen Weise wie im vorhergehenden Prozessschritt wird das zweite Flurstück gebildet. Dabei werden Entscheidungen aus dem ersten Schritt als Vorbelegung übernommen

20 Die Vor-Ort-Lösung zu ALKIS Abbildung 6 - Zerlegtes Flurstück und Objektbearbeitung Im Hintergrund wurde bereits der Fortführungsnachweis angelegt und die Daten für den aktuellen Fortführungsfall gesammelt. Danach können noch Prüfungen ausgeführt werden, die die Validierung des Datenbestandes sicherstellen. Die Erhebungsarbeiten werden mit der Erstellung des Fortführungsentwurfs und der Bereitstellung weiterer Unterlagen (Datei der benutzten Anschlusspunkte, grafische Darstellung des Fortführungsentwurfs) für die Qualifizierung abgeschlossen. Geodätische Berechnungen Die geodätischen Berechnungen können jederzeit im Erhebungsprozess mit den entsprechenden Berechnungsprogrammen u. a. für Orthogonalaufnahme, Polaraufnahme, Freie Stationierung, Schnittberechnungen ausgeführt werden. Zur Auswahl von Punkten kann auch auf die Unterstützung der Grafik zurückgegriffen werden. Die neuen, veränderten und gelöschten Punkte werden direkt in der Grafik nachgeführt und je nach fachlicher Bedeutung der Objekte wird der vorhandene Geometrieverlauf automatisch nachgeführt oder digitalisiert. Abbildung 7 - Punkt speichern, hier nach Punktsuche 19

21 Die Vor-Ort-Lösung zu ALKIS Die Katasterpunkte gehören im AAA-Modell zur Klasse,Zusammengesetztes Objekt (ZUSO). Dies bedeutet, dass neben dem Punktobjekt, wie beispielsweise dem Grenzpunkt, auch ein oder mehrere Objekte für die Daten des Raumbezuges, d. h. für die Lage- und Höhenangaben, erzeugt werden. Dabei bildet jeder Raumbezug, getrennt nach dem gewählten Koordinatenreferenzsystem, ein eigenes Objekt Punktort (wie bereits in den Datengruppen der Katasterpunktdatei). An die Punktorte sind folgende Bedingungen geknüpft: 20 Mit der Erhebung der Koordinaten wird auch eine Qualitätseinstufung ausgeführt. Die Ergebnisse finden sich in den Attributen,Herkunft,,Genauigkeitsstufe und,vertrauenswürdigkeit wieder. Die Vorgaben aus der neuen Liegenschaftsdatenerhebungsanweisung (LEA) werden automatisch umgesetzt und dem Anwender angezeigt. Die einzelnen Berechnungsansätze werden in einer Stapeldatei zur wiederholten Berechnung gespeichert. Außerdem werden entsprechende Protokolldateien über den Ablauf der Berechnung geführt. Koordinatenverzeichnisse können nach eigenen Selektionskriterien zu jedem Zeitpunkt ausgegeben werden. Mit der Einführung neuer Koordinaten, z.b. aus einer Verbesserung der vorhandenen Punktorte, werden die Daten für einen Koordinatenaustausch mit ggf. anschließender Homogenisierung (Nachbarschaftsanpassung durch Interpolation der Verschiebungsvektoren) gesammelt und können mit dem Werkzeug- kasten,homogenisierung bearbeitet werden. Homogenisierung Der Ablauf eines Koordinatenaustausches bzw. einer Homogenisierung gestaltet sich wie folgt: Festlegen des Homogenisierungsgebietes durch Digitalisierung eines Umrings. Bilden des Objektes,Homogenisierungsgebiet, wobei auch die Art der Homogenisierung festzulegen ist. Dabei stehen die Varianten,Koordinatenaustausch ohne Nachbarschaftsanpassung oder,koordinatenaustausch mit Nachbarschaftsanpassung zur Auswahl. Bei der Entscheidung mit Nachbarschaftsanpassung stehen mehrere Interpolationsmethoden zur Verfügung (verschiedene Abstandsgewichte oder,kleinste Quadrate ). Automatische Sollpunktzuweisung für das Homogenisierungsgebiet, ggf. ergänzt durch manuelle Auswahl von Punkten. Erschnüffelung der verschiedenen Bedingungen in den Geometrien (Geradheit, Parallelität, Abstand gleich NULL u. a.). Verteilung der Verschiebungsvektoren in den Stützpunkten auf benachbarte abhängige Grundrisspunkte und Wiederherstellen der geometrischen Bedingungen. Zur Beurteilung des Ergebnisses werden der Vektorenplan und die Bedingungen präsentiert, die Homogenisierung kann danach übernommen oder verworfen werden. Zur Übergabe an die Qualifizierung und zur späteren Abgabe an die Kunden wird das Homogenisierungsgebiet gemeinsam mit den Verschiebevektoren in XML-Dateien (mit eigenem Schema) überführt. Die Ergebnisse werden dauerhaft in der Datenbank gespeichert.

22 Die Vor-Ort-Lösung zu ALKIS Abbildung 8 - Homogenisierungsgebiet und Vektorenplan DAVID-Feldsystem Ergänzung der Erhebungskomponente für den Außendienst Das DAVID-Feldsystem und die Erhebungs- und Qualifizierungskomponente (EQK) bauen auf der gleichen DAVID-Basissoftware auf. Sie haben die gleichen Datenstrukturen und identische Funktionalitäten. Mit dem DAVID-Feldsystem ist die Erhebung der geometrischen Liegenschaftsobjekte und ihrer Attribute vor Ort (im Außendienst) innerhalb des Erhebungsprozesses sichergestellt. Es ist jederzeit der Zugriff auf die beiden Benutzeroberflächen (EK für ALKIS und DAVID-Feld für ALKIS) möglich. Der Datenaustausch zwischen den beiden Erhebungssystemen erfolgt über Projektdateien, ohne jegliche Datenkonvertierung und Informationsverluste. Im Gegensatz zur Serverlösung der EQK handelt es sich hierbei um eine Einzelplatzinstallation auf einem Tablet-PC. Das DAVID-Feldsystem enthält gegenüber der Serverlösung zusätzlich die für den Außendienst wichtigen Funktionalitäten wie die Anbindung und Ansteuerung von Tachymetersystemen (TPS) oder GPS-Empfängern, sowie die Auswertung der Messungsergebnisse oder Koordinatenberechnungen. Durch diese Kopplung ist es möglich, neue Positionen vor Ort zu erzeugen. Mit der aus VPR bekannten Speichermaske für Fachobjekt und Punktort (vgl. Abbildung 7) entstehen die Katasterpunkte (ZUSO + REO). Durch die Umschaltung der Benutzeroberfläche in den Erhebungssystemen kann die Prozesskette,Erhebung auf zwei verschiedenen Wegen beschritten werden: 21

23 Die Vor-Ort-Lösung zu ALKIS Die bearbeiteten Punkte können mit Linien, jeweils in ihren entsprechenden Fachbedeutungen, verbunden und mit Texten ergänzt werden. Anschließend werden die Projektdaten für den weiteren Erhebungsprozess an den Innendienst (EQK) abgegeben. Hier erfolgt die weitere Bearbeitung im Erhebungsprozess. alternativ: Mittels Umschaltung auf die EQK kann der weitere Erhebungsprozess bis einschließlich der Erstellung des Fortführungsentwurfs direkt vom Außendienst auf dem Tablet-PC weiterbearbeitet werden. Abbildung 9 - Das DAVID-Feldsystem Das DAVID-Feldsystem bietet somit alle Möglichkeiten zur effizienten Erhebung von Liegenschaftsdaten im Außendienst. 22

24 Die Vor-Ort-Lösung zu ALKIS 5 Qualifizierung Prozesse und Werkzeuge Zum Abschluss der Erhebung werden die Arbeitsergebnisse der Bearbeitung gemeinsam mit weiteren Dateien in einem ZIP-Archiv auf dem Datenaustauschverzeichnis abgelegt. Die Qualifizierung kann von autorisierten Bearbeitern mit der gleichnamigen Rolle ausgewählt werden. Ähnlich wie bei der Erhebung hat der Bearbeiter die Möglichkeit, in den Bestandsdaten zu recherchieren. Dies ist aber nicht die Hauptaufgabe der Qualifizierung. Neben den Standardfunktionen der Vorbereitung kann hier auf die ZIP-Archive (beinhalten u. a. die Fortführungsentwürfe) im Datenaustauschverzeichnis zurückgegriffen werden. Nach der Auswahl eines Archives wird ein neues Projekt im Datenverzeichnis,Qualifizierung eingerichtet, das ZIP-Archiv extrahiert und die enthaltenen Daten automatisch importiert. Die Antragsobjekte werden aus dem LDM importiert, für die in der Erhebung als,fortgeführt gekennzeichneten Objekte werden die zugehörigen Bestandsdaten über ein geometrisches Selektionskriterium als Benutzungsauftrag an das LDM gestartet und das Ergebnis importiert. Dabei werden automatisch einzelne DV-technische und modellintegrierte Prüfungen durchgeführt, ein wesentlicher Punkt hierbei ist die Aktualitätsprüfung der benutzten Bestandsdaten. Anschließend erfolgt eine visuelle Prüfung der Erhebungsdaten anhand verschiedener Präsentationen, in denen die Veränderungen besonders hervorgehoben sind. Es werden Verschneidungen durchgeführt, um die noch vorhandenen Migrationsattribute (,Sonstige Eigenschaften ) und Migrationsobjekte (,Gebäudeausgestaltung und Topographische Linie ) zu überprüfen und aufzulösen. Außerdem wird die Vollständigkeit der Objekte,Georeferenzierte Gebäudeadresse geprüft und ggf. automatisch ergänzt. Zur synergetischen Nutzung der Daten aus dem Erhebungsprozess auch für ATKIS (vgl. Limmert/Kullmann/Friehl -,Synergien zwischen ALKIS und ATKIS im AAA-Modell ) werden die Gebäude grundsätzlich nur noch im Liegenschaftskataster erhoben und dann für die Geotopograhie (ATKIS Modellartenkennung Basis-DLM ) nutzbar gemacht. Dies bedeutet, dass Gebäude mit bestimmten Gebäudefunktionen oder sonstigen für ATKIS relevanten Attributen (,Hochhaus oder auch,unterirdisch ), aber auch alle Gebäude mit einer Grundfläche größer 50 m², die Modellartenkennungen,DLKM und,basis-dlm tragen. Fehlende Daten werden nach einem entsprechenden Hinweis ergänzt. In der Qualifizierung können noch,kosmetische Veränderungen an den Daten ausgeführt werden, z. B. an der Lage von Präsentationsobjekten. Ebenso können Aggregationen von benachbarten Flächen mit identischer Tatsächlicher Nutzung vorgenommen werden. Wesentliches Ergebnis der Qualifizierung ist die Fortführungsentscheidung. Diese führt zur Aktualisierung des LDM und im Rahmen des NBA- Verfahrens zur Fortführung des Liegenschaftskatasters in der DHK. Für die Fortführungsentscheidung wurden auch bereits alle Daten zur Erzeugung des Fortführungsnachweises (FN) sowie der benötigten Fortführungsmitteilungen (FM) gesammelt. Der hierzu gehörige grafische Nachweis kann dabei durch gezielte Auswahl manuell erzeugt oder automatisch abgeleitet werden. Blattformate, Blattausrichtung und Maßstab sind dabei auswählbar. Sobald die DHK durch das LDM fortgeführt ist und die DHK eine positive Quittung zurückgegeben hat, kann die Freigabe des Fortführungsnachweises durch den Qualifizierer erfolgen. Außerhalb der Erhebung und Qualifizierung werden die Produkte,FN-Hessen und,fm- Hessen noch in Papierform gebracht, für den Versand vorbereitet und die Dokumentation in der Verfahrensakte in die Wege geleitet. 6 ALKISbuch Für die Fortführung der Personen- und Bestandsdaten des Liegenschaftskatasters wird die Benutzeroberfläche ALKISbuch als Teil der EQK eingesetzt. Hiermit können Veränderungslisten des Grundbuchs, die nicht automatisiert übernommen werden konnten, nachbearbeitet werden oder Korrekturen, die aufgrund der Nichtübereinstimmung von Grundbuch und Liegenschaftskataster vorhanden sind, bereinigt werden. Dem Bearbeiter steht hierbei immer ein DAVID-Projekt zur Verfügung. Das Projekt wird automatisch nach der Auswahl der Anwendung aus der CITRIX- Farm gestartet. Die Grundlage für die Bearbeitungswerkzeuge und die Steuerung bildet auch hier der DAVID-Expertenplatz, für den eine nur auf diese Aufgabe abgestimmte Benutzeroberfläche entwickelt wurde. 23

25 Die Vor-Ort-Lösung zu ALKIS Daher werden an dieser Stelle auch keine Bearbeitungswerkzeuge für das Editieren von raumbezogenen Objekten zur Auswahl angeboten. Dazu stehen die Geschäftsprozesse,Veränderung der Verwaltung,,Veränderung der Vertretung,,Beschreibung der Buchungsstelle ändern,,angaben zu Eigentümern oder Erbbauberechtigten verändern,,grundstücke buchen,,rechte buchen und,anteile buchen zur Verfügung. Diese Geschäftsprozesse haben alle einen ähnlichen Ablauf: ein vorhandenes Objekt, das bearbeitet werden soll, wird anhand seines Fachkennzeichens (Flurstückskennzeichen oder Buchungsblattkennzeichen oder Buchungsblattkennzeichen + Buchungsstelle) gesucht, die zugehörige Buchung wird in einem Übersichtsfenster (vgl. Abbildung 10) dargestellt, wobei hier zusätzlich die auf den einzelnen Objekten ausführbaren Funktionen zum Anlegen neuer Objekte, Ändern oder Löschen vorhandener Objekte, aktiv sind, die einzelnen Objekte können in den jeweils auf das Objekt abgestimmten Bearbeitungsfenstern geändert und gespeichert werden, wenn das Übersichtsfenster (die Buchung) den neuesten Stand darstellt, wird dieses beendet, parallel dazu werden Plausibilitätskontrollen auf die komplette Buchung ausgeführt und ein Fortführungsauftrag erstellt und direkt in das LDM übernommen, anschließend werden Statistiken gepflegt und das Projekt für die nächste Bearbeitung neu initialisiert. Für Veränderungslisten, die nicht durch das albesas-verfahren (vgl. Eisenhuth/Padberg,Zusammenarbeit mit der Grundbuchverwaltung ) übernommen werden konnten, sind die gleichen Prozessschritte zu durchlaufen. Es entfällt hierbei jedoch das Suchen der Objekte anhand des Kennzeichens und die Auswahl des Geschäftsprozesses. Die aktualisierten Daten werden durch den nicht erfolgreich ausgeführten Fortführungsauftrag in ALKISbuch übernommen und weiterbearbeitet. 24 Abbildung 10 - Arbeitsumgebung von ALKISbuch

26 Die Vor-Ort-Lösung zu ALKIS 7 Lokales Datenmanagement Das Lokale Datenmanagement (LDM) wird für die meisten Bearbeiter nicht unmittelbar spürbar sein, schon gar nicht sichtbar. Es besitzt aber die fundamentale Rolle, alle Aufgaben der Fortführung, die zu Veränderungen an den Daten des Liegenschaftskatasters führen, zeitlich lückenlos und qualitativ vollständig nachzuvollziehen und benutzbar zu machen. Die Kommunikation von und zum LDM erfolgt immer auf der Basis der NAS, unter Nutzung einer eingerichteten http-call-schnittstelle zwischen den Komponenten (vgl. Abbildung 1). Alle Änderungen an den AAA- Bestandsdaten werden am Ende jeden Tages mit Hilfe des NBA-Verfahrens über den Zeitstempel der Aktualisierung an die DHK abgegeben, dort übernommen und das Ergebnis der Übernahme wird von dort quittiert. Nur positive Quittierungen erlauben die Ausgabe weiterer Änderungen am folgenden Tag. Aus dem LDM werden auch die Fortführungssätze für die Grundbuchverwaltung in der Form des WLDG-GB (vgl. Eisenhuth/Padberg Zusammenarbeit mit der Grundbuchverwaltung) ausgegeben und anschließend per Transferverfahren zentral an die Server der Justizverwaltung übermittelt. Neben den AAA-Bestandsdaten nimmt das LDM auch die Homogenisierungsergebnisse auf und kann ebenfalls über das NBA-Verfahren diese Daten in bestimmten Zeitintervallen an die interessierten Kunden ausgeben. Es ist beabsichtigt, in diesem LDM auch die Daten des LEFIS, des,schwesterverfahrens zu ALKIS in der Flurbereinigung, aufzunehmen. 8 Ausblick Für die Produktionsmigration wird die,bedienerlose Variante bereitgestellt. Es werden auch noch Methoden entwickelt, eine möglichst unterbrechungsfreie Übernahme der Einrichtungsaufträge sicherzustellen. Für die Übernahme der Fortführungsdaten von der Grundbuchverwaltung wird als Basiswerkzeug das Verfahren,aLBESAS mit der Kernkomponente,LBESAS-Konverter eingesetzt. Durch das ALKISbuch wird dieses Verfahren für die besonderen Anwendungsfälle ergänzt, die nicht für eine automatisierte Übernahme geeignet sind. Die Entwicklung des AAA- Desktops entstammt einer,gemeinschaftsproduktion aus vielen Experten der HVBG, anderer Verwaltungen sowie der Fa. ibr. Besonders hervorheben möchten wir dabei Herrn Dr. Köster, ibr-projektleiter für den AAA-Desktop, der mit seiner Professionalität die Zielerreichung immer positiv beeinflusst hat. Die EQK wird in einer hohen Qualität in Produktion gehen. Der Entwicklungsstand umfasst dann die 1. Stufe des AAA-Desktops. Weitere Funktionalitäten stehen bereits jetzt schon für die Entwicklung der 2. Stufe nach Produktionsbeginn fest. Dabei können auch weitere Optimierungen vorgenommen werden, die dann bereits auf den praktischen Erfahrungen der ÄfB mit der 1. Stufe beruhen. 25

27 Zusammenarbeit mit der Grundbuchverwaltung Zusammenarbeit mit der Grundbuchverwaltung Klaus Eisenhuth, Dorothea Padberg 26 1 Rechtliche Voraussetzungen Die rechtliche Voraussetzung für die Zusammenarbeit mit der Grundbuchverwaltung ist in 9 Abs. 2 Hessisches Vermessungs- und Geoinformationsgesetz (HVGG) geregelt. Das Liegenschaftskataster ist amtliches Verzeichnis nach 2 Abs. 2 der Grundbuchordnung (GBO), in der Fassung vom 26. Mai 1994 (BGBl. I S. 1115), zuletzt geändert durch Gesetz vom 19. April 2006 (BGBl. I S. 866). Es wird mit dem Grundbuch hinsichtlich der gemeinsamen Informationsinhalte dauernd in Übereinstimmung gehalten. 2 Der Auftrag Für den Lenkungsausschuss des Projekts,Einheitliche Bodenmanagementbehörde, Geoinfrastruktur Hessen hat die Projektgruppe 1,Fachliche Zusammenführung im Jahre 2004 den Datenaustausch Grundbuch/ALKIS untersucht. Diese Untersuchung ergab zwei Möglichkeiten: Einsatz einer vorhandenen, auch in den anderen Bundesländern praktizierten Verfahrenslösung oder eine neu zu realisierende Lösung. Anfang des Jahres 2005 beschloss der Kabinettsausschuss,Verwaltungsreform und Verwaltungsinformatik, dass die vorhandene Lösung zu realisieren ist. Die notwendige Software wurde durch das HMdJ und die HVBG beschafft und wird nun mit Pilotsystemen getestet. Ende des Jahres 2008 sollen die Ministerien dem Kabinettsausschuss über den Betrieb berichten. 3 Sachstand Die Grundbuchblätter sind hessenweit gescannt und liegen bei der HZD Außenstelle Hünfeld - vor. Zur Suche nach Flurstücken, Lagebezeichnungen und Eigentümern ist eine Datenbank mit den Daten des ALB-Hessen befüllt und an die Bedürfnisse der Amtsgerichte angepasst worden. Eine Aktualisierung erfolgt über die ALBi-Schnittstelle. Die Auswertung der Datenbank geschieht über die Flurstücks- und Eigentümerrecherche (F&E-Recherche). Die gescannten Grundbuchblätter und die F&E-Recherche bilden das Elektronische Grundbuch (EGB) und werden über das Programmsystem SolumSTAR von den Amtsgerichten gepflegt. Der Inhalt der Grundbuchblätter stimmt nicht immer mit den Daten der F&E-Recherche überein, da z.b. die Pseudonummern der Bestandsverzeichnisnummern des ALB-Hessen hier eingespeist wurden. Die mit SolumSTAR vorgenommenen Änderungen werden aber nicht über eine Schnittstelle automatisiert an das ALB-Hessen übergeben. 4 Entwicklung der Schnittstellen LBESAS und WLDG-GB Auf Bundesebene ist ein ALB entwickelt worden, dass bei einigen Bundesländern (z.b. Rheinland-Pfalz, Niedersachsen, Baden-Württemberg) eingesetzt und über Fortführungsarten im Batchverfahren aktualisiert wird. Aus diesen Fortführungsarten sind die Schnittstellen LBESAS (Liegenschaftsbuch Eingabesätze Auftragsbuch Sequentiell) und WLDG-GB (Workdatei Liegenschaftsbuch Daten-Gewinnung Grundbuch) entwickelt worden. Die LBESAS-Schnittstelle übermittelt vom Amtsgericht veränderte Bestands- und Eigentumsangaben (Eingabeschnittstelle) an die Ämter für Bodenmanagement. Die WLDG-GB-Schnittstelle übermittelt katastertechnische Änderungen im Bereich der Flurstücksangaben (Ausgabeschnittstelle) an die Amtsgerichte. Über diese Schnittstellen werden heute schon in Rheinland- Pfalz und Niedersachsen die im Grundbuch und Kataster veränderten Daten automatisiert ausgetauscht. 5 Folgen aus der Entwicklung der Schnittstellen Aus dieser Entwicklung heraus ist erkennbar, dass SolumSTAR

28 Zusammenarbeit mit der Grundbuchverwaltung und die Schnittstellen keine objektorientierten Strukturen analog zu ALKIS haben. Es gibt lediglich drei gemeinsame eindeutige Kennzeichen: Buchungsblattkennzeichen Buchungsblattkennzeichen + Buchungsstelle Flurstückskennzeichen So wird z. B. bei einer Eigentumsänderung mit dem Buchungsblattkennzeichen das Objekt Buchungsblatt gesucht und alle abhängigen Objekte Namensnummer, Person, Anschrift, Vertretung und ggf. auch Personengruppe gelöscht und mit den vom Grundbuch gelieferten Daten neu angelegt. Dies ist erforderlich, da es keine eindeutigen identifizierenden Eigenschaften für diese Objekte gibt. Auch soll hierdurch eine möglichst schnelle Übereinstimmung mit den Daten des Grundbuchs erreicht werden. 6 Der Datenaustausch ALKIS/SolumSTAR Abbildung 1 Schematische Darstellung - Datenaustausch Die im Elektronischen Grundbuch veränderten Bestandsund Eigentümerangaben werden in ein LBESAS-Format ausgegeben. Diese werden durch den NAS-Konverter in Fortführungsaufträge umgewandelt und in ALKIS eingelesen. Die Verarbeitung wird protokolliert und kann für statistische Zwecke genutzt werden. Veränderungen der Flurstücksangaben in ALKIS werden durch einen Konverter in das WLDG-GB-Schnittstellenformat umgewandelt und an das Elektronische Grundbuch übergeben. Schnittstelle vom Grundbuch zum AfB Pro AfB werden täglich durch die HZD in Hünfeld alle von den Amtsgerichten im Elektronischen Grundbuch veränderten Bestands- und Eigentümerdaten in einer LBESAS- Datei bereitgestellt. Diese Datei holt sich das örtliche AfB auf seinen eigenen File-Server. Sie wird anschließend in die Daten der einzelnen Amtsgerichte aufgesplittet, damit eine parallele Verarbeitung von Korrekturen erfolgen kann. Jede Änderungsdatei eines Amtsgerichtes enthält beliebig viele Fortführungsfälle, die zur weiteren Verarbeitung an den NAS-Konverter weitergereicht werden. Ein Fortführungsfall wird mit einer so genannten Fortführungsart beschrieben. Die Fortführungsarten sind den ALKIS-Anlassarten zugeordnet (z.b. FA: 64,Veränderung der Angaben zu Eigentümer entspricht der Anlassart ,Angaben zu Eigentümern oder Erbbauberechtigten verändern ). Der Konverter erstellt für den Fortführungsfall einen Benutzungsauftrag mit dem entsprechenden Kennzeichen an die lokale Datenhaltung (LDM). Mit dem vom LDM gelieferten Benutzungsergebnis und den Daten des Fortführungsfalls erstellt der Konverter einen Fort- 27

29 Zusammenarbeit mit der Grundbuchverwaltung 28 führungsauftrag. Dieser wird in das LDM eingetragen und liefert ein Fortführungsergebnis. So wird Fortführungsfall für Fortführungsfall automatisiert in das LDM übernommen. Wenn das Benutzungs- oder Fortführungsergebnis fehlerhaft ist, müssen manuelle Nachbearbeitungen erfolgen. Gründe hierfür können sein: Ein Kennzeichen konnte im LDM nicht gefunden werden, z. B. weil ein älterer Veränderungsnachweis nicht im Grundbuch eingetragen wurde. Dies kommt gelegentlich bei Grundbuchblättern des Erbbaurechts vor. Man muss bedenken, dass die beiden Register,Kataster und,grundbuch in der Vergangenheit noch nie miteinander abgeglichen worden sind und es deshalb zu Recherche- und Nachbearbeitungen kommen wird. Die Anzahl der Fälle, der Umfang und der Aufwand hierfür sind nicht abschätzbar. Die Fortführung wurde nicht übernommen, weil in dem Fortführungsfall nicht alle Daten übertragen werden konnten. Im Elektronischen Grundbuch ist es möglich Felder mit mehr Zeichen zu belegen, als die Schnittstelle LBESAS es vorsieht. Zum Beispiel werden für Namensangaben (Name, Vorname, Namensbestandteil, akademischer Grad, Geburtsdatum, Geburtsname) nur 104 Zeichen übertragen, im Elektronischen Grundbuch können aber rund 300 Zeichen eingetragen werden. Auch hier ist eine manuelle Nachbearbeitung durch Abgleich der im Grundbuch eingetragenen Daten notwendig. Möglichkeiten der Nachbearbeitung: Mit der Anwendung ALKISbuch (Bezeichnung der Erhebungskomponente für den Bereich der Bestands- und Eigentümerangaben) kann durch einen Standard-Editor (z.b. TextPad) in der LBESAS-Datei das Kennzeichen für den Fehlerfall korrigiert werden. Mit der Anwendung ALKISbuch wird der fehlerhafte Fortführungsauftrag entsprechend seiner Anlassart aufbereitet und präsentiert. Die zugehörigen Funktionen ermöglichen die Korrektur und erneute Fortführung des Auftrages. Eine Qualifizierung ist für die Veränderungen, die durch den LBESAS-Konverter oder ALKISbuch erfolgen, nicht erforderlich, da die Daten in diesem Bereich nur einen Sekundärdatenbestand darstellen. Weiterhin werden für Kontrollzwecke die Veränderungslisten in Papierform vom Grundbuch an die ÄfB abgegeben. Ob auf diese irgendwann verzichtet werden kann, muss sich aus der Praxis ergeben. Schnittstelle vom AfB zum Grundbuch Durch die Änderung der ALKIS- Bestandsdaten mit Hilfe der Erhebungskomponente des AAA-Desktop, z. B. durch einen Geschäftsprozess Zerlegung, werden die für das Grundbuch relevanten Änderungen in einem Fortführungsnachweis (FN) gesammelt. Bei der anschließenden Übernahme der Fortführungen in die lokale Datenhaltung (LDM) durch die Qualifizierungskomponente wird in einem Nachbearbeitungsschritt von der LDM automatisch ein Produkt,Änderungsdaten an Justizverwaltung erzeugt und dabei die ALKIS-Daten in die Schnittstelle WLDG-GB rückmigriert. Erst nach der erfolgreichen Übernahme der ALKIS-Bestandsdaten in der Datenhaltungskomponente (DHK) und einer entsprechenden Quittierung wird die Schnittstellendatei per FTP zur Grundbuchverwaltung übermittelt. Für den Datenaustausch ist kein Quittierungsverfahren vorgesehen, das die ordnungsgemäße Übernahme der Daten bestätigt. Es erfolgt daher weiterhin der Versand einer Fortführungsmitteilung (FM) in Papierform, die als Produkt aus dem digitalen FN abgeleitet wird. Eine Beglaubigung dieser FM wird nicht mehr vorgenommen, eine entsprechende Rechtsverordnung soll ergehen. Die Schnittstellendatei ähnelt einem Auftragsformular mit Zeilen und Spalten, in die die verschiedenen Informationen abgelegt werden (vgl. Abbildung 2). Die Art der Information wird über eine Satzart kenntlich gemacht. Jede Fortführung wird mit einer laufenden Nummer eingetragen und erstreckt sich über mehrere Zeilen. Die Datei beginnt mit einer Kopfzeile, die die Auftragsdaten, Liegenschaftskatasterführende Stelle und Auftragsnummer, enthält. Anschließend kommen die Bestandsdaten des von einer Änderung betroffenen Flurstücks mit der Angabe des Bestands- oder Buchungskennzeichens sowie den Namensnummern und Eigentümerdaten. Den Abschluss bilden die Sätze für die Flurstücke mit den Angaben über den Status (aktuell, historisch) und die Fläche, die Lage, die Wirtschaftsart, die Buchungsstelle/ Buchungsart und ggf. Hinweise zu Bodenordnungsverfahren.

30 Zusammenarbeit mit der Grundbuchverwaltung Abbildung 2 - Auszug aus einer WLDG-GB-Datei 7 Ausblick Die Justizverwaltungen der Bundesländer sind dabei ein bundesweit einheitliches Softwaresystem,Redesign EDV- Gundbuch zu entwickeln. Dies soll voraussichtlich in den Jahren 2013 oder 2014 eingeführt werden. Dieses System soll dann konform zum AAA-Modell und hier insbesondere ALKIS sein. Ob dann ein Datenaustausch über NAS-Schnittstellen erfolgt oder aber die doppelte Datenhaltung aufgegeben wird, jede Verwaltung nur noch die Daten pflegt, für die sie originär zuständig ist und die Präsentation der Daten über Web-Dienste erfolgt ist noch nicht abzusehen. 29

31 DV-System DV-System Friedhelm Geitz 30 1 Einführung ALKIS, als modernes Geoinformationssystem für Bürger, Wirtschaft und Verwaltung, bedarf einer aktuellen, integrierten informationstechnischen Infrastruktur. Unsere Kunden erwarten einen,rund um die Uhr Online- Zugriff auf die Geobasisdaten bzw. eine permanente Versorgung mit Aktualisierungsdaten. Neben leistungsfähigen Servern und Speichereinheiten, die einen ausfallsicheren 7mal24-Stunden-Betrieb gewährleisten, müssen auch performante Netzwerke für die Intranet- und Internet-Kommunikation zur Verfügung stehen. Dass dabei die Vorgaben seitens des hessischen E-Government-Projekts und die der Datenschutzgesetze eingehalten werden, ist selbstverständlich. Ebenso sind die Anforderungen an die Informationssicherheit zu berücksichtigen, so dass bei der Verarbeitung, Speicherung und Kommunikation der Daten deren Authentizität, Verbindlichkeit, Vertraulichkeit, Verfügbarkeit und Integrität in ausreichendem Maß sichergestellt werden. Gleichzeitig ist die Datenintegrität zur logischen Widerspruchsfreiheit, Vollständigkeit und Genauigkeit von Daten in einer Datenbank zu gewährleisten. Schließlich sind für die erbrachten Leistungen die für eine Kostenermittlung notwendigen Kenngrößen zu bestimmen und für die Abrechnung im SAP-Rechnungswesen bereitzustellen. 2 UPG DV-System Für die Konzeption eines DV- Gesamtsystems wurde Ende 2003 die Unterprojektgruppe,DV-System, kurz UPG DV-System (vgl. INTERN 2/2005, Köpper -,Projektarbeit für ALKIS ), zum Projekt ALKIS gebildet. Die UPG DV-System besteht aus Vertretern des Hessischen Ministeriums für Wirtschaft, Verkehr und Landesentwicklung (HMWVL), der Ämter für Bodenmanagement (ÄfB) sowie der Dezernate Informationstechnik (Z 3), Topographie und Fernerkundung (I 2), Fachkonzepte Liegenschaftskataster (II 1) und Datenverarbeitung für Geobasisdaten (III 3) des Hessischen Landesamtes für Bodenmanagement und Geoinformation (HLBG). Der Auftrag an die Unterprojektgruppe DV-System lautet: Erstellung eines DV-Gesamtkonzepts (Hard- und Software) unter Berücksichtigung der Anbindung des Geodatenservers, der gemeinsamen Datenhaltung AFIS, ALKIS und ATKIS (AAA) sowie aller Applikationen. Erstellung eines Hardwarekonzepts für die Pilotierung, Migration und Fortführung von ALKIS unter Berücksichtigung der sieben Bodenmanagementbehörden und Aufstellung eines Zeitplans für die Jahre 2005 bis zur Ablösung ALB und ALK. Durchführung der Pilotierung. Erstellung von Schulungskonzepten. Erstellung des Finanzplanes für das DV-Gesamtkonzept. 3 DV-Gesamtkonzept In den ersten Sitzungen der UPG DV-System wurde zunächst das DV-Gesamtkonzept erörtert. Dabei wurden u. a. folgende Rahmenbedingungen berücksichtigt: In der Ausschreibung zur Entwicklung des hessischen Geodatenservers ist bereits entschieden worden, den Geodatenserver in der Hessischen Zentrale für Datenverarbeitung (HZD) zu betreiben und ihn als ALKIS-Datenhaltungskomponente (DHK) weiter zu entwickeln und die,auskunfts- und Präsentationskomponente (APK) als,shop-lösung zu realisieren. Aufgrund des notwendigen direkten physikalischen Datenflusses zwischen den bisherigen DV-Systemen, den Vermessungsinstrumenten und den externen Erfassungsgeräten zu dem zukünftigen System sollen das Migrationstool und die Erhebungskomponente des,aaa-desktop Hessen bei den ÄfB eingerichtet werden.

32 DV-System (vgl. INTERN 2/2005, Pauly -,Der AAA-Desktop Hessen ). Das Migrationstool wird bereits zu Beginn der Qualifizierung der Liegenschaftsdaten für die Probemigration benötigt (vgl. INTERN 2/2005, Köpper -,Migrationskonzept ). Die Qualifizierungskomponente war seinerseits für den Leistungskatalog zur Ausschreibung des Geodatenservers nicht enthalten. Sie wird nun gemeinsam mit der Erhebungskomponente als,erhebungs- und Qualifizierungskomponente (EQK) entwickelt und spätestens zu Beginn des ALKIS-Produktivbetriebs benötigt. Für die Speicherung der AAA-Bestandsdaten, der temporären Ergebnisse der Erhebung und der Daten für die Fachinformationssysteme (wie beispielsweise LEFIS oder Bodenrichtwerte) wird ein,lokales Datenmanagement (LDM) benötigt. Diese im Wesentlichen aus einer Oracle- Datenbank bestehende Komponente muss ebenfalls zum Zeitpunkt des Produktivbetriebs der EQK zur Verfügung stehen. Die UPG DV-System hat folgendes Konzept für das DV-Gesamtsystem entwickelt und über die PG ALKIS dem Programmlenkungsausschuss (PLA) - ehemals: Projektmanagement (PM) - zur Entscheidung vorgelegt: Für die Datenhaltung der AAA-Daten wird der Geodatenserver als gemeinsame,datenhaltungskomponente (DHK) weiter entwickelt. Somit werden die Anforderungen an einen 7mal24-Stunden-Betrieb sowie die Sicherheit und Integrität der Daten durch die zentrale Systemumgebung in der HZD auch weiterhin gewährleistet. Alle internen und externen Nutzer greifen über die zentrale,auskunfts- und Präsentations-Komponente (APK) des Geodatenservers auf die AAA- Daten der DHK in der HZD zu. Die existierende Shop-Lösung gewährleistet den Online-Zugriff der Kunden, die Kostenermittlung sowie die Abrechnung der empfangenen Leistungen über SAP. In den Hauptstellen der ehemaligen Katasterämter wird das Migrationstool bereits zu Beginn der Qualifizierung der Liegenschaftsdaten und zur Probemigration benötigt. Um einen standortübergreifenden, flexiblen Personaleinsatz während der Übergangsphase zur Einhäusigkeit der ÄfB zu gewährleisten, ist die Systemumgebung für das Migrationstool und die EQK als Windows-Terminalserverlösung zu realisieren. Als Betriebssystem wird Microsoft Windows Server 2003 definiert. Ausschließlich an den sieben Standorten der Hauptstellen der ÄfB wird das Migrationstool für die abschließende Überführung der Datenbanken von ALB-Hessen, der ALK- Grundrissdatei und der ALK- Punktdatei in die neue ALKIS- Struktur installiert. Zum Beginn des ALKIS- Produktivbetriebs müssen an diesen Standorten auch die,erhebungs- und Qualifizierungskomponente (EQK) und das,lokale Datenmanagement (LDM) zur Verfügung stehen. Migrationstool und EQK sind aus Synergiegründen zusammenzufassen und als System eines Herstellers als,aaa- Desktop Hessen zu beschaffen. Abbildung 1 - Zeitschema zur Einführung von ALKIS Die UPG DV-System erhält den Auftrag, einen Leistungs- 31

33 DV-System katalog für einen beschränkten Teilnehmerwettbewerb zur Beschaffung des,aaa-desktop Hessen zu erstellen. Die Ausschreibung und Vergabe soll durch die Hessische Zentrale für Datenverarbeitung (HZD) erfolgen. Die UPG DV-System erhält den Auftrag, die Anforderungen der DHK/APK für die Weiterentwicklung des Geodatenservers zu spezifizieren. Alle Fortführungsdaten der Qualifizierungskomponente werden im LDM gesammelt und täglich über das Verfahren der Nutzerbezogenen Bestandsdatenaktualisierung (NBA-Verfahren) an die DHK übertragen. Es ist sicherzustellen, dass die gemeinsamen Objekte benachbarter LDM in den Randgebieten der ÄfB ebenfalls in den Fortführungszyklus integriert werden. Der,AAA-Desktop Hessen als EQK/LDM und der Geodatenserver als DHK/APK müssen zeitgleich ihre Produktion aufnehmen. Es ist ein gemeinsamer Pilotbetrieb vorzusehen. Der,AAA-Desktop Hessen als EQK/LDM und der Geodatenserver als DHK/APK müssen stets auf der gleichen Basis des AAA-Referenzmodells (GeoInfoDok Version) betrieben werden. Die Betriebsbereitschaft der bisherigen DV-Systeme zur Führung des Liegenschaftskatasters muss bis zum Abschluss der ALKIS-Migration sichergestellt werden. 4 Hardwarekonzept Mit der Entwicklung eines Hardwarekonzepts für den,aaa-desktop Hessen wurde eine Arbeitsgruppe, bestehend aus Mitgliedern der Linienorganisation der Dezernate Z 3 und III 3, beauftragt. Die Analyse der vorhandenen DV-Struktur in den einzelnen Standorten der ehemaligen Katasterämter zeigte, dass die existierende Systemumgebung für den Betrieb des,aaa- Desktop Hessen nicht geeignet war. Die Anforderungen an eine neue DV-Systemumgebung wurden in dem Arbeitspapier,Erneuerung der IT-Infrastruktur bei den Ämtern für Bodenmanagement wie folgt dokumentiert und dem Projektmanagement zur Entscheidung vorgelegt. Die NCR Worldmark 4300 (Baujahr 1997), als System für das ALB-Hessen und die ALK- Punktdatei (GEOi-SQL), und die SGI Octane II (Baujahr 2002), als System für die ALK-Grundrissdatei (SICAD), müssen bis zum Abschluss der ALKIS- Migration an allen Standorten der ehemaligen Katasterämter betriebsfähig gehalten werden. Es wird empfohlen, die Wartungsverträge zu verlängern. Die Adaption der Fachanwendungen auf eine neue Hard- bzw. Softwareplattform ist unwirtschaftlich. Realisierungsstufe 1 In einer,realisierungsstufe 1 ist für das Migrationstool des,aaa-desktop Hessen eine neue Hardwareplattform an allen Standorten der Hauptstellen der ehemaligen Katasterämter zu errichten. Neben einem Fileserver zur Aufnahme Abbildung 2 AAA DV-Gesamtsystem 32

34 DV-System der ALB- und ALK-Migrationsdaten sind Ressourcen für die Oracle-Datenbank zur temporären Aufnahme der Migrationsergebnisse bereitzustellen. Das Migrationsprogramm wird auf mehrere Terminalserver (Citrix Presentation Server) verteilt. Für die Schulung der Anwender des,aaa-desktop Hessen und zum Test der Software wird im HLBG ein zusätzliches, baugleiches System benötigt. Als Ersatz für veraltete Hardware, zum Betrieb der Systemumgebung des,aaa- Desktop Hessen und als Vorableistung zur Einführung der E-Government-Struktur (ITS-Hessen) sind folgende Anforderungen berücksichtigt worden: Ersatzbeschaffung für die Systeme Fujitsu Siemens Computers (FSC) der Baujahre als Systeme zur Archivierung der Vermessungsrisse (DMAS) und als Microsoft Windows 2003 Server Fileserver für verschiedene Fachanwendungen (z.b. Office- CAD, RBU) an allen Standorten der ehemaligen Katasterämter der ÄfB. Diese Fileserver sollen auch für die Dateiablage der PCs (sog. Home-Verzeichnisse) genutzt werden und somit die NCR-Systeme entlasten. Installation eines CITRIX- Lizenzverwaltungs- und Steuerungs-Systems und Integration aller Terminalserver in eine Citrix-Farm im HLBG. Zur Realisierung der Druck- bzw. Plot- Ausgaben werden Printserver an allen Standorten der ehemaligen Katasterämter benötigt. Installation eines einheitlichen Backup-Systems zur Sicherung und Archivierung der Daten auf ein gemeinsames Sicherungsmedium an jedem Standort der ÄfB. Einführung einer Microsoft Active Directory Struktur und Integration der Microsoft Exchange Umgebung als Vorableistung zur Einführung einer hessischen E-Government-Umgebung mit gleichzeitiger Einführung eines Verfahrens zum automatisierten Updaten (Patchen) aller Microsoft Windows 2003 Server in der HVBG. Migration aller Microsoft Windows NT 4.0 Server nach Microsoft Windows 2003 Server an den ehemaligen Standorten der Flurneuordnung der ÄfB. Migration aller Arbeitsplatzgeräte (PCs und Notebooks) von Microsoft Windows NT 4.0 nach Microsoft Windows XP an allen Standorten der ÄfB und im HLBG mit gleichzeitiger Einführung eines Verfahrens zu automatisierter Installation, Verwaltung und Update der Arbeitsplatzgeräte für das Betriebssystem, Microsoft Office, aller Fachanwendungen und der McAfee Antiviren- und Internetsicherheits-Software. Einrichtung eines File Transfer Servers zur Steuerung und Abwicklung des Datenverkehrs zwischen den einzelnen Fachanwendungen und zur Aktualisierung der DHK. Ausbau der aktiven Netzwerkkomponenten zum Anschluss der Microsoft Windows 2003 Server mit 1 GBit/s Netzwerkanbindung und Umstellung bzw. Erweiterung des IP-Adressraums an allen Standorten. Beschaffung aller Hard- und Softwarekomponenten aus dem Standardangebot der HZD. Unter Berücksichtigung der vorhandenen IT-Infrastruktur (geringe Raumgröße, tlw. keine Klimatisierung, Stromversorgung, keine USV, keine Serverschränke) bei den derzeitigen Standorten der ÄfB und der Forderung nach einem flexiblen Betrieb der neuen DV-Systemumgebung - auch während einer längeren Umzugsphase und nach vollzogener Einhäusigkeit der sieben ÄfB - wurde für die,realisierungsstufe 1 ein System auf der Basis,virtueller Server konzipiert. Auf einer physischen Hardware stellt das Softwareprodukt,ESX Server der Firma VMware eine virtuelle Hardware für Server unterschiedlicher Betriebssysteme zur Verfügung. Somit lassen sich mehrere Server gleichzeitig auf einer gemeinsamen Hardware betreiben und die Ressourcen, wie CPU, Speicher etc., den jeweiligen Anforderungen individuell anpassen bzw. lastabhängig steuern. Diese platzsparende Lösung lässt sich in den momentan vorhandenen Rechnerräumen betreiben und ist, durch Neuverteilung der virtuellen Systeme, während der Umzugsphasen und nach der Einhäusigkeit flexibel konfigurierbar sowie später in 19 - Serverschränke einbaubar. Zusätzlich können, beispielsweise beim Ausfall einer Hardware, die virtuellen Server innerhalb kürzester Zeit auf eine andere Plattform transferiert werden. 33

35 DV-System Zur Umsetzung des Konzepts werden Server der Firma Fujitsu Siemens Computers (FSC) Modell TX 600 für die Hauptstellen der ehemaligen Katasterämter und Modell TX 300-S2 für die Nebenstellen der ehemaligen Katasterämter aus dem Standardangebot der HZD beschafft. Abbildung 3 Systemarchitektur Realisierungsstufe 1 Realisierungsstufe 2 In einer,realisierungsstufe 2 müssen die zum Produktivbetrieb der EQK und des LDM benötigten Applikations- und Datenbank-Server zur Verfügung gestellt werden. Um den performanten Zugriff aller Beschäftigten der ÄfB zu gewährleisten, ist auch die Anzahl der Terminalserver zu erhöhen. Während der Umzugsphase und nach der Einhäusigkeit der Ämter für Bodenmanagement sind die virtuellen Server neu zu verteilen, wobei gleichzeitig eine höhere Ausfallsicherheit herzustellen ist. Gleichzeitig muss die Festplattenkapazität in einem AfB-Standort dem künftigen Bedarf angepasst und, gemeinsam mit den lokalen Festplatten der vorhandenen Server, in einem externen Speichersystem allen Servern zur Verfügung gestellt werden. Darüber hinaus sind die lokalen Netzwerke und die Bandbreiten der bestehenden WAN-Anbindungen für die Haupt- und Außenstellen der Ämter für Bodenmanagement zu optimieren. Die Komponenten für die,realisierungsstufe 2 werden zum Zeitpunkt der Pilotierung der EQK/LDM benötigt bzw. müssen bei der Einhäusigkeit der ÄfB in Betrieb genommen werden. Abbildung 4 Datenfluss im Gesamtsystem 34

36 Erfahrungen aus 5 Jahren Vormigrationsarbeiten Erfahrungen aus 5 Jahren Vormigrationsarbeiten Reinhard Limmert und Roland Peter 1 Einleitung Schon bald nach der Gründung der Projektgruppe ALKIS im Sommer 2002 wurde klar, dass die Datenbestände des Liegenschaftskatasters nur dann reibungslos nach ALKIS migriert werden können, wenn sie zuvor so verbessert worden sind, dass sie in sich widerspruchsfrei, vollständig und teilweise auch in besonderer Weise aufbereitet sind. Die dafür anfallenden Arbeiten wurden als,qualifizierungsarbeiten festgelegt. Den damaligen Katasterämtern wurde aufgetragen, die Arbeiten mit Vorrang zu bewältigen. Seit Juli 2005 gibt es ein erstes Migrationsprogramm, mit dessen Hilfe die Datenbestände probeweise nach ALKIS migriert werden können, so dass auf diese Weise überprüft werden kann, ob die Daten wirklich - wie für ALKIS notwendig - verbessert sind. Damit sind nun den Ämtern im Vorfeld der Migration nach ALKIS, in der Zeit der Vormigration, zwei wichtige Arbeiten aufgegeben: Qualifizierungsarbeiten Probemigrationen Außerdem gehört die Pilotierung der EQK zu den Arbeiten in der Vormigration. Hierbei soll die EQK vor Ort in der Praxis getestet werden, es sollen mögliche Fehler entdeckt und Programmverbesserungen vorgeschlagen werden. Die EQK- Pilotierung ist vom Umfang her geringer und soll hier nicht weiter betrachtet werden. Im Folgenden sollen die wesentlichen Vormigrationsarbeiten beschrieben und die dabei gewonnenen Erfahrungen aus den letzten 5 Jahren aufgezeigt werden. 2 Qualifizierungsarbeiten In dem INTERN-Sonderheft 2/2005,ALKIS Konzeption für Hessen sind die notwendigen Qualifizierungsarbeiten umfassend beschrieben. Nach ihrer Wichtigkeit sind sie unterschieden in Muss- Arbeiten, Soll-Arbeiten und Kann-Arbeiten. Es zeigte sich bald, dass von den Ämtern eine gewaltige Arbeitsleistung abverlangt wurde und dies noch unter dem Zeitdruck, die Arbeiten bis zum abzuschließen. Die Folge davon war, dass an die Bewältigung der Kann-Arbeiten überhaupt nicht gedacht werden konnte; auch die Soll-Arbeiten wurden erst einmal zugunsten der Muss-Arbeiten zurückgestellt. Zwischenzeitlich wurden die Soll-Arbeiten immer nur dann in Angriff genommen, wenn je nach örtlichen Gegebenheiten vorübergehend Personal frei war. Der Berg der zu bewältigenden Muss-Arbeiten war aber immer noch so groß, dass innerhalb der Muss- Arbeiten nochmals eine Unterscheidung getroffen wurde: Muss-Arbeiten mit KO-Kriterium Übrige Muss-Arbeiten In die erste Art fallen die Arbeiten, die für die Migration nach ALKIS unabdingbar sind (Abgleich der Flurstücksnummern, keine Überschneidung von Flurstücken an kreisförmigen Grenzen, Randanpassung an den Grenzen der Katasteramtsbezirke, Erstellung der Virtuellen Folie 021). Ohne die Erledigung der Arbeiten mit KO-Kriterium wäre die Migration nach ALKIS unmöglich. Bei einem Verzicht auf die übrigen Muss-Arbeiten würde zwar die Migration nach ALKIS funktionieren, wir müssten aber dabei im Liegenschaftskataster erhebliche, nicht mehr vertretbare Mängel in Kauf nehmen. Aus verschiedenen Gründen verschob sich der Starttermin für die Migration nach ALKIS mehrere Male nach hinten, so dass die Ämter doch mehr Zeit zur Bewältigung aller Muss- Arbeiten bekamen. Auch zum sind noch nicht bei allen Ämtern alle Muss- Arbeiten erledigt. Für die Restarbeiten verbleibt ein überschaubarer Umfang, so dass sie auf alle Fälle bis zum derzeit angepeilten Starttermin geschafft werden. Aus der Erledigung der Qualifizierungsarbeiten können folgende Erfahrungen abgeleitet werden: Leider schleichen sich bei der alltäglichen Fortführung des Liegenschaftskatasters immer wieder neue Fehler in die Datenbestände ein. Die Rechenläufe zur Überprüfung der Daten müssen immer wieder neu gestartet werden; die Behebung der neu entdeckten Fehler vergrößert laufend den Gesamtaufwand für 35

37 Erfahrungen aus 5 Jahren Vormigrationsarbeiten Wie oben schon ausgeführt wurde, ist es für die Migration wichtig, eine Datenkonsistenz zu erzeugen, die den strengen Anforderungen an die Datenhaltung unter ALKIS gerecht wird. Auch wenn eine Qualifizierungsarbeit erledigt ist, kann letzte Klarheit über den Erfolg der Fehlerbeseitigung nur ein Migrationstest bringen. Dazu kommt, dass auch die Software für die Migration bisher nur unter,laborbedingungen erprobt ist. Die Tauglichkeit in der Praxis - mit der Verarbeitung von Massendaten und amtsspezifischen Besonderheiten - zu untersuchen, ist auch unter diesem Aspekt geboten. Schließlich geht es auch darum, Erfahdie Qualifizierungsarbeiten. Gewisse neue Gegebenheiten oder auch neue Erkenntnisse können dazu führen, dass ein nachträglicher Aufwand für bereits erledigte Qualifizierungsarbeiten notwendig wird (zum Beispiel die erneute Beseitigung von Flurstücksüberschneidungen an kreisförmigen Grenzen durch die Einführung des LST 100, die Übertragung der Linienteilungspunkte von Nutzungsarten- und Schätzungsgrenzen an Amtsbezirksgrenzen in die Nachbar- GDB). Wenn ein Bearbeiter eine neue Arbeit anpackt und an dieser Arbeit dranbleiben kann, wird sie aufgrund der stetig wachsenden Erfahrungen am Ende schneller bewältigt, als vorher abgeschätzt werden konnte. Sehr hilfreich und förderlich für den Arbeitsfortschritt war die ständige Verbesserung der Programme zur Prüfung der Daten und zur Bereinigung der aufgedeckten Fehler. Wirklich alle Fehler und Widersprüche zu beseitigen, ist eine Aufgabe, die wir in die Zeit der Nachmigration verlegen müssen. Seit Jahresbeginn 2005 wird über Zeitaufschreibung der personelle Aufwand für ALKIS erfasst und in SAP festgehalten. Mit diesen verlässlichen Zahlen und Abschätzungen für die beiden vorangegangenen Jahre wurde ermittelt, dass in den Jahren in der HVBG (in den Ämtern und im Dezernat II 1 des HLBG) bisher 207 Personenjahre für die Qualifizierungsarbeiten aufgebracht worden sind. 3 Migration allgemein Die Verwendung des Begriffes Migration (von lateinisch migratio,wanderung ) assoziiert bei den meisten Menschen die soziologische Bedeutung. Spezialisten haben je nach Fachgebiet (Geologie, Medizin, Astronomie, Botanik, ) ganz andere Bilder vor Augen, IT-Fachleute denken an den Transfer von Daten, den Umstieg auf eine andere Software oder den Technologiewechsel auf der Hardware-Seite. Wenn wir in der HVBG im Zusammenhang mit ALKIS von Migration sprechen, meinen wir im Sinne der IT-Technik den Datentransfer der ALB-Daten, der ALK-Daten und der Daten der KP-DAT nach ALKIS in eine neue Datenhaltungsstruktur. Damit verbunden sind der gleichzeitige Wechsel von Soft- und Hardware sowie die Neukonzeption der Infrastrukturen. 36 Abbildung 1 4 Probemigration im Besonderen

38 Erfahrungen aus 5 Jahren Vormigrationsarbeiten rungen im Umgang mit den Tools zu gewinnen und Vorstellungen über die für die Migration notwendige Zeit zu entwickeln. 5 Erste Probemigration Hessen Im Juli 2005 konnte das Migrationstool auf der Basis der GeoInfoDok 3.1 an die Ämter ausgeliefert werden, die Arbeiten wurden aber zunächst nur zögerlich aufgenommen. Das für die Migration vorgesehene und geschulte Personal war noch mit wichtigen Arbeiten der Qualifizierung beschäftigt. Erst etwa Mitte des Jahres 2006 waren die ersten 500 Gemarkungen (von landesweit 2867) probemigriert, die Fehlerbereinigung hinkte entsprechend nach. Die ersten mühsam gemachten Erfahrungen entsprachen den Befürchtungen: Trotz aller Sorgfalt enthielten die Daten weiterhin Fehler, deren Suche und Bearbeitung umständlich aus verschiedenen Protokollen erfolgen musste. In der Migration selbst musste jeder Schritt einzeln angestoßen werden, was das Personal an den Rechner band. Es kam auch zu Fehlern im Programm, zu Abstürzen, die nicht durch die Daten erklärbar waren. Zur Lösung dieser Probleme entwickelte sich zwischen den Ämtern und den Experten im Landesamt eine intensive und weiterführende Zusammenarbeit. Die Bearbeiter vor Ort erkannten, wie wichtig und unverzichtbar ihre Arbeit bei der Bewältigung der Qualifizierungsarbeiten für den Gesamtprozess war, was zu neuem Elan und einem gewissen Pioniergeist führte. Abbildung 2 - Entwicklung der ersten Probemigration Der landesweite Durchbruch wurde dann mit einer neuen Software im Juli 2006 auf der Basis der GeoInfoDok 4.0 erreicht. In der Kurve der erledigten Probemigrationen (Abbildung 2) ist ab August 2006 ein deutlicher Knick als Aufwärtstrend erkennbar. Das neue Tool ist durch die Berücksichtigung der bisherigen Erkenntnisse insgesamt bedienerfreundlicher, die gesamte Migration kann durch einen Klick angestoßen werden, die ermittelten Fehler werden in einer einzigen Datei zusammengefasst, die anschließend in SICAD eingelesen wird. Dort springt das Programm automatisch an die fehlerhaften Stellen in der ALK, so dass die Fehler schneller abgearbeitet werden. Dazu gibt es nun auch Arbeitshilfen, die mögliche Fehler und deren Beseitigung beschreiben. 37

39 Erfahrungen aus 5 Jahren Vormigrationsarbeiten 38 Auf den Punkt gebracht: die Migration der Daten läuft nun komfortabler und schneller. Bezogen auf Kartenpunkte kann der Gesamtaufwand von 6,4 Stunden auf 4,8 Stunden reduziert werden. Dieser Analyse liegen 173 Gemarkungen (Basis GID 3.1) bzw. 414 Gemarkungen (Basis GID 4.0) zu Grunde. Der Aufwand für eine mittlere Gemarkung geht dabei von 8,8 Stunden auf 6,1 Stunden zurück. Die deutlichste Beschleunigung ist bei der Fehlerbereinigung zu verzeichnen, aber auch die eigentliche Migrationszeit ist ein Drittel kürzer, wie aus der Tabelle in Abbildung 3 ersichtlich ist. Zum sind 94 % der hessischen Gemarkungen ein Mal zu Testzwecken migriert, 89 % sind bereits fehlerbereinigt. In den Ämtern und im Dezernat II 1 des HLBG sind bisher 11 Personenjahre für die erste Probemigration aufgebracht worden. 6 Versionenproblem Die Weiterentwicklung der GeoInfoDok (GID) durch das Revisionsmanagement der AdV ist sicher notwendig, stellt aber im laufenden Umstellungsprozess ein nicht unerhebliches Problem dar, zumal sich die Frequenz der Änderungen erhöht. Der Wechsel von der Version 3.1 zur Version 4.0 konnte im Migrationstool noch gewinnbringend im Zusammenhang mit der ohnehin notwendigen Weiterentwicklung der Startversion des Tools umgesetzt werden. Am beschloss die PG ALKIS die Einführung der GID 5.1 als Basis für die Komponenten Migrationstool, EQK und LDM. Für April 2007 wurden dann die Versionen (Vorstufe) mit 14 Änderungen und im Abbildung 3 - Bearbeitungszeiten Sommer (Endstufe) mit weiteren 76 Änderungen erwartet. In die Sitzung des Programm-Lenkungsausschusses vom wurde schließlich das Change-Management für die Version 5.1.1_K (,K steht für Korrekturversion) eingebracht, am wurde festgestellt, dass die Version 5.1.1_K2 umgesetzt werden muss. Der Programm-Lenkungsausschuss hat deshalb am beschlossen, dass das Liegenschaftskataster in der Version 5.1.1_K2 nach ALKIS migriert wird. Jeder Wechsel der Version verschlingt finanzielle und personelle Ressourcen und kostet Zeit. 7 Zweite Probemigration Hessen Das ursprüngliche Ziel, die Daten jeder Gemarkung Hessens einmal zur Probe migriert zu haben, ist in Kürze erreicht. Schon seit geraumer Zeit ist klar, dass zur Bereinigung der neu erzeugten oder bisher unentdeckten Fehler unbedingt eine zweite Probemigration notwendig ist. Etwa 20% der Gemarkungen sind noch mit dem Migrationsprogramm auf Basis der GID 3.1 bearbeitet worden, das noch nicht so durchgreifend abgeprüft hatte. Für viele Gebiete gilt, dass nach der Fehlerbearbeitung keine weitere Kontrolle durchgeführt wurde. Diese zweite Probemigration ist seit Mai 2008 bei den Ämtern angelaufen. Das Migrationsprogramm beruht auf der Version 5.1.1_K. Die migrierten Daten werden in ein Test-LDM im HLBG eingelesen, weil sich herausgestellt hat, dass dabei weitere, bisher unentdeckte Fehler festgestellt werden. Inzwischen ist noch eine dritte Probemigration dann in der Version 5.1.1_K2 eingeplant, die unmittelbar vor der Produktionsmigration unter genau den gleichen Bedingungen wie diese ablaufen soll.

40 Migration nach ALKIS Migration nach ALKIS (Produktionsmigration) Reinhard Limmert 1 Einleitung Für die eigentliche Migration der Datenbestände des Liegenschaftskatasters nach ALKIS hat sich inzwischen der Begriff,Produktionsmigration herausgebildet, während die testweisen Migrationen nach ALKIS im Rahmen der Vormigrationsarbeiten als,probemigrationen bezeichnet werden. Seit Oktober 2007 entwickelt die PG ALKIS ein Konzept für die Durchführung der Produktionsmigration. Mit diesem Migrationskonzept sehen wir nun viel klarer, wie die Migration technisch und zeitlich ablaufen wird. Im Folgenden sollen die wesentlichen Punkte des Migrationskonzeptes dargestellt werden. 2 Zeitplanung Der wichtigste Punkt des Migrationskonzeptes ist die Zeitplanung. Hierbei sind folgende Zwänge bzw. Vorgaben zu berücksichtigen: Die Migration soll in jedem früheren Katasteramtsbezirk und in jedem AfB möglichst schnell ablaufen. Hintergrund für diese Vorgabe ist, dass für das Gebiet eines Katasteramtsbezirkes die Fortführung des Liegenschaftskatasters völlig eingestellt werden muss, solange die Migration läuft. Auch landesweit soll die Migration möglichst schnell abgeschlossen sein, da nur so der Parallelbetrieb von ALKIS mit den Altsystemen auf dem Geodatenserver abgekürzt werden kann. Der Parallelbetrieb auf dem Geodatenserver erfordert nämlich bedeutend höhere Betriebskosten. Die Migration in einem AfB soll möglichst gut mit den anstehenden Umzügen abgestimmt sein. Die beste Lösung ist, wenn das betreffende AfB vor der Migration bereits in seinen Neubau eingezogen ist. Dass Migration und Umzug genau zusammenfallen, muss unbedingt vermieden werden. Notfalls muss in Kauf genommen werden, dass die Migration noch an den alten Standorten stattfindet. Es macht keinen Sinn, wenn in dem Bezirk eines AfB nach ALKIS migrierte Daten in so großem Umfang anfallen, dass beim Füllen des LDM ein Stau entsteht. Die anfallende Datenmenge muss deshalb so bemessen sein, dass sie dem Aufnahmevermögen des LDM entspricht. Seit Anfang Dezember 2007 verfügen das Dezernat II 1 des HLBG und seit Mai 2008 alle Ämter über das neue Migrationsprogramm auf Grundlage der Version 5.1.1_K der GeoInfoDok. Seitdem werden Probemigrationen mit dieser Programmversion durchgeführt und die angefallenen Migrationszeiten ermittelt. Hieraus werden Leistungszahlen abgeleitet, mit deren Hilfe die Dauer der Produktionsmigration für einen Katasteramtsbezirk, für ein AfB und für das Land Hessen hochgerechnet wird. Diese Hochrechnungen bilden die Grundlage für eine Zeitplanung. Nach dem Stand vom bestehen folgende Leistungszahlen: Für die Migrationszeit: 46,1 Minuten / Punkte der KP-DAT Für das Füllen des LDM: 17,8 Minuten / Punkte der KP-DAT Für das Auslesen aus dem LDM werden für eine durchschnittliche Gemarkung mit Punkten 10 Minuten benötigt. In die Leistungszahl für die Migrationszeit sind die Zeiten für das Auslesen der Altdaten nicht mit eingegangen, obwohl hierbei ein erheblicher zeitlicher Aufwand anfällt ( % der Migrationszeit). Die Gründe dafür sind: Das Auslesen der Altdaten betrifft andere Maschinen, nicht den Terminalserver, auf dem die Migration läuft. Die Arbeit der Bediensteten, die die Produktionsmigration durchführen, wird nicht beeinträchtigt, selbst wenn sie noch gleichzeitig Altdaten auslesen müssen. Nur ganz am Anfang - vor der Migration der ersten Gemeinde - entsteht durch das Auslesen der Altdaten ein zusätzlicher Aufwand, der aber im Hinblick auf den Gesamtaufwand der Produktionsmigration vernachlässigbar wird. Bei der weiteren Migration laufen Auslesen der Altdaten und 39

41 Migration nach ALKIS Migration gleichzeitig. Innerhalb eines AfB kann gleichzeitig an verschiedenen Terminalservern migriert werden. Die Anzahl der einzusetzenden Terminalserver sollte mindestens drei betragen, weil dann aufgrund der oben genannten Leistungszahlen ein Gleichgewicht zwischen migrierter Datenmenge und dem Aufnahmevermögen des LDM besteht. Mit Vorliegen einer größeren Stichprobe an Probemigrationen soll versucht werden, verschiedene Sachverhalte, die die Migrationszeit beeinflussen (z. B. Vorliegen der Folie 042, unterschiedliche Gebäudeanzahl, Wohnungseigentum in größerem Umfang), herauszurechnen, um entsprechend erweiterte Leistungszahlen zu erhalten. Zu erwähnen ist noch, dass der Rechenaufwand für die Transformation der Koordinaten von LST 100 nach ETRS89/UTM in jeder Gemarkung bisher kleiner als eine Minute war. Offen ist derzeit noch, ob das LDM weiterhin mit gleicher Geschwindigkeit gefüllt werden kann, wenn schon viele Daten eingespeichert sind. Zur Prüfung dieses Sachverhalts ist im HLBG ein Massentest vorgesehen: landesweit anfallende ALKIS-Daten werden in ein einziges Test-LDM eingelesen. In der Abbildung 1 ist die Zeitdauer für die Produktionsmigration für jedes AfB abgeschätzt. Sicherheitshalber ist für die Migrationszeit der Faktor 3 und für die Zeit des LDM-Füllens der Faktor 2 angesetzt. Außerdem wird je nach Größe des AfB von einer unterschiedlichen Anzahl der zur Migration eingesetzten Terminalserver ausgegangen. Abbildung 1 Abschätzung der Dauer der Produktionsmigration für ein AfB Die DHK könnte ohne Leistungseinschränkung gleichzeitig ALKIS-Daten von allen 7 ÄfB aufnehmen. Deshalb wird auch ein gleichzeitiges Füllen der DHK von zwei bzw. drei ÄfB aus ins Auge gefasst werden. Hieraus ergeben sich für die landesweite Migration drei verschiedene Modelle: Abbildung 2 - Modelle für die Produktionsmigration Die landesweite Migration würde nach den einzelnen Modellen folgende Zeiträume umfassen: Modell 1: 9 Monate Modell 2: 6 Monate Modell 3: 5 Monate Inzwischen wird das Modell 2 bevorzugt. Es soll jedoch mit dem AfB Homberg (Efze) begonnen werden. Fulda kommt als erstes AfB aus folgendem Grund nicht mehr in Betracht: Es hat sich gezeigt, dass das Auslesen der ALK so aufwendig sein kann, dass es fast so viel Zeit erfordert wie das Migrieren selbst. 40

42 Migration nach ALKIS Folglich macht es nun keinen Sinn mehr, einen Katasteramtsbezirk (wie in vorstehender Zeitplanung unterstellt) gleichzeitig an mehreren Terminalservern zu migrieren. Wegen der Größe der GDB des Katasteramtsbezirks Fulda wird die Migration des AfB Fulda etwa die dreifache ursprünglich geplante Zeit in Anspruch nehmen, nämlich 6 Wochen. Daher wird die Migration nach Modell 2 nun mit dem AfB Homberg (Efze) beginnen. Das AfB Homberg (Efze) hat zwar eine größere Datenmenge als das AfB Fulda, die größere Datenmenge ist aber recht gleichmäßig auf 7 Katasteramtsbezirke verteilt, so dass der AfB-Bezirk insgesamt schneller migriert werden kann. Das derzeitige Migrationsmodell sieht folgendermaßen aus: Unmittelbar vor jeder Probemigration muss über die entsprechenden Prüfläufe sichergestellt sein, dass folgende Muss-Arbeiten abschließend erledigt worden sind: Abgleich der Flurstücksnummern (mit den Flurstücksnummern des ALB auf dem Geodatenserver) Keine Überschneidung von Flurstücken an Kreisbögen Keine Überschneidung von oberirdischen Gebäuden Flächendeckung der Virtuellen Folie 021 Abbildung 3 Die jetzt vorliegende Zeitplanung für die landesweite Migration nach ALKIS soll schrittweise weiterentwickelt werden: Immer zuverlässigere Leistungszahlen führen zu einer verbesserten Zeitplanung. Die Leistungszahl für das Einlesen in das LDM wird kleiner werden, wenn anstelle der jetzigen Hardware für das Test- LDM die endgültige Hardware für das LDM bereit steht. Die Zeitplanung wird durch den Zeitaufschrieb bei der zweiten Probemigration eine letzte Anpassung erfahren. 3 Weitere Probemigrationen Die Zeitplanung kann jederzeit an veränderte Rahmenbedingungen angepasst werden (z. B. bei verändertem Starttermin, bei veränderten Umzugsterminen). Im Beitrag Limmert/Peter,Erfahrungen aus 5 Jahren Vormigrationsarbeiten wurde bereits dargelegt, dass eine zweite und dritte Probemigration notwendig ist. Im Unterschied zur ersten Probemigration wird bei beiden folgenden Probemigrationen das LDM mit den probemigrierten ALKIS-Daten gefüllt. Dies ist notwendig, weil beim Füllen des LDM weitere, bisher unentdeckte Fehler festgestellt werden. Während die zweite Probemigration noch in diesem Jahr abgeschlossen sein soll, soll die dritte Probemigration unmittelbar vor der Produktionsmigration unter genau den gleichen Bedingungen ablaufen. Dies bedeutet, dass natürlich mit der gleichen Programmversion, der Version 5.1.1_K2, gearbeitet wird und die dritte Probemigration vollautomatisch ablaufen muss. Randanpassung an den Amtsbezirksgrenzen 4 Ablauf der Produktionsmigration Mit Beginn der Produktionsmigration in einem AfB muss der Fortführungsbetrieb in den Altsystemen jeweils bezogen auf einen früheren Katasteramtsbezirk, dessen Daten gerade migriert werden vollkommen eingestellt werden. Hintergrund dafür ist, dass durch Fortführungen in den Nachbargemeinden die Ausgangsdaten der gerade migrierten Gemeinde nicht unbeabsichtigt verändert werden. Der vollständige Fortführungsstopp für den Bereich eines früheren Katasteramtsbezirkes während der Migration seiner Daten ist vertretbar, weil der jeweilige Zeitraum von einigen Wochen überschaubar ist und weil damit eine grundsätzliche Verfahrensweise vorgegeben ist, bei der Fehlbedienungen weitgehend ausgeschlossen werden können. Darüber hinaus dürfen innerhalb des Bezirkes eines AfB in 41

43 Migration nach ALKIS 42 den Katasteramtsbezirken, in denen noch die ALK vorliegt, unmittelbar an den Amtsbezirksgrenzen keine Änderungen mehr vorgenommen werden. Diese Fortführungen können erst eingearbeitet werden, wenn beiderseits der früheren Amtsbezirksgrenze ALKIS vorliegt. Entsprechend müssen Fortführungen unmittelbar an der AfB-Grenze zurückgestellt werden, bis auf beiden Seiten ALKIS besteht. Wie schon vor der zweiten und dritten Probemigration wird unmittelbar vor der Produktionsmigration die Einhaltung der oben genannten Qualitätskriterien abgeprüft. Die Einhaltung der Kriterien,keine Überschneidung von Flurstücken,,Flächendeckung der Virtuellen Folie 021 sowie,keine Überschneidung von Flurstücken und keine Lücken zwischen den Flurstücken an den Amtsbezirksgrenzen ist jetzt besonders wichtig, da im LDM und in der DHK bei der Ersteinrichtung keine Abprüfung auf Flächendeckung möglich ist. Gerade aber die Flächendeckung muss für die Kunden sichergestellt sein, deren Software möglicherweise entsprechende Abprüfungen beinhaltet. Der Beginn der Migration wird zwischen HLBG und dem jeweiligen Amt rechtzeitig abgestimmt, so dass die dritte Probemigration entsprechend zeitnah zur Produktionsmigration geplant und durchgeführt werden kann. Das Amt wiederum gibt den Beginn und die abgeschätzte Dauer für die Migration an alle Vermessungsstellen und Kunden in seinem Amtsbezirk weiter. Hierbei sollten vor allem die Vermessungsstellen über den vollständigen Fortführungsstopp und die damit verbundenen Auswirkungen für die Übernahme von Liegenschaftsvermessungen informiert werden. Die rechtzeitige Information der Vermessungsstellen und Kunden erfordert, dass eine möglichst scharfe Migrationsplanung schon einige Monate vor Migrationsbeginn festgelegt wird. Bei Start der Produktionsmigration ist unabdingbar, dass ALK und ALB den gleichen Fortführungsstand aufweisen. Anschließend wird die Fortführung von ALK, KP-DAT und ALB eingestellt. Da für die Migration das ALB gemeindeweise vom Geodatenserver abgerufen wird, muss im AfB bis zum nächsten Tag gewartet und dann geprüft werden, ob die Fortführung des ALB auf dem Geodatenserver in der Nacht zuvor richtig vollzogen worden ist. Anschließend werden die ALB-Daten der Gemeinden abgerufen, die parallel auf mehreren Terminalservern migriert werden sollen. Die angeforderten ALB-Daten werden nachts vom Geodatenserver ausgegeben und stehen somit am nächsten Tag im AfB zur Verfügung. Da die Migration während der Nacht weiterlaufen soll, andererseits Abbrüche in der Nacht nicht ausgeschlossen werden können, sollten für die nächtliche Migration die Daten von drei Gemeinden je Terminalserver bereitstehen. Im Falle eines Abbruchs beginnt das Migrationsprogramm selbsttätig mit der Migration der nächsten Gemeinde. Insofern ist es eine besondere Aufgabe, den ALB-Abruf so zu steuern, dass das ALB von einer ausreichenden Anzahl an Gemeinden vorliegt. Dass ein AfB in einer Nacht das ALB von einer größeren Anzahl an Gemeinden anfordert oder dass bei den Modellen 2 bzw. 3 verschiedene ÄfB gleichzeitig das ALB abrufen, überlastet den Geodatenserver nicht. Bei der Migration kommt es zum Abbruch, wenn das KO- Kriterium,Flurstücksnummernabgleich nicht erfüllt ist, Flurstücke nicht flächendeckend vorliegen oder Überschneidungen aufweisen. In diesem Fall müssen die Altdaten ALK und / oder ALB berichtigt werden. Die Migration dieser Gemeinde muss auf einen späteren Zeitpunkt in der Abfolge der Migrationen verschoben werden. Bei fehlender Flächendeckung in der Virtuellen Folie 021 oder bei Überschneidungen von oberirdischen Gebäuden bricht das Migrationsprogramm nicht ab; der betreffende Fehler kann mit einer Sonderfunktion des Migrationsprogramms beseitigt werden. Sobald die ALKIS-Daten einer Gemeinde im LDM vorliegen, sind sie bezüglich der als,ungetrennte Hofräume bezeichneten Sonderfälle zu überarbeiten. Anschließend werden die Daten dieser Gemeinde im NAS-Format aus dem LDM ausgelesen und zur DHK geschickt, so dass sich die DHK gemeindeweise füllt. Sobald von der DHK die Quittierung für das jeweilige Einlesen der Daten eingegangen ist, kann in ALKIS wieder mit der Fortführung des Liegenschaftskatasters begonnen werden. Als erstes sind jedoch die übrigen,sofortigen Nacharbeiten (Bildung der TN,Bergbau, Bereinigung der Grenzen von Sanierungsgebieten) anzupacken. Der vorstehend beschriebene Weg, der eine recht schnelle Wiederaufnahme des Fortführungsbetriebes beschreibt, soll aber erst beschritten werden,

44 Migration nach ALKIS wenn sich herausgestellt hat, dass die Datenübertragung vom LDM zur DHK einwandfrei klappt. Aus diesem Grund soll bei allen drei Modellen abgewartet werden, ob die Daten des ersten AfB richtig und vollständig in der DHK übernommen sind, bevor wieder Fortführungen aufgenommen werden. Nach unseren Migrationsregeln wird die Gesetzliche Klassifizierung,Straße nicht aus dem Liegenschaftskataster, sonders aus ATKIS migriert. Diese gesonderte Migration wird für die Ämter zentral im HLBG ausgeführt. 5 Weitere Gesichtspunkte zur Produktionsmigration Das Migrationskonzept enthält noch weitere Aussagen, zum Beispiel zu Anforderungen an den Personaleinsatz während der Migration, zu weiteren organisatorischen Fragen bei der Migration, zur EQK-Schulung für rund 500 Bedienstete der Ämter, zur Zusammenarbeit mit den Vermessungsstellen und zur Archivierung der Altsysteme. Diese Punkte sollen aber hier nicht weiter dargestellt werden. 43

45 Transformation in das Lagebezugssystem ETRS89/UTM Transformation in das Lagebezugssystem ETRS89/UTM Bernhard Heckmann 44 1 Einführung des Lagestatus 100 Vor der Migration nach ALKIS wurden die digitalen geometrischen Nachweise des Liegenschaftskatasters die ALK-Punktdatei und die ALK- Grundrissdatei gemarkungsweise durch das Angleichungsverfahren Homogenisierung großer Punktmengen vom spannungsbehafteten hessischen Lagestatus 120 bzw. 110 (Potsdam-Datum mit Bessel-Ellipsoid und Gauß-Krüger- Abbildung) in den spannungsfreien hessischen Lagestatus 100 (homogenes Landesnetz auf gleicher geodätischer Basis) überführt. Anschließend wurden auch die Grenzen der Datenbanken geometrisch harmonisiert, so dass die digitale Liegenschaftskarte mit Punkt- und Grundrissdatei danach landesweit einheitlich im Lagestatus 100 vorliegt. LGS im Lagestatus 120 bzw. 110 LGS im Lagestatus 100 Die Lagequalität der Katasterpunkte (KP) wurde dabei jedoch nicht flächenhaft verbessert, sondern bestenfalls erhalten. Daneben ist zu beachten, dass die Lagegenauigkeitsstufe (LGS) im landesweit homogenen Lagestatus 100 eine Art absolute Lagegenauigkeit beschreibt, und zwar bezogen auf die SAPOS-Referenzstationen und die HREF-Punkte. Dagegen gibt die LGS im spannungsbehafteten Lagestatus 120 bzw. 110 nur eine relative Lagegenauigkeit wieder, bezogen auf die Koordinaten der nächstgelegenen TP oder AP. Diese unterschiedliche Wertigkeit der LGS wurde beim Übergang zum Lagestatus 100 im Sinne einer Qualitätssicherung wie folgt berücksichtigt: Für alle KP, die nicht im Lagestatus 100 neu bestimmt oder mit alten Messungselementen neu gerechnet worden sind, wurden die im früheren Lagestatus 120 nachgewiesene LGS 1 4 vorsorglich in die LGS D F überführt. Die Konvertierungsregeln für die LGS der durch Angleichung in den Lagestatus 100 überführten KP sind nachstehend tabellarisch wiedergegeben: A B C D D E F A B C Im Lagestatus 100 werden KP-Koordinaten der LGS D F zwar bei jeder sich bietenden Gelegenheit überprüft (vor allem anlässlich von Liegenschaftsvermessungen) und danach wieder in die LGS 1 4 eingestuft. Bei der Migration der Punkt- und Grundrissdaten liegt dennoch das gesamte LGS-Spektrum (LGS 1 4, LGS A C und LGS D F) im Lagestatus 100 vor, welches in ALKIS-konforme Qualitätsangaben umgesetzt werden muss. Näheres dazu wird noch in Abschnitt 2 ausgeführt. 2 Transformation des Lagestatus 100 nach ETRS89/UTM Die Koordinaten des hessischen Lagestatus 100 sind hinreichend homogen und können daher landesweit mit einem einzigen Algorithmus in UTM-Koordinaten des geometrisch gleichwertigen ETRS89 umgerechnet werden. Hierzu ist allerdings ein räumlicher Transformationsansatz mit 7 Parametern (3 Translationen, 3 Rotationen und 1 Maßstabsfaktor) erforderlich. Außerdem müssen bei der Transformation für alle KP genäherte ellipsoidische Höhen vorliegen, wobei ein Höhenfehler von 100 m etwa 2 mm Lagefehler verursacht. Deshalb werden für alle zu transformierenden KP Höhenwerte aus dem Digitalen Geländemodell (DGM) konkret dem DGM 50 mit 100 m Rasterweite - interpoliert. Die aus dem DGM 50 ermittelten NHN-Höhen können dabei unmittelbar als ellipsoidische Höhen weiterverwendet werden, da die Höhenanomalie bezogen auf das Bessel-Ellipsoid in Hessen weniger als +/- 3 m beträgt und in diesem Zusammenhang vernachlässigt werden kann. Als Passpunkte für die Ermittlung der Transformationskonstanten dienen die 77 Punkte des HREF-Netzes sowie weitere 3 Punkte außerhalb Hessens. Die Lagestatus 100 Koordinaten der 77 HREF- Punkte beruhen auf der Berechnung von 1993, die 3 zusätzlichen Passpunkte wurden später bestimmt. Mit Hilfe von

46 Transformation in das Lagebezugssystem ETRS89/UTM ellipsoidischen Höhen, die aus der Digitalen Finite Elemente Höhenbezugsfläche Hessen (DFHBF-H3) abgeleitet wurden, und den Parametern des Bessel-Ellipsoides lassen sich daraus die räumlichen kartesischen Koordinaten (X, Y, Z) des Startsystems (Potsdam-Datum / DHDN) ermitteln. Die kartesischen Koordinaten (X, Y, Z ) der Passpunkte im Zielsystem ETRS89 beruhen letztendlich auf der bundesweiten Diagnoseausgleichung der SAPOS-Referenzstationen, die 2002/2003 durchgeführt worden ist und deren Ergebnisse anschließend auf die 77 HREF-Punkte und die 3 weiteren Passpunkte übertragen wurden. Aus den 80 Passpunkten wurden im August 2007 die nachstehenden endgültigen Parameter für die Transformation von Lagestatus 100 nach ETRS89 ermittelt: Verschiebungen (Translationen) Drehungen (Rotationen) * DX + 584,8095 m ßx + 0, DY + 71,2415 m ßy + 0, DZ + 401,6035 m ßz - 2, Maßstabsfaktor M Maßstabsverbesserung dm 1, , ppm * Hinweis: In Abhängigkeit von der weiterverarbeitenden Software sind die Vorzeichen der Rotationen ggf. umzukehren! Bei dieser Transformation treten in den 80 Passpunkten (räumliche) Restklaffungen auf, die in der Lage bis zu 39 mm erreichen (innerhalb Hessens bis zu 29 mm). Diese Restklaffungen beschreiben die landesweit noch verbliebenen Inhomogenitäten zwischen dem 1993 entstandenen Lagestatus 100 und der aktuellen Koordinierung des ETRS89. Zur Wahrung der Nachbarschaftstreue der transformierten Koordinaten zu den Passpunkten im Zielsystem ETRS89 müssen diese Restklaffungen verteilt werden. Da die 80 Passpunkte im Süden Hessens keine optimale Randabdeckung aufweisen, die für eine multiquadratische Interpolation notwendig wäre, wurde die einfachere Restklaffenverteilung nach Abstandsgewichten 1/s² gewählt. Diese liefert auch für den betreffenden Randbereich noch gute und vor allem plausible Interpolationsergebnisse. Aus den nach der Restklaffenverteilung erhaltenen kartesischen X, Y, Z Koordinaten im ETRS89 werden für die KP zunächst geographische Koordinaten B, L auf dem GRS80- Ellipsoid ermittelt (GRS80 = Geodetic Reference System 1980). Daraus werden dann die ebenen UTM-Koordinaten East (E) und North (N) in der 32. Zone (Mittelmeridian 9 östl. Greenwich) berechnet und in ALKIS gespeichert. Die aus dem DGM 50 interpolierten NHN-Höhen der KP werden nicht nach ALKIS übernommen. Für die Punktobjekte werden aus der im Lagestatus 100 nachgewiesenen LGS die neuen Qualitätsangaben Herkunft (DPL), Genauigkeitsstufe (GST) und Vertrauenswürdigkeit (VWL) wie folgt festgelegt und entsprechend nach ALKIS migriert (mit sp = Standardabweichung der Punktlage): 45

47 Transformation in das Lagebezugssystem ETRS89/UTM LGS DPL GST VWL Wert Bedeutung Wert Bedeutung Wert Bedeutung gerechnet 2000 sp 2 cm gerechnet 2100 sp 3 cm gerechnet 3000 sp 30 cm gerechnet 3000 sp 30 cm 1300 A 4200 digitalisiert 3100 sp 60 cm 1400 B 4200 digitalisiert 3000 sp 30 cm 1400 C 4200 digitalisiert 3200 sp 100 cm 1400 D 1000 gerechnet 2200 sp 6 cm 1300 E 1000 gerechnet 3000 sp 30 cm 1300 kontrollierte Berechnung kontrollierte Berechnung kontrollierte Berechnung kontrollierte Bestimmung nicht kontrolliert nicht kontrolliert nicht kontrolliert kontrollierte Bestimmung kontrollierte Bestimmung F 1000 gerechnet 3000 sp 30 cm nicht belegt Anhand dieser Zuordnungstabelle können auch die ursprünglichen LGS bei Bedarf wieder rückwärts und eindeutig aus den künftigen ALKIS-Attributen ermittelt werden. 3 Rücktransformation des ETRS89/UTM nach Lagestatus 100 Für die Rücktransformation des ETRS89 in den hessischen Lagestatus 100 wurden aus den in Abschnitt 2 genannten 80 Passpunkten ebenfalls im August 2007 die folgenden Parameter ermittelt: Verschiebungen (Translationen) Drehungen (Rotationen) * DX - 584,8032 m ßx - 0, DY - 71,2479 m ßy - 0, DZ - 401,5990 m ßz + 2, Maßstabsfaktor M Maßstabsverbesserung dm 0, , ppm * Hinweis: In Abhängigkeit von der weiterverarbeitenden Software sind die Vorzeichen der Rotationen ggf. umzukehren! 46

48 Transformation in das Lagebezugssystem ETRS89/UTM Damit können ETRS89/UTM- Koordinaten nach Umwandlung in kartesische 3-D-Koordinaten (X, Y, Z ) wieder in das System des hessischen Lagestatus 100 zurück transformiert werden. Für die umzuformenden Punkte werden die erforderlichen ellipsoidischen Höhen über dem GRS80 wiederum aus dem DGM 50 interpoliert, wobei zu den dabei erhaltenen NHN-Höhen noch die mittlere Höhenanomalie für das GRS80- Ellipsoid addiert werden muss, die in Hessen + 47 m beträgt. Nach der Transformation treten in den 80 Passpunkten die gleichen räumlichen Restklaffungsbeträge wie bei der Hintransformation auf, nur mit umgekehrten Vorzeichen. Diese Restklaffungen werden dann ebenfalls nach Abstandsgewichten 1/s² auf die transformierten Punkte verteilt. Aus den nach der Restklaffenverteilung erhaltenen kartesischen X, Y, Z Koordinaten im Potsdam-Datum / DHDN werden für die KP zunächst geographische Koordinaten B, L auf dem Bessel-Ellipsoid ermittelt. Daraus werden dann die ebenen Gauß-Krüger- Koordinaten Rechts (R) und Hoch (H) im hessischen Lagestatus 100 berechnet (3. Meridianstreifen, Mittelmeridian 9 östl. Greenwich). 4 Transformationstool Die Algorithmen für die Hinund Rücktransformation (einschließlich der Höheninterpolation der umzuformenden Punkte aus dem DGM 50, der Restklaffenverteilung nach Abstandsgewichten 1/s² sowie der Umrechnung der kartesischen 3-D-Koordinaten in die jeweilige Abbildung) ist in einem Transformationstool realisiert, das vom Ingenieurbüro Riemer (ibr) für die Hessische Verwaltung für Bodenmanagement und Geoinformation (HVBG) entwickelt wurde. Dieses Werkzeug wird allen Nutzern von hessischen Geobasisdaten als geschlossene Softwarelösung unter der Bezeichnung,Landeseinheitlicher Transformationsansatz Hessen (LET-Hessen) kostenfrei zur Verfügung gestellt. Mit LET-Hessen können alle Koordinatenumrechnungen vom hessischen Lagestatus 100 nach ETRS89/UTM (Zone 32) und zurück einheitlich, konsistent und millimetergenau ausgeführt werden. Da die Ergebnisse aber nur auf volle Millimeter angegeben werden (im Sinne des geometrischen Millimetermodells in ALKIS), kann es bei der Hin- und Rücktransformation desselben Punktes im Einzelfall zu Rundungsdifferenzen von maximal 1 mm pro Koordinate kommen. Dies muss bei der künftigen Anwendung dieses Transformationstools berücksichtigt werden. LET-Hessen wird allerdings nur einfache Ein- und Ausgabeformate für die umzuformenden Koordinaten unterstützen (z.b. ASCII). Die Transformation von Koordinaten, die in komplexeren Datenformaten (z. B. NAS) bereitgestellt werden, geht über diese Kernfunktion hinaus und erfordert entsprechende Erweiterungen. LET-Hessen wird von ibr in die hessische Migrations-Software für ALKIS integriert, so dass die Positionen aller digitalen Daten des Liegenschaftskatasters bei der Migration von den bisherigen Gauß-Krüger-Koordinaten des Lagestatus 100 in UTM-Koordinaten (Zone 32) des ETRS89 umgerechnet und entsprechend in ALKIS eingespeichert werden können. Somit werden die Daten des Liegenschaftskatasters in ALKIS von Beginn an und ausschließlich im zukunftsorientierten bundesweit einheitlichen Lagebezugssystem ETRS89/UTM geführt. 5 Abschlussbemerkungen Die Entwicklung und kostenfreie Bereitstellung des in Abschnitt 4 genannten Transformationstools LET-Hessen durch die HVBG hat zur der Entscheidung geführt, in ALKIS nur noch das Lagebezugssystem ETRS89/UTM nachzuweisen und auf die Parallelführung von Gauß-Krüger-Koordinaten des hessischen Lagestatus 100 in den Punktobjekten zu verzichten. Ausgaben im bisherigen Lagestatus 100 werden somit ausschließlich bedarfsweise erzeugt, wobei die Lagekoordinaten mit Hilfe des LET-Hessen aus den in ALKIS gespeicherten ETRS89/UTM-Koordinaten berechnet werden. Liegenschaftsvermessungen und sonstige georeferenzierte Datenerhebungen für ALKIS werden zukünftig unmittelbar im ETRS89/UTM erfolgen. Dabei wird sich der Einsatz des hochpräzisen Echtzeit-Positionierungsservice des SAPOS (SAPOS-HEPS) deutlich vereinfachen, weil die dabei unmittelbar erzeugten Koordinaten bereits im Referenzsystem ETRS89 definiert sind und keine großräumige Restklaffenverteilung auf die HREF-Punkte mehr anfällt, wie das bei der Einpassung in den hessischen Lagestatus 100 noch erforderlich ist. Sofern man auch zukünftig noch Gauß-Krüger-Koordinaten im hessischen Lagestatus 100 aus SAPOS-Messungen für das Liegenschaftskataster oder für darauf referenzierte Fachanwendungen erzeugen möchte, ist dazu stets das in Abschnitt 4 beschriebene Transformationstool LET-Hessen einzusetzen, mit dem eine landesweit einheitliche Verfahrensweise gewährleistet wird. 47

49 Einrichtung und Führung von AFIS Einrichtung und Führung von AFIS Bernhard Heckmann 48 1 Inhalt von AFIS In AFIS sind folgende Punktarten der Landesvermessung modelliert: Lagefestpunkte (LFP), Höhenfestpunkte (HFP), Schwerefestpunkte (SFP) und Referenzstationspunkte (RSP). Zu diesen 4 Kategorien werden in AFIS die Objekte Punktort, ggf. Schwerewert und Skizze (Punktbeschreibung) nachgewiesen. Unter Skizze kann jedoch nur der Dateiname als Fundstelle angegeben werden (z. B. ein Unified Resource Identifier, kurz URI). Identitäten zwischen LFP, HFP und SFP werden über Relationen dargestellt. Punktorte und Schwerewerte können multipel geführt werden, so dass sich in AFIS verschiedene Lage-, Höhen-, Schwere- oder 3-D-Referenzsysteme nachweisen lassen. Darüber hinaus werden für diese Angaben auch die zugehörigen Metainformationen zur Datenqualität Punktort (Herkunft DPL für Lage- und Höhenangaben bzw. Datenerhebung DES für Schwerewerte, Genauigkeitsstufe GST, Genauigkeitswert GWT und Vertrauenswürdigkeit VWL) gespeichert. Festpunktübersichten gehören nicht zum Inhalt von AFIS und sind daher gesondert zu realisieren. Die Festpunktbeschreibungen (Skizzen) werden digital geführt und können weiterhin mit dem Programm SIPView bearbeitet werden. (SIP = Software Image Pro). 2 Migration der Festpunktdaten Die Lagefestpunkte werden im Hessischen Landesamt für Bodenmanagement und Geoinformation (HLBG) zurzeit in einer Superbase-Datenbank, die Höhen- und Schwerefestpunkte in einer Access-Datenbank geführt. Vor der Migration wird der Inhalt der Superbase- Datenbank in eine Access- Datenbank übernommen, so dass alle Lage-, Höhen- und Schwerefestpunkte einheitlich von dort nach AFIS migriert werden können. Während des Migrationsvorgangs werden die Festpunktdaten noch durch ergänzende Informationen aus anderen Datenquellen angereichert (z. B. Gemeindename, Name der zuständigen Katasterbehörde). Die digitalen Punktskizzen werden nicht migriert, sondern bleiben weiterhin als Bilddatei in gesonderten Verzeichnissen gespeichert. Sie sind dort TK25-blattweise unter der jeweiligen Festpunktnummer (= Dateiname) abgelegt. Bei der Migration werden Pfadund Dateiname nach AFIS in das Objekt Skizze übernommen. Im Gegensatz zu ALKIS, wo für jedes Punktobjekt nur ein Lagebezugssystem (nämlich ETRS89/UTM) und ggf. ein Höhenbezugssystem (nämlich NHN-Höhen im DHHN92) gespeichert wird, sollen in AFIS für die Festpunkte der Landesvermessung mehrere geodätische Referenzsysteme parallel nachgewiesen werden.

50 Einrichtung und Führung von AFIS Abbildung - Koordinatenreferenzsysteme in Hessen 3 Einrichtung, Führung und Verwendung von AFIS AFIS wird im HLBG auf einem Lokalen Datenmanagement (LDM) implementiert und durch das Dezernat Geodätischer Raumbezug geführt. Parallel dazu wird AFIS auf der AAA- Datenhaltungskomponente (DHK) mit Auskunfts- und Präsentationskomponente (APK) eingerichtet, aus der amtliche Ausgaben erstellt werden können. Der Inhalt der DHK/ APK wird dabei täglich aus dem LDM heraus mittels NBA- Verfahren aktualisiert (NBA = Nutzerbezogene Bestandsdaten-Aktualisierung). Die Punktbeschreibungen (Skizzen) werden weiterhin digital auf der Lokalen Datenhaltung abgelegt und mit SIPView bearbeitet. Daneben sollen die digitalen Skizzen auch im Umfeld der DHK (z.b. in SIPGIS-Web) gespeichert werden, damit sie dort (ggf. separat) abgerufen bzw. genutzt werden können. Die amtlichen Standardausgaben aus AFIS das sind Einzelnachweise und Punktlisten sollen grundsätzlich aus der DHK/APK heraus erstellt werden. Hierzu müssen außerdem geeignete digitale Übersichten für Lage-, Höhenund Schwerefestpunkte bereitgestellt werden, anhand derer eine grafische Navigation und Selektion der gewünschten Festpunkte erfolgen kann. Die verschiedenen Punktarten sollen dabei mit unterschiedlichen Symbolen gekennzeichnet sein, und auch die Punktkennung muss präsentiert werden. 49

51 Einrichtung und Führung von AFIS 50 Die Festpunktübersicht (FPÜ) enthält standardmäßig den Blattschnitt der TK 25, dem Nummerierungsbezirk der LFP, HFP und SFP. Neben der DTK25 sollen aber auch andere Hintergrundgrafiken gewählt werden können, z.b. Digitale Orthophotos, Präsentationsgrafiken aus den ATKIS-DLMs oder die Liegenschaftskarte. Die Einbindung der Skizzen in die Einzelnachweise ist noch nicht realisiert. Hier muss möglicherweise eine pragmatische Zwischenlösung in Kauf genommen werden. Dabei ist angedacht, dass die AFIS-Nutzer die gewünschten Skizzen anhand der Punktart (LFP, HFP oder SFP) und der Punktkennungen (die aus AFIS oder der FPÜ entnommen werden) selbst manuell aus SIPGIS-Web selektieren. Die ausgewählten Skizzen- Dateien können dann zur weiteren Nutzung heruntergeladen bzw. ausgedruckt werden. Eine zweite Option wäre, Einzelnachweise mit Skizzen übergangsweise als Bestellprodukte durch das HLBG zu erzeugen. Eine abschließende Aussage dazu ist derzeit noch nicht möglich. Ziel bleibt aber weiterhin, Einzelnachweise mit integrierter Skizze unmittelbar aus der DHK/APK heraus zu produzieren und online bereitzustellen. Punktlisten können dagegen sofort aus der DHK/APK erstellt werden. Zusätzliche hessenspezifische Ausgaben aus AFIS sind bislang nicht vorgesehen. 4 Erhebung und Qualifizierung von Festpunktdaten Zur Fortführung der Festpunktdaten im LDM wird der AAA-Desktop mit dem AFIS- Editor eingesetzt. Der AFIS- Editor enthält alle Funktionen zum Einfügen, Verändern und Löschen (bzw. Historisieren) von Festpunktdaten. Die Geschäftsprozesse zur Erhebung, Qualifizierung und Fortführung von AFIS-Bestandsdaten sind dabei an den entsprechenden ALKIS-Prozessen orientiert (vgl. Adam Geschäftsprozessmodell Hessen ). Die Erhebungsarbeiten erfolgen im Wesentlichen durch die Ämter für Bodenmanagement, durch das HLBG selbst oder durch externe Stellen, die vom HLBG beauftragt worden sind. Die Zuständigkeit für die Fortführung von AFIS obliegt jedoch dem Dezernat Geodätischer Raumbezug im HLBG. Die in der Grundlagenvermessung bislang verwendeten und bewährten geodätischen Auswerteprogramme (insbesondere PAGEWIN für Lage- und 3-D-Bestimmungen, LINIV für Nivellements, TRANSID für Koordinatentransformationen und TTC (Trimble Total Control) zum Postprocessing von GNSS-Messungen) bleiben

52 Einrichtung und Führung von AFIS im Erhebungsprozess bis auf weiteres im Einsatz. Für die Kommunikation mit AFIS werden im AFIS-Editor entsprechende Import- und Exportfunktionen bereitgestellt, so dass die benötigten Daten bequem aus dem AFIS-LDM in die Auswerteprogramme übernommen und die Ergebnisse wieder in den AFIS-Editor zurückgegeben werden können. Erhebungsdaten der Ämter für Bodenmanagement oder anderer Stellen werden in den AAA-Desktop importiert und dort mit dem AFIS-Editor bis zur Erstellung des AFIS- Fortführungsentwurfs weiterbearbeitet. Der AFIS-Fortführungsentwurf wird im HLBG vom Dezernat Geodätischer Raumbezug nach dem 4- Augen-Prinzip unabhängig geprüft (qualifiziert) und endet im Regelfall in einer Fortführungsentscheidung. Nach der Fortführung von AFIS im LDM wird in der darauf folgenden Nacht auch die DHK/APK über das NBA-Verfahren aktualisiert. Die Bearbeitung von Festpunktskizzen erfolgt weiterhin mit SIPView. Die synchrone Fortführung der Punktskizzen mit AFIS soll nach Möglichkeit über den AFIS-Editor gesteuert werden, mit dem auch der AFIS-Fortführungsentwurf qualifiziert wird. Skizzen können auch separat fortgeführt werden, wenn ansonsten keine Daten in AFIS geändert werden brauchen (auch kein Dateiname für die Skizze). 5 Ausblick Nach der Einrichtung von AFIS sollen Weiterentwicklungen für die Standardausgaben aus der DHK/APK erfolgen, und zwar insbesondere für den Einzelnachweis mit Skizze. Des Weiteren steht in Hessen die Umstrukturierung der bisherigen Festpunktfelder der Landesvermessung in multifunktionale Festpunkte bei gleichzeitiger Reduzierung der Punktanzahl bevor. Dabei gewinnen die Identitätsrelationen in AFIS eine zunehmende Bedeutung, was sich auf die Nachweise einschließlich der Skizzen und FPÜs entsprechend auswirkt. Ob dafür auch neue hessenspezifische Ausgaben aus AFIS (sowohl Einzelnachweise als auch Punktlisten) konzipiert werden müssen, kann derzeit noch nicht beurteilt werden. Darüber hinaus ist mit technisch-wissenschaftlichen Fortentwicklungen in den geodätischen Referenzsystemen (z. B. neues Datum für Höhe und Schwere, Nachweis von zeitlichen Veränderungen) zu rechnen, die dann ggf. zusätzlich in AFIS zu führen wären. Des Weiteren muss auch der Softwaremarkt im Bereich der geodätischen Ausgleichungsprogramme für Lage-, Höhen-, Schwere- oder 3-D- Bestimmungen beobachtet werden. Vielleicht sind in Zukunft Berechnungsprogramme verfügbar, die unmittelbar auf dem AFIS-Modell aufsetzen und direkt in den AAA-Desktop bzw. in den AFIS-Editor integriert werden können. Auch hier darf man sicherlich noch interessante Weiterentwicklungen erwarten. 51

53 ATKIS - MIgration und Modellierung im AAA-Modell ATKIS - Migration und Modellierung im AAA-Modell Karl-Heinz Kullmann 52 1 Einleitung Das gemeinsame Datenmodell für die drei Geobasisdatenbestände AFIS, ALKIS und ATKIS sowie die gemeinsame Führung in der Datenhaltungskomponenten (DHK) machen eine Migration der ATKIS- Daten vom alten Modell in das neue AAA-Modell erforderlich. Im Gegensatz zur ALK/ALB- Migration nach ALKIS liegen die bestehenden ATKIS- Daten bereits in einer ähnlichen Struktur vor, wie sie auch im AAA-Modell benötigt wird. Sie sind als Objekte modelliert. Jedes Objekt (OJ) besteht aus mindestens einem Objektteil (OT). Im AAA-Modell werden die Daten als raumbezogene Elementarobjekte (REO) oder als zusammengesetzte Objekte (ZUSO) modelliert. Ein ZUSO muss immer aus mindestens einem REO bestehen. Ein REO kann als Teil eines ZUSO oder als eigenständiges Objekt existieren. Ein ZUSO entspricht im alten Modell dem Objekt (OJ), ein REO dem Objektteil (OT). Trotz dieser großen Gemeinsamkeit zwischen altem und neuem Modell ist die Migration auch in ATKIS ein aufwendiger Prozess, der nicht einfach auf Knopfdruck durchgeführt werden kann. 2 Migrationsprozess Die Migration des ATKIS-Basis- DLM in das AAA-Modell erfolgt in Hessen nach Fertigstellung der 3. Aufbaustufe (Basis- DLM/3). Grundlage für die Migration bildet eine von der AdV erarbeitete und bundesweit gültige Migrationstabelle, die auf hessische Gegebenheiten angepasst wurde. Sie wird bei jedem GeoInfoDok- Versionswechsel nachgezogen. In der Tabelle ist für jede Objektart und jedes Attribut festgelegt, wohin es im AAA- Modell überführt wird. In Hessen wird für die Migration der Daten die Software,3A Migration ATKIS der Firma AED SICAD - zurzeit in der Version eingesetzt. Seit Herbst 2006 werden Test- und Probemigrationen durchgeführt. Testmigrationen dienen der Prüfung und Weiterentwicklung des Migrationstools durch einen eigens hierfür aufgebauten fiktiven Testdatenbestand. Dieser Testdatenbestand umfasst alle in Hessen vorkommenden Objektarten, Attribute und Relationen. Parallel zu den Testmigrationen werden auch umfangreiche Probemigrationen mit Realdaten vorgenommen. Dadurch können verlässliche Angaben bezüglich der Performance des Migrationsprozesses sowie der Qualität der Ausgangsdaten ermittelt werden. Fehler werden in Form von Protokollen ausgegeben. Sie werden entweder in einer sogenannten,vormigration in den Ausgangsdaten bereinigt oder erst nach der eigentlichen Migration im AAA- Modell korrigiert. Der Migrationsprozess läuft in mehreren Teilprozessen ab: Vorarbeiten Die Migration erfolgt nicht in einem Durchlauf über die gesamte Landesfläche, sondern sukzessive über Teilgebiete (Pakete) von ca. 500 qkm Größe. Die ATKIS-Basis-DLM- Daten liegen gekachelt in einer Datenbank. Objekte enden am Kachelrand. Eine Kachel ist 6 mal 6 km groß. Die gesamte Landesfläche besteht aus 630 Kacheln. Sie wird zur Migration aus Performancegründen in 42 Pakete zu je 15 Kacheln zusammengefasst. Migration der Daten Dieser Teilprozess ist der aufwendigste und besteht je nach Objektart aus mehreren Arbeitsschritten. Bei manchen Objektarten reicht eine einfache Überführung aus (Objekt 1 der Objektart XY wird zu Objekt 11 der Objektart AB), bei anderen sind zusätzliche komplexe Verschneidungen erforderlich. Manchmal müssen aus linienförmigen Objekten flächenförmige erzeugt und Relationen neu aufgebaut werden. Abbildung 1 zeigt eine Verschneidungsoperation, die innerhalb des Migrationsprozesses durchzuführen ist. Im alten Modell ist das Objekt,Umspannstation als Überlagerungsfläche modelliert. Im AAA-Modell ist Umspannstation kein Objekt, sondern ein Attribut beim Objekt,Industrieund Gewerbefläche. Da diese Objektart im Objektartenbereich,Tatsächliche Nutzung angesiedelt ist, wird aus der ehemaligen Überlagerungsfläche des ATKIS-Basis-DLM im AAA-Modell eine Grundfläche.

54 ATKIS - MIgration und Modellierung im AAA-Modell Abbildung 1 - Migration eines überlagernden Objektes in ein Objekt der Tatsächlichen Nutzung Migration von Verknüpfungen zwischen Basis-DLM-Objekten und DTK25-Objekten Im alten Datenmodell liegen große Teile des DTK25- Datenbestandes bereits als Vektordaten vor. Sie sind über die Objektteilnummer mit den zugehörigen Basis-DLM- Objektteilen verknüpft. Diese Verknüpfungen müssen im AAA-Modell erhalten bleiben. Die (alte) Objektteilnummer wird deshalb bei jedem REO im Attribut zeigtaufexternes temporär gespeichert. Nach der Migration der DTK25- Daten kann daraus die Relation istabgeleitetaus für das Kartengeometrieobjekt abgeleitet werden. Koordinatentransformation von Gauß-Krüger nach ETRS 89/UTM Zusätzlich zu den Überführungen der einzelnen Objekte erfolgt die Transformation der Koordinaten von Gauß-Krüger nach ETRS 89/UTM mit einem bundesweiten Transformationsansatz. Hierzu wurde die Erweiterungskomponente,3A Migration ATKIS-NTv2 als Add-On zum Migrationstool,3A Migration ATKIS beschafft. Erzeugen der Blattschnittfreiheit Wie unter 1. Vorbereitungen bereits erwähnt, sind die ATKIS-Basis-DLM-Daten nicht blattschnittfrei, sondern enden am Kachelrand. Innerhalb des paketweisen Migrationsprozesses werden die Objekte an den inneren Kachelrändern vereinigt. In den Abbildungen 2 und 3 ist beispielhaft aufgezeigt, wie die Erzeugung der Blattschnittfreiheit der Daten abläuft. 53

55 ATKIS - MIgration und Modellierung im AAA-Modell Vorher Abbildung 2 - Vor der Migration enden die Objekte am Kachelrand Nachher Abbildung 3 - Nach der Migration sind die Daten blattschnittfrei 3 Modellierung im AAA-Modell 54 Im AAA-Modell werden innerhalb der ATKIS-Produktpalette neben den Digitalen Landschaftsmodellen (DLM) auch die Digitalen Topographischen Karten (DTK) vektororientiert geführt. Die Datenbestände werden Modellarten zugeordnet. Ein Objekt wie z. B. eine Straße kann zu beliebig vielen Modellarten gehören. Jedes Produkt erhält eine eigene Modellartenkennung (MAT). Daraus ergibt sich, dass die Daten des Basis-DLM bzw. des DLM50 und die daraus abgeleiteten Daten der DTK25 bzw. der DTK50 nach gleichen Regeln bearbeitet werden können. Objekte, die beispielsweise in der DTK25 die gleiche Geometrie aufweisen

56 ATKIS - MIgration und Modellierung im AAA-Modell wie im Basis-DLM, werden nur einmal gespeichert. Diese Objekte erhalten zwei Modellartenkennungen (siehe Abbildung 4, Objekt 1 hat die Modellartenkennung MAT = Basis-DLM und MAT = DTK25). Weist ein Objekt in der DTK25 eine andere Geometrie auf als im Basis-DLM, werden beide Objekte gespeichert. Das eine Objekt trägt die Modellartenkennung MAT = Basis-DLM, das andere MAT = DTK25 (siehe Abbildung 4, Objekte 2 und 3). Abbildung 4 - Objekte und Modellarten Objekt 3 ist ein kartographisch generalisiertes Objekt, ein sogenanntes Kartengeometrieobjekt. Jedes Kartengeometrieobjekt ist über die Relation,istAbgeleitetAus mit den zugehörigen DLM-Objekten verknüpft. Neben den Kartengeometrieobjekten gibt es noch Präsentationsobjekte, die ebenfalls die Modellartenkennung MAT = DTK25 bzw. MAT = DTK50 tragen. Bei den Präsentationsobjekten handelt es sich um Texte oder Symbole. Sie sind über die Relation,dientZurDarstellungVon mit den zugehörigen DTK-Objekten verbunden (siehe Abbildung 5). Abbildung 5 - Modellierung im AAA-Modell 55

57 Synergien zwischen ALKIS und ATKIS im AAA-Modell Synergien zwischen ALKIS und ATKIS im AAA-Modell Mario Friehl, Karl-Heinz Kullmann, Reinhard Limmert 56 1 Einleitung Das gemeinsame Datenmodell der drei Geobasisdatenbestände AFIS, ALKIS und ATKIS, das AAA-Modell, und die gemeinsame Führung in der DHK fordern geradezu heraus, dass für deren Fortführung nach Synergien gesucht wird. Im Folgenden soll dargestellt werden, welche Synergieeffekte bei der Erhebung neuer Daten zur Fortführung von ALKIS und ATKIS in der HVBG erwartet werden. 2 Allgemeines zu den Synergien ALKIS / ATKIS Vergleicht man ALKIS und ATKIS miteinander, dann erkennt man schnell, dass Gebäude, Bauwerke, die Tatsächliche Nutzung (TN) sowie öffentlichrechtliche und gesetzliche Festlegungen in beiden Datenbeständen geführt werden. Infolgedessen muss bei diesen Objektartenbereichen untersucht werden, inwieweit Synergien hergestellt werden können. Bei den Gebäuden werden Synergiegewinne dadurch erzielt, dass Gebäude nur noch durch die dafür gesetzlich zuständigen Vermessungsstellen erhoben werden. Das für das Liegenschaftskataster erhobene Gebäude wird in der gemeinsamen Datenhaltung mehrfach genutzt: in der DHK ist das Gebäude zwar nur einmal gespeichert, es steht aber über entsprechende Modellartenkennungen für beide Informationssysteme (ALKIS und ATKIS) zur Verfügung. Im Liegenschaftskataster werden unter der Kategorie Bauwerke im Wesentlichen nur noch der Turm, die Brücke und der Durchlass geführt. Diese Objekt- bzw. Wertearten benötigt auch ATKIS. Synergien lassen sich bei diesen Bauwerken dadurch gewinnen, dass sie wie die Gebäude nur noch für das Liegenschaftskataster erhoben und dann von beiden Informationssystemen genutzt werden. Wegen der unterschiedlichen Geometrie (in ALKIS flächenförmige und in ATKIS punkt- bzw. linienförmige Objekte) ist aber keine gemeinsame Datenhaltung möglich. Ähnlich verhält es sich mit der Tatsächlichen Nutzung. Für die TN sind eine gemeinsame Erhebung und eine gemeinsame Weiterverwendung vorgesehen. Eine gemeinsame Datenhaltung scheidet wie bei den Bauwerken wegen der unterschiedlichen Geometrie aus: in ATKIS sind die Verkehrswege (Straßen, Wege, Eisenbahnen) und Gewässer in aller Regel linienförmige Objekte, während sie in ALKIS immer flächenförmig sind. 3 Gemeinsame Erhebung der TN für ALKIS und ATKIS Gemeinsame Erhebung bedeutet, dass die TN jeweils nur von einer Stelle erhoben wird und dass die neu gewonnenen Informationen an die jeweils anderen Stellen abgegeben werden. Die Synergie besteht also darin, dass die TN nur noch einmal erhoben, aber gemeinsam von ALKIS und ATKIS genutzt wird. Bei der Erhebung der TN treten zwei unterschiedlich gelagerte Regelfälle auf: Im Rahmen von Katasterarbeiten (z. B. Zerlegungsvermessungen, Grenzfeststellungen, Gebäudeeinmessungen) werden fortlaufend Nutzungsartenänderungen festgestellt. Diese finden unmittelbar Eingang in ALKIS, müssen aber auch an ATKIS abgegeben werden. Dieser Fall wird,punktuelle Aktualisierung genannt. Er spielt sich überwiegend in der Ortslage ab. Vor allem im Außenbereich finden turnusmäßig topographische Arbeiten statt, bei denen die TN flächendeckend aktualisiert wird, und zwar in unterschiedlichen Zeitabständen, die abhängig von der Bedeutung der einzelnen Objekte von fünf Jahren bis zu einer Spitzenaktualisierung von drei Monaten für Straßen reichen. Bei dieser,flächendeckenden Aktualisierung wird die TN für ATKIS erhoben und an ALKIS zur gemeinsamen Nutzung übergeben. Bei der TN gibt es aber zwei Merkmale, die bisher einer gemeinsamen Erhebung für ALKIS und ATKIS im Wege standen: die unterschiedliche Erfassungstiefe und die unterschiedlichen Erfassungsuntergrenzen (Mindestflächen für

58 Synergien zwischen ALKIS und ATKIS im AAA-Modell den Nachweis einer TN). Um die TN gemeinsam erheben zu können, ist eine Harmonisierung der TN zwischen ALKIS und ATKIS unabdingbar. Im Liegenschaftskataster wurden für den Nachweis der TN bisher 213 verschiedene Einerschlüssel geführt, während es in ATKIS nur 63 verschiedene Wertearten zur Beschreibung der TN gibt. Durch den Erlass des HMWVL vom ist für das Liegenschaftskataster vorgegeben, dass in ALKIS in einem ersten Schritt nur noch 82 verschiedene Wertearten bestehen, die vorübergehend noch für die Auswertung der TN durch die Bundesstatistik benötigt werden. Sobald alle Bundesländer auf ALKIS umgestiegen sind, werden diese Wertearten in einem zweiten Schritt noch mal auf 49 reduziert. Damit ist bei der Erfassungstiefe eine weitgehende Harmonisierung der TN zwischen ALKIS und ATKIS gelungen. Bisher hatte man im Liegenschaftskataster beim Nachweis der TN immer nur die Sicht auf das einzelne Flurstück. Insofern kann von einer Erfassungsuntergrenze von 1 m² gesprochen werden. Für ATKIS gilt im Regelfall eine Erfassungsuntergrenze von 1 ha. Da mit dem Umstieg auf ALKIS die TN vollkommen unabhängig von den Flurstücken geführt wird, können im Liegenschaftskataster die Erfassungsuntergrenzen großzügig angehoben werden. Die Unterprojektgruppe ALKIS- ATKIS-Synergie (UPG Synergie) der PG ALKIS hat gemeinsame Erfassungsuntergrenzen für ALKIS und ATKIS entwickelt, deren Beträge unterhalb des bisher für ATKIS geltenden Grenzwertes liegen. Die vorgeschlagenen Grenzwerte unterscheiden sich nach der Wichtigkeit der betreffenden Nutzungsart und danach, ob ein Wechsel in der Nutzungsart zwischen zwei verschiedenen Objektartengruppen, zwei verschiedenen Objektarten in derselben Objektartengruppe oder zwei verschiedenen Wertearten in derselben Objektart vorliegt. Die vorgeschlagenen Erfassungsuntergrenzen müssen nun in der HVBG so angenommen und durch Erlass eingeführt werden. Mit den neuen gemeinsamen Erfassungsuntergrenzen und der fast gleichen Erfassungstiefe ist eine weitgehende Harmonisierung zwischen ALKIS und ATKIS erreicht. Trotz aller gelungenen Harmonisierung gibt es immer noch gewisse Unterschiede in der TN in ALKIS und ATKIS, deren Beseitigung fachlich nicht mehr gerechtfertigt wäre. Wenn nun die TN in einem Arbeitsgang von einer Stelle gemeinsam für beide Informationssysteme erhoben wird, müssen die Informationen so umfassend festgehalten werden, wie es jeweils ALKIS und ATKIS erfordern. Der Erheber muss beide Systeme im Auge haben und sich in beiden Bereichen auskennen. Es liegt nun nahe, für die Erhebung ein Werkzeug zu entwickeln, mit dessen Hilfe die Informationen zur TN für beide Systeme gleichzeitig, aber in der jeweils erforderlichen Ausgestaltung erhoben werden, und zwar in einer Weise, dass beide Systeme weitgehend automatisiert fortgeführt werden können. 4 Praxistest zur Erhebung der TN Um die bisherigen Annahmen für eine gemeinsame flächendeckende Aktualisierung der TN für ALKIS und ATKIS zu untermauern, wurde der nachfolgend beschriebene Praxistest konzipiert und durchgeführt. Erste Einschätzungen, mit welchem Aufwand bei einer Aktualisierung und Abgleichung der beiden Datenbestände ALKIS und ATKIS über die gesamte hessische Landesfläche hinweg zu rechnen ist, können aus dem bisherigen Test leider noch nicht erfolgen. Dafür müssen erst weitere Testreihen entwickelt und auf den Weg gebracht werden. Für das ausgewählte Testgebiet standen ALKIS- und ATKIS-Basis-DLM-Daten sowie aktuelle Orthophotos zur Verfügung. Untersucht wurden ausreichend große Gebietsteile für Bebaute Flächen (Ortslagen) Feldlagen Ziel des Praxistests war es, durch Orthophotointerpretation die ALKIS- und ATKIS-Daten im Testgebiet zu aktualisieren. Die Objekte aus dem Objektartenbereich,Tatsächliche Nutzung (TN) waren dabei mit dem aktuellen Orthophoto zu vergleichen. Bei diesem Vergleich wurde maschenweise vorgegangen. Eine Masche ist eine Fläche, die durch Straßen, Wege, Eisenbahnen oder Gewässer begrenzt wird. Neben den geometrischen Abweichungen zwischen den Daten und dem Orthophoto wurde sowohl die Nutzung in der Masche interpretiert, als auch die Nutzung der sogenannten,maschenbegrenzer (auch,maschenbildner genannt). 57

59 Synergien zwischen ALKIS und ATKIS im AAA-Modell Nach dem Zufallsprinzip wurden zudem zwischen 5 und 10 % der mit dem Orthophoto übereinstimmenden ATKIS-Objekte mit ihren ALKIS-,Geschwistern verglichen, um festzustellen, wie oft die,geschwister identisch und wie häufig sie widersprüchlich sind. Sowohl die über Orthophotointerpretation ermittelten Veränderungen als auch die Stichproben nach dem Zufallsprinzip wurden anschließend durch Ortsvergleich verifiziert. Aus den Ergebnissen konnten erste Schlüsse bezüglich der Interpretationssicherheit von verschiedenen Objekt- und Wertearten gezogen werden. Konkrete Bearbeitungszeiten waren aus den Tests noch nicht zu ermitteln. Mit Sicherheit lässt sich aber sagen, dass der Aufwand für den Ortsvergleich um ein vielfaches höher ist als die Zeiten für die Ortophotointerpretationen. 5 Gemeinsame Fachschale ALKIS-ATKIS Der UPG Synergie wurde u. a. die Aufgabe übertragen, die Datenerhebung für ALKIS und ATKIS zu analysieren, mit dem Ziel einer einzigen Erhebung und Überführung in die jeweils andere Modellart. Hierzu hat die UPG Synergie ein erstes Konzept auch hinsichtlich einer DV-technischen Abbildung der o. a. Fragestellung entwickelt. Die gegenwärtige Realisierung des AAA-Desktops als Erhebungs- und Qualifizierungskomponente bildet dabei die Konzeptionsgrundlage. In dieser Entwicklungsphase wird die Schnittmenge zwischen den Werkzeugen für ALKIS und ATKIS deutlich, so dass sich eine,gemeinsame Fachschale ALKIS-ATKIS geradezu anbietet. Nachfolgend sind die wichtigsten Anforderungen stichpunktartig aufgeführt: Die Gemeinsame Fachschale ist keine neue zusätzliche Fachschale zu den Fachschalen ALKIS und ATKIS-Basis-DLM im AAA-Desktop, sondern eine Erweiterung der beiden Fachschalen um zusätzliche Komponenten und Funktionalitäten. In der Gemeinsamen Fachschale können ALKIS- und ATKIS-Daten eingelesen, unterschiedlich signaturiert und anderweitig bearbeitet werden. In der Gemeinsamen Fachschale werden alle neuen Objekte gemäß den Regeln des ATKIS-Basis-DLM modelliert und, falls für ALKIS erforderlich, mit Zusatzinformationen angereichert. Neue ALKIS-Objekte und/ oder Geometrien werden im Erhebungsprozess in der Gemeinsamen Fachschale aus den Objekten des ATKIS-Basis- DLM erzeugt. Diese Thematik soll zunächst anhand eines Beispiels näher verdeutlicht werden. Die folgende Grafik (Abbildung 1) zeigt die Datenbestände von ALKIS und ATKIS Basis-DLM in der Gemeinsamen Fachschale vor der Aktualisierung: 58 Abbildung 1 - ALKIS- und ATKIS-Bestandsdaten vor der Veränderung

60 Synergien zwischen ALKIS und ATKIS im AAA-Modell Abbildung 2 zeigt ein im Zuge der Aktualisierung neu erhobenes ATKIS-Objekt AX_Fahrwegachse mit einer spezifizierten Breitenangabe, das daraus abgeleitete ALKIS-Objekt AX_Weg sowie den Einsatz der zusätzlichen Funktion,Klippen, um das Objekt AX_Weg an der Einmündung zur flächenhaften Straße modellkonform abzubilden. Abbildung 2 - ALKIS- und ATKIS-Bestandsdaten nach Veränderung der TN Auf dieses Beispiel wird im folgenden Abschnitt 6 nochmal zurückgekommen. Für den Umstieg von der Konzeptions- in die Realisierungsphase wurde Mitte des Jahres 2008 eine Arbeitsgruppe,Gemeinsame Fachschale ALKIS- ATKIS unter der Federführung der UPG Synergie mit folgendem Auftrag eingerichtet:,erarbeitung von fachlichen und DV-technischen Vorgaben zur Entwicklung der Gemeinsamen Fachschale ALKIS-ATKIS zum Zwecke der einmaligen Erhebung der Objektarten des Objektartenbereiches,Tatsächliche Nutzung (TN) sowie der in einem engen funktionalen Zusammenhang zur TN stehenden Objektarten wie z.b.,ax_klassifizierungnach- Strassenrecht oder,ax_bauwerk für ALKIS und ATKIS. Ziel ist, dass nach dem Umstieg auf ALKIS und auf das neue ATKIS-Modell die erforderlichen Werkzeuge zur synergetischen Erhebung der betreffenden Objektarten und Attribute in der HVBG verfügbar sind. 6 ErfTopAfB Das Pilotprojekt,Erfassung von topographischen Tatbeständen innerhalb des AAA-Modells bei den ÄfB (ErfTopAfB) hat im Wesentlichen zum Ziel, vor Ort nur eine Erfassung der Veränderungen bezüglich des gesamten Geobasisdatenbestandes sicherzustellen. Das bedeutet konkret, dass sowohl der Messtrupp im Liegenschaftskataster als auch der Topograph bei seinen örtlichen Arbeiten die Aktualisierungsanforderungen des Liegenschaftskatasters und der Geotopographie kennen müssen. Im Falle einer,einfachen Veränderung sollte die Erhebung gleich mit dem verbundenen Auftrag erledigt werden. Bei einer,komplexen Veränderung muss in jedem Fall ein Hinweis an die für die Aktualisierung des Datenbestandes zuständige Stelle weitergeleitet werden. Durch eine optimale Vorrecherche soll der örtliche Aufwand der Datenerfassung zudem auf ein Minimum reduziert werden. Diese Arbeitsprozesse zu beschreiben und die Entwicklung der daraus erforderlichen Werkzeuge (Software) einzuleiten, ist das Ziel der Projektgruppe. Neben der Harmonisierung der Erfassungsvorgaben durch die UPG Synergie werden durch die PG ErfTopAfB die Bearbeitungsprozesse einschließlich 59

61 Synergien zwischen ALKIS und ATKIS im AAA-Modell 60 der erforderlichen Vorrecherchen und die notwendigen Arbeitsabläufe bei der Erhebung mit dem Dezernat Topographie und Fernerkundung des HLBG beschrieben. Daraus resultieren Empfehlungen für die Entwicklung an der EQK- ATKIS, die dann vom HLBG umgesetzt werden. Arbeitsanforderungen Bevor wieder auf das praktische Beispiel (siehe Abschnitt 5) eingegangen wird, soll auf die unterschiedlichen Anforderungen bei der Fortführung der beiden Geobasisdatenbestände ALKIS und ATKIS hingewiesen werden. ALKIS repräsentiert im Wesentlichen den geometrischen Nachweis der Liegenschaften (Flurstücke und Gebäude) mit einer hohen Lagegenauigkeit. Von den Messtrupps im Liegenschaftskataster wird ein hohes Maß an vermessungstechnischem und liegenschaftsrechtlichem Sachverständnis, messtechnischer Präzision und die Auswahl des den Anforderungen entsprechenden wirtschaftlichsten Verfahrens erwartet. ATKIS beschreibt die tatsächliche Form und Bedeckung der Erdoberfläche. Der Topograph muss sich bei den Aktualisierungsarbeiten mitunter auch ohne vermessungstechnische Unterstützung im Gelände orientieren und die örtlichen Veränderungen zum,alten Datenbestand ebenfalls auf wirtschaftliche Weise erfassen. In vielen Fällen führen hierbei einzelne Veränderungen in der Örtlichkeit zu einer Vielzahl von weiteren Veränderungen an Objekten und ihren Attributen. Hierin liegt die eigentliche Komplexität der Arbeit des Topographen, der diese Zusammenhänge bei der Vorrecherche oder vor Ort erkennen muss, um eine erneute Anfahrt zu vermeiden. Im Gegensatz zum Messtrupp im Liegenschaftskataster, der stets vor Ort tätig wird, kann der Topograph auch Informationen aus georeferenzierten Unterlagen und Plänen verschiedenster Art übernehmen. Er muss allerdings sicherstellen, dass diese Informationen im Rahmen der für das ATKIS-Basis-DLM geltenden Genauigkeitskriterien bereits entsprechend in die Örtlichkeit umgesetzt wurden. Die Entnahme von Informationen aus zuverlässigen Planwerken ist in der Regel auch die wirtschaftlichste Form der Erhebung. Wenn bei größeren Maßnahmen die Quellensituation durch die Zuständigkeit mehrerer Träger unklar ist oder sich eine zeitliche Dringlichkeit aufgrund der Spitzenaktualität ergibt, kann allerdings auch die Erfassung im Gelände wirtschaftlicher sein. Derzeit wird der Außendienst im topographischen Bereich allerdings in der Regel durch das bloße,nicht-vorhandensein von Unterlagen ausgelöst. Diese Situation ist unbefriedigend und soll künftig verbessert werden. Recherchesystem Die Projektgruppe beschreibt, entwickelt und testet daher ein einfaches Recherchesystem, mit dem das genannte Defizit behoben und somit eine wirtschaftlichere Bearbeitung ermöglicht werden soll. Ziel ist es hierbei, Veränderungsinformationen georeferenziert in einer multiuserfähigen Datenbank zu sammeln, Rückfragen zu den Meldungen zu ermöglichen, weitere Informationen zu sammeln und die Erledigungsabfolge der gesammelten Aufträge nach Prioritäten zu steuern. Dieses System muss nicht ausschließlich für topographische Aktualisierungen nutzbar sein, es kann auch andere Belange im internen Geschäftsbetrieb der ÄfB bzw. des HLBG unterstützen. Beispiel zu den vorangehenden Ausführungen Abbildung 1 in Abschnitt 5 dieses Beitrages zeigt eine Flurstückssituation mit einem Gaswerk vor der Veränderung. Dieses Gaswerk soll nun erweitert werden, wobei unterstellt wird, dass das AfB durch die Gemeinde auf diese Veränderung aufmerksam gemacht worden ist. Nach der Erweiterung des Gaswerkes wird der derzeit vorhandene Weg nicht mehr nutzbar sein. Daher hat die Gemeinde mit dem Träger der Maßnahme vereinbart, dass ein neuer Weg im Rahmen der Bautätigkeiten durch den Träger auf seinem neuen Grundstück angelegt werden muss. Die Ausbaupläne für den neuen Weg liegen der Gemeinde allerdings nicht vor, und die Heraustrennung des Weges als separates Flurstück wird erst nach Abschluss der Bautätigkeiten über eine Zerlegungsvermessung erfolgen. Der Topograph analysiert nach Bekanntwerden der Maßnahme die nähere Umgebung unter Zuhilfenahme der ALKISund ATKIS-Daten, zu denen ausdrücklich auch das digitale Orthophoto (DOP) zählt. Bei Hinweisen auf weitere Veränderungen aus diesen Quellen versucht er über die Veränderungsverursacher an die für seine Aktualisierung erforderlichen Pläne und Daten heranzukommen. Es wird weiterhin davon ausgegangen, dass das aktuellste Orthophoto den neuen Weg noch nicht enthält und durch den (derzeit) dreijährigen Befliegungszyklus erst in zwei Jahren mit neuem Bildmaterial zu rechnen ist. Unter diesen Umständen ist die örtliche Erhebung der Veränderung die

62 Synergien zwischen ALKIS und ATKIS im AAA-Modell einzige Alternative. Demzufolge beschreibt der Topograph seine Anforderungen für den vermessungstechnischen Außendienst des AfB. Im Idealfall ist ein Messtrupp im Laufe der nächsten Woche in unmittelbarer Nähe zu diesem Auftrag tätig und kann ohne zusätzliche lange Anfahrtszeiten die erforderlichen Informationen erfassen. Bei dieser Erfassung werden zunächst drei Punkte in der Mitte des Weges (z.b. mit SAPOS-EPS) mit Metergenauigkeit bestimmt, um die,fahrwegachse für ATKIS abzuleiten. Des Weiteren wird die Fahrbahnbreite auf volle Meter gemessen, damit für ALKIS eine flächenhafte Darstellung der Tatsächlichen Nutzung,Weg in Verbindung mit der Achsgeometrie gebildet werden kann (für ATKIS hätte die Zuordnung einer Klassenbreite zur Wegeachse ausgereicht). Dies ist in Abschnitt 5 Abbildung 2 dargestellt, siehe hier Kasten AX_Fahrwegachse (BRV-Eingabe statt Klassenbreite; BRV bedeutet hier,breite des Verkehrsweges ) und Kasten AX_Weg. Das Ergebnis ist also eine Erfassung vor Ort für zwei weitgehend harmonisierte Datenmodelle und einen Geobasisdatenbestand, bei der die Kompetenzen, die Fähigkeiten und das Fachwissen aus den Bereichen Liegenschaftskataster und Geotopographie gebündelt werden. Erhebung für ALKIS und ATKIS mit zwei Fortführungsentwürfen abschließen und jeweils an das lokale Datenmanagement für ALKIS und ATKIS abgeben. Dieser Ansatz führt zu einer wirtschaftlicheren Arbeitsweise bei der Aktualisierung des Geobasisdatenbestands. Es wird auch deutlich, dass die fachlichen Zuständigkeiten innerhalb der HVBG in Zukunft nicht mehr so streng wie in der Vergangenheit sein werden. abgegrenzt Im Liegenschaftskataster werden allerdings - unter dem Fokus der liegenschaftsrechtlichen Anforderungen - nach wie vor Flurstücksgrenzen festgestellt oder festgelegt und Gebäudegrundrisse erhoben, während die Geotopographie den tatsächlichen aktuellen Zustand der Erdoberfläche abbildet. Bei allen durch die Einführung des AAA-Modells anstehenden Veränderungen bleiben die jeweiligen Kernkompetenzen der ÄfB und des HLBG weiterhin erhalten. Durch die ganzheitliche Sicht auf die Geobasisdaten werden sich die Werkzeuge und die Geschäftsprozesse bzw. Arbeitsabläufe wandeln, wobei die Bediensteten der HVBG für ihre Tätigkeiten sicherlich ein breiteres Spektrum an Fachwissen benötigen werden. Die Erhebung aller gesammelten Daten kann nun im Innendienst von einer Person mit der Gemeinsamen Fachschale in beiden Systemen bzw. Modellen vollzogen werden. Durch modellbedingte Unterschiede sind hier noch Anpassungen nötig, die jedoch möglichst automationsgestützt begleitet werden sollen. Bei diesem Beispiel wird der Topograph die 61

63 Abkürzungen Abkürzungsverzeichnis Redaktionsteam Abkürzung 3A 3GK3 Beschreibung Kurzbezeichnung für AFIS-ALKIS-ATKIS-Referenzmodell (benutzt von Systemherstellern) Gauß-Krüger-Abbildung mit 3 breiten Streifen im 3. Meridianstreifen (Mittelmeridian 9 östlich von Greenwich) A AAA Kurzbezeichnung für AFIS-ALKIS-ATKIS AAA-Desktop Werkzeuge für die Bearbeitung der Objekte des AAA-Modells AAA-Modell Kurzbezeichnung für das AFIS-ALKIS-ATKIS-Referenzmodell AB/NB AdV AfB AFIS Programmsystem,Alter Bestand/Neuer Bestand Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bundesrepublik Deutschland Amt für Bodenmanagement (Mehrzahl: ÄfB Ämter für Bodenmanagement) Amtliches Festpunktinformationssystem AK Arbeitskreis (z.b. innerhalb der AdV) AL ALB(-Hessen) albesas ALBi Abteilungsleitung, auch für Plural Programmsystem,Automatisiertes Liegenschaftsbuch hier mit Zusatz,Hessen automatisiertes Verfahren der Datenübernahme mit dem LBESAS-Konverter Internes Schnittstellenformat vom ALB ALK Automatisierte Liegenschaftskarte ALKIS ALKISbuch ANSI Amtliches Liegenschaftskatasterinformationssystem Prozesssteuerung zur Fortführung der Personen- und Bestandsdaten in ALKIS American National Standards Institute AP Aufnahmepunkt APK Auskunfts- und Präsentationskomponente (für AAA) 62

64 Abkürzungen Abkürzung Arge ATKIS Beschreibung Arbeitsgemeinschaft hier mit Zusatz Landentwicklung Amtliches Topographisch-Kartographisches Informationssystem B BGDB Bezirksgrundstücksdatenbank BKG Bundesamt für Kartographie und Geodäsie BORIS Bodenrichtwertinformationssystem BRV Attribut Breite des Verkehrsweges (Objekt AX_Fahrwegachse) BZSN Bezieher Sekundärnachweis C CAD CEN CIO CITRIX CPU Computer Aided Design (allgemeine Bezeichnung für Software zur graphischen Datenverarbeitung) Comité Européen de Normalisation (Europäisches Komitee für Normung) Chief Information Officer (CIO-Hessen = Chief Information Officer der hessischen Landesverwaltung) Citrix Systems - US-amerikanische Softwarefirma, Hersteller moderner Terminalserveranwendungen Central Processing Unit (Hauptprozessor) CRS Coordinate Reference System (Koordinatenreferenzsystem) CSV Comma Separated Value (alphanumerisches Datenformat) D DAVID DBMS Programmsystem,Digitalisierung, Ausgleichung und Verbesserung inhomogener Daten Datenbankmanagementsystem DFGM Digitales Festpunktmodell (der Grundlagenvermessung) DGF Digitales Graphisches Feldbuch DGM Digitales Geländemodell DHDN Deutsches Hauptdreiecksnetz DHK Datenhaltungskomponente (für AAA) DIN Deutsche Industrie Norm DKM Digitales kartographisches Modell 63

65 Abkürzungen Abkürzung DLKM DLM DMAS DNS DOP DPL DTK DV DXF Beschreibung Digitales Liegenschaftskatastermodell Digitales Landschaftsmodell Digitales Mikrofilm-Archivsystem Domain Named Services Digitales Orthophoto Attribut,Herkunft' bei Objekt,Datenqualität für Punktort Digitale Topographische Karte Datenverarbeitung Data bzw Digital Exchange Format von Firma Autodesk E EDBS Einheitliche Datenbankschnittstelle EG EK EPSG EQK Expertengruppe (z. B. innerhalb der AdV) Erhebungskomponente (für AAA) European Petroleum Survey Group Erhebungs- und Qualifizierungskomponente (für AAA) ETRS89 Europäisches Terrestrisches Referenzsystem 1989 ETRS89/UTM32 EUREF EVU ETRS89 mit UTM-Abbildung in Zone 32 (Mittelmeridian 9 östlich Greenwich) European Reference Frame Energieversorgungsunternehmen F FE Fortführungsentwurf FES FFV F-HCC FIS Filter Encoding System Fortführungsverfahren durch Vermessungsstellen Fachliches Hessisches Competence Center Fachinformationssystem 64

66 Abkürzungen Abkürzung FKZ FM FN FNO FPÜ FSC FTP F&E-Recherche Beschreibung Flurstückskennzeichen (ALB, ALK) Fortführungsmitteilung (auch in Verbindung mit FM-Hessen) Fortführungsnachweis (auch in Verbindung mit FN-Hessen) Flurneuordnung Festpunktübersicht Fujitsu Siemens Computers (Firmenname) File Transfer Protocol Flurstücks- und Eigentümerrecherche G GDB Geographische Datenbank GDI (-DE) GDI (-HE) GEOgraf GEOi-SQL GeoInfoDok GIF GIS GK GML GNSS GOHLBG GPS GravP GRK Geodateninfrastruktur hier mit Zusatz DE für Deutschland Geodateninfrastruktur hier mit Zusatz HE für Hessen CAD-Software der Firma,HHK-Datentechnik Programmsystem,Geodätische Berechnungen interaktiv mit Datenbankanschluss über Schnittstelle SQL Dokumentation (der AdV) zur Modellierung der Geoinformationen des amtlichen Vermessungswesens Graphics Interchange Format (Datenformat für Rasterdaten) Geographisches Informationssystem Gauß-Krüger (-Koordinatensystem) Geography Markup Language Global Navigation Satellite System (Sammelbegriff für globale Satellitennavigationssysteme) Geschäftsordnung des Hessischen Landesamtes für Bodenmanagement und Geoinformation Global Positioning System Gravimetriepunkt (Schwerefestpunkt) Programmsystem,Gutachten-Richtwerte-Kaufverträge GRS80 Geodetic Reference System

67 Abkürzungen Abkürzung GST GT GUI Beschreibung Attribut,Genauigkeitsstufe bei Objekt,Datenqualität für Punktort Geotopographie (auch im Zusammenhang mit AK GT) Grafik User Interface H HE Hessen HE 100 Hessischer Lagestatus 100 HFP HLBG HLVA HMWVL HVBG HVKF HREF HTML http-call HZD Höhenfestpunkt Hessisches Landesamt für Bodenmanagement und Geoinformation Hessisches Landesvermessungsamt - neue Bezeichnung HLBG Hessisches Ministerium für Wirtschaft, Verkehr und Landesentwicklung Hessische Verwaltung für Bodenmanagement und Geoinformation Hessische Verwaltung für Kataster und Flurneuordnung - neue Bezeichnung HVBG Hessisches Referenznetz Hypertext Markup Language Schnittstelle für den Aufruf per http-protokoll Hessische Zentrale für Datenverarbeitung IJ ibr Ingenieurbüro Riemer ID IK IML IP-Adresse ISDN ISO IT Identifikator Informations- und Kommunikationstechnik (auch im Zusammenhang mit AK IK) Integrierte Modellierung des Liegenschaftskatasters (auch im Zusammenhang mit EG IML) Internet-Protocol-Adresse Integrated Services Digital Network International Organization for Standardization Informationstechnologie 66

68 Abkürzungen Abkürzung JPEG JPG Beschreibung Joint Photographic Expert Group (Bild-Datenformat) Joint Photographic Expert Group (Bild-Datenformat) K KGIS Kommunales Geographisches Informationssystem KP-DAT Katasterpunktdatei L LAN Local Area Network LBESAS LDM LEFIS LET-Hessen LFP LINIV LINUX LK LST Liegenschaftsbuch Eingabesätze Auftragsbuch - Sequentiell Lokales Datenmanagement Landentwicklungsfachinformationssystem Landeseinheitlicher Transformationsansatz Hessen (Transformationstool) Lagefestpunkte Programm zur Linien- und Netznivellementausgleichung in der Grundlagenvermessung Kunstwort, zusammengesetzt aus LINUS und UNIX Liegenschaftskataster (auch im Zusammenhang mit AK LK) Lagestatus M MAT Attribut Modellartenkennung (Abstrakte Objektklasse AA_Objekt) MIS MO MRSID MS Metadateninformationssystem Migrationsobjekt Multi Resolution Seamless Image Database (Komprimierungsformat) Microsoft N NAS Normbasierte Austauschschnittstelle NBA Nutzerbezogene Bestandsdatenaktualisierung NCR National Cash Register (Firmenname) NHN Normalhöhennull 67

69 Abkürzungen Abkürzung NivP Beschreibung Nivellementpunkt (Höhenfestpunkt) NN Normalnull NREO Nicht-raumbezogenes Elementarobjekt NRW Nordrhein-Westfalen NT New Technologie (in Verbindung mit Microsoft) O OBAK OCL Objektabbildungskatalog für die ALK, ggf. mit Zusatz des Versionsjahres (z.b. OBAK 2000) Object Constraint Language ODBC ÖbVI OGC Open Database Connectivity Öffentlich bestellte Vermessungsingenieurin oder Öffentlich bestellter Vermessungsingenieur Open Geospatial Consortium OID Objektidentifikator OK Objektartenkatalog PQ PAGEWIN PCX Programmsystem zur Auswertung von GPS- und terrestrischen Messungen in der Grundlagenvermessung / Windows-Version Picture Exchange (Datenformat) PD Potsdam-Datum PDF Portable Document Format (Adobe) PG Projektgruppe PKN Punktkennung (ALKIS) PKZ Punktkennzeichen (ALK) PL Projektleitung, auch für Plural PM Projektmanagement in der HVBG PMO Punktmengenobjekt PNG Portable Network Graphic (Datenformat) 68

70 Abkürzungen Abkürzung PO PoST ppm Beschreibung Präsentationsobjekt Positionsstatus parts per million R RB Raumbezug (auch im Zusammenhang mit AK RB) RBU Programmsystem,Rechnergestützte Baulandumlegung REO Raumbezogenes Elementarobjekt RSP Referenzstationspunkt für SAPOS RTF Rich Text Format (alphanumerisches Datenformat) S SAP Systeme, Anwendungen, Produkte in der Datenverarbeitung: Begriff steht sowohl für das Softwarehaus als auch für das Produkt (SAP R/3) SAP R/3 Systeme, Anwendungen, Produkte Release 3 SAPOS SAPOS-EPS SAPOS-HEPS SD SFP SGI SICAD SIPGIS SIPGIS-web SIPView SK SOA SOLUM-STAR Satellitenpositionierungsdienst der deutschen Landesvermessung Echtzeit-Positionierungsservice des SAPOS Hochpräziser Echtzeit-Positionierungsservice des SAPOS SAP-Vertriebsmodus Sales/Distribution Schwerefestpunkt Silicon Graphics Incorporated (Firmenname) Siemens Computer Aided Design Software Image Pro Geoinformationssystem Internetfähige Version von SIPGIS Image Viewer von Firma Image Pro GmbH Signaturenkatalog Serviceorientierte Architekturen (im IT-Bereich) Programmsystem zur elektronischen Grundbuchführung 69

71 Abkürzungen Abkürzung SQD SQL SVG Beschreibung Sequentielle Datei (graphisches Datenformat in SICAD) Structured Query Language Scalable Vector Graphics (W3C-Standard für die XML-basierte Darstellung von zweidimensionalen Vektorgraphiken) T TIFF Tagged Image File Format (Format für Rasterdaten) TN TP TPS TTC TRANSID Tatsächliche Nutzung Trigonometrischer Punkt (Lagefestpunkt) Tachymeter Positionierungssystem Programm,Trimble Total Contol in der Grundlagenvermessung zur Auswertung von GNSS-Messungen im Postprocessing Programm zur Transformation zwischen verschiedenen Referenzsystemen mit Berechnung der Transformationsparameter über identische Punkte, sowie die Umrechnung innerhalb eines Referenzsystems in verschiedene Koordinatendarstellungen U UML Unified Modelling Language UMN-Mapserver UPG URI USV UTM Von der Universität von Minnesota (UMN) entwickelter Server für die Bereitstellung und Nutzung von Geodaten Unterprojektgruppe, in Verbindung mit Geschäftsprozesse, DV- System bzw. Synergie ALKIS-ATKIS Unified Resource Identifier Unterbrechungsfreie Stromversorgung Universale Transversale Mercator-Abbildung V VBORIS Vernetztes Bodenrichtwertinformationssystem VMware VPR VWL VMware (Software, mit der man mehrere Betriebssysteme gleichzeitig auf einem Server oder PC laufen lassen kann) VM bedeutet dabei,virtual Machine Vermessungsprogramme Riemer Attribut,Vertrauenswürdigkeit bei Objekt,Datenqualität für Punktort W W3C World Wide Web Consortium WAN Wide Area Network 70

72 Abkürzungen Abkürzung WFS Beschreibung Web Feature Service WGS 84 World Geodetic System 1984 WLDG-E WLDG-GB WMS WWW Workdatei Liegenschaftsbuch Daten-Gewinnung hier mit Zusatz E für,entschlüsselt (Format für ALB-Daten) Workdatei Liegenschaftsbuch Daten-Gewinnung hier mit Zusatz GB für,grundbuch (Format für ALB-Daten) Web Map Service World Wide Web XYZ XLS Microsoft Excel Datenformat (Tabellenkalkulation) XML XSLT ZIP ZUSO Extensible Markup Language Extensible Stylesheet Language for Transformation (Sprache für Transformationen von XML- und GML-Dokumenten) Format zur komprimierten Archivierung von Dateien Zusammengesetztes Objekt 71