© Henryk Sadura, Fotolia.com

In deutschen Katasterämtern gewinnen Unix, Linux und freie Software an Boden. Vor wenigen Wochen gingen im westfälischen Kreis Lippe die ersten Behörden mit dem Amtlichen Liegenschaftskatasterinformationssystem (ALKIS) und dem freien Konvertierungsmodul Postnas online.

Im Sommer 2010 war es so weit: Der Katasterdatenkonverter Postnas [1] wird Open-Source. Schon länger bindet das Kommunale Rechenzentrum KRZ im westfälischen Landkreises Lippe damit mehrere Gemeinden über eine freie Geodateninfrastruktur an das Amtliche Liegenschaftskatasterinformationssystem (ALKIS, [2]). Mehrere Jahre hatten freie Entwickler, Vermessungsspezialisten und Admins in Behörden unter Führung der Bonner Wheregroup an Alternativen zu proprietären Tools gearbeitet.

Weitere Gemeinden und Kunden des RZ wollen 2011 folgen. Auch andere Bundesländer wie Mecklenburg-Vorpommern interessieren sich mittlerweile für die flexiblen Möglichkeiten der freien GIS-Tools und tauschen ihre Erfahrungsberichte auf der Mailinglistste von Postnas aus [3].

Das deutsche Katasterwesen ist eine der wohl komplexesten Geodatenstrukturen weltweit, in die eine große Anzahl IT-Konzepte und Softwareprojekte eingebettet sind. Tabelle 1 gibt einen kleinen Einblick in die lange Liste der kryptischen Abkürzungen. Im Kasten “Geschichte der elektronischen Katastersysteme” findet sich ein kurzer Abriss der historischen Entwicklung.

Abbildung 1: Eine an Details reduzierte ALKIS-Karte, mit Postnas konvertiert …

Neben Flurbüchern, amtlichen Bestandsblättern und dem Kartenwerk in Form der Liegenschaftskarten besteht das Katasterwesen aus den so genannten Zahlenwerken mit Vermessungspunkten, Koordinaten und Berechnungen. Jeder Bauherr, der schon mal wegen eines Vorhabens oder einer Auskunft mit einer Behörde zu tun hatte, kann ein Lied davon singen.

Die amtlich verbindliche Kartendarstellung der ALK ist aus geschichtlichen Gründen reduziert auf reines Schwarz auf einem weißen (transparenten) Hintergrund (Abbildungen 1 und 2). Auf Farben, Raster, Teiltransparenzen oder andere Mittel eines modernen GIS verzichtet sie vollkommen. Bis 2004 war diese rechtsverbindliche Darstellung nur einer Handvoll proprietärer Spezialprogramme von wenigen Softwareherstellern eines Quasi-Monopols vorbehalten.

Tabelle 1: Abkürzungen in der Katasterverwaltung

Erste freie ALK-Konverter

Erste Ansätze freier Software finden sich ab 2004 in dem Projekt Automatisierte Liegenschaftskarte (ALK) mit freier Software [4] mit dem Konverter Edbs2wkt [5], der die EDBS-Ausgabe (einheitliche Datenbankschnittstelle) der ALK in eine Spatial-Datenbank überführt. Diese Aufgabe ist nicht trivial, widerspricht die Struktur der ALK doch den Simple-Features-Normen des OGC (Open Geospatial Consortium, [6]).

Abbildung 2: … und als amtlich verbindlicher ALK-Ausdruck von Edbs2wkt.

Die Geometrie der ALK basiert auf der Idee der Redundanzfreiheit. Eine Linie ist hier nur einmal gespeichert, auch wenn sie (horizontal) zwei Flächen rechts und links der Linie trennt und somit zu zwei Objekten einer Ebene gehört. Eine Spatial-DB speichert jedoch jedes Objekt in einem Geometrie-Datenfeld, unabhängig davon, ob zum Beispiel ein Teil vom Rand der Fläche auch ein Teil einer anderen ist. Linientypen wie Kreisbögen oder Splines (ausgleichende Kurven über Stützpunkte und Vor-/Nachlaufpunkte, [7]) mussten die Entwickler durch ausreichend fein interpolierte Polygone ersetzen, denn die Welt des OGC ist eckig. Außerdem arbeitet die ALK mit gemischten Koordinatensystemen (verschiedene Gauß-Krüger-Meridianstreifen), ein GIS aber in einem einheitlichen System.

Edbs2wkt amtlich

Aufbauend auf der ALK-GIS-Datenbank und dem Konverter Edbs2wkt entwickelten Programmierer und Ämter Mapfiles und Symbolbibliotheken für den UMN-Mapserver und erreichten so erstmals das Ziel einer mit Open-Source-Mitteln erstellten amtlichen Karte. Nebenbei machten die freien GIS-Tools auch alternative, wahlweise komplexere oder aber vereinfachte Darstellungen möglich. Edbs2wkt kommt heute in ganz Deutschland zum Einsatz [8].

Da bis Ende nächsten Jahres alle Katasterämter auf das ALK-Nachfolgesystem ALKIS umstellen, braucht die freie Softwarewelt einen neuen Konverter, der das dort verwendete Exportformat XML einschließlich der neuen, vereinheitlichten Attribute aus dem Buchwerk beherrscht. Dieses neue Interface heißt Normbasierte Austauschschnittstelle (NAS), und dient dem Import von Daten aus ALKIS. Dieses freie GDAL-Konvertierungsmodul für macht für viele PostgreSQL/Postgis-Server und Nutzer von Katasterdaten erstmals die zahlreichen Features freier Web-GUIs wie Mapbender zugänglich (Abbildung 3 bis 5).

Abbildung 3: Im Web-GUI von Mapbender erscheinen die durch freie Software aufbereiteten Daten. Die Abbildung zeigt die Kombination von ALKIS-Daten mit einem Luftbild und dem Kanalkataster.

Abbildung 4: Flächen-Nutzungsarten markiert Mapbender farbig, auch das Abwassernetz ist mit zahlreichen Meta-Informationen versehen. Im abgebildeten DIN-A4-Druck werden Zahlen und Bezeichnungen sichtbar.

Postnas für ALKIS

Postnas ist allerdings kein eigenständiges Programm, sondern ein Konverter für den Datenimport über die Geodatenabstraktionsbibliothek GDAL/OGR (Geospatial Data Abstraction Library, [9]) und damit auch nicht auf Server mit PostgreSQL-Datenbanken beschränkt. Vielmehr kann es mit allen von GDAL unterstützten Vektorformaten arbeiten. GDAL setzt auf GEOS und PROJ.4, lässt sich via Python, Java, C#, Ruby, Visual Basic und Perl ansprechen und dient zahlreichen proprietären Herstellern als Basis für kartografische Software.

Der Treiber für GDAL unterstützt seinerseits zahlreiche Ein- und Ausgabeformate, darunter ESRI Shapefiles, CSV oder Oracles Spatial-Erweiterungen. Postnas konvertiert als ausschließlich lesendes GDAL-Modul die Daten für die Präsentation und Weiterverarbeitung.

Abbildung 5: ALKIS im Maßstab 1:2500 als Hintergrund für die Karte »Baudenkmal«. Statt der Themenübersicht ist die Legende aufgeklappt, das Popup-Fenster zeigt die Details eines alten Fachwerkgebäudes.

Selber installieren

Die folgende Beispielinstallation erfolgt auf einem Debian Lenny mit PostgreSQL 8.3 und geht davon aus, dass auf dem System GDAL/OGR noch nicht installiert ist. Weil Postnas nur im Quelltext zu erhalten ist, braucht es auf dem System C/C++-Compiler sowie gängige Build-Werkzeuge wie Make. Den Sourcecode pflegt ein Subversion-Repository, daher sind auch der Kommandozeilenclient im Paket »svn« sowie die Headerdateien aller beteiligten Bibliotheken erforderlich.

Der Befehl »svn checkout http://svn.osgeo.org/gdal/trunk/gdal« in einem separaten Unterverzeichnis (zum Beispiel »~/postnas«) holt den aktuellen Entwicklercode des GDAL/OGR-Projekts, etwa 120 MByte, in ein lokales Verzeichnis. In der Zwischenzeit installiert

apt-get install postgresql-8.3 postgresql
-server-dev-8.3 postgresql-8.3-postgis 
libxerces-c2-dev libgeos-dev proj

die XML-Bibliothek Xerces und löst die Abhängigkeiten zu PROJ.4 und GEOS für Projektionen und räumliche Analysen. Auch die PostgreSQL-Datenbank samt Postgis-Erweiterung und Headern landet mit diesem Kommando bereits auf der Platte. Jetzt lässt sich im von Svn angelegten Unterverzeichnis »gdal« von jedem Benutzer die Konfiguration der Quellen durchführen.

Das Configure-Skript erkennt vorhandene Software und ermittelt unter anderem mit dem Hilfsprogramm »pg_config« aus den PostgreSQL-Headern für den Compiler essenzielle Angaben (Abbildung 6). Die meisten Komponenten lassen sich damit automatisch integrieren, für Bibliotheken wie Xerces geht der Admin allerdings auf Nummer sicher, wenn er die Anforderung explizit angibt.

Abbildung 6: Das Konfigurationstool Pg_config aus den PostgreSQL-Headern erkennt die Einstellungen und Vorgaben des Datenbankservers und liefert dem Configure-Skript Angaben zu installierbaren Modulen.

Der Befehl »./configure –prefix=/opt/gdal-trunk –with-xerces« bereitet nun das Kompilieren vor. Das an der Kommandozeile explizit angegebene Installationsziel verhindert Verwechslungen mit vielleicht vom Paketmanagement installierten Versionen. Wem das nicht reicht, dem liefert »./configure –help« eine lange Liste der verfügbaren Parameter, die das Make-Tool versteht.

Erfolgskontrolle

In der Terminalausgabe verrät der Eintrag »NAS support: yes«, dass der NAS-Treiber für die Aktivierung vorgesehen ist. Abschließend kompilieren und installieren »make« und »make install« die GDAL-Bibliotheken mit Postnas. Ist alles erfolgreich verlaufen, sollte der Befehl »ogrinfo« ohne Parameter unter anderem folgende Ausgabe erzeugen:

# /opt/gdal-trunk/bin/ogrinfo --formats | 
 grep NAS
-> "NAS" (readonly)

Für den jetzt folgenden Datenimport dient ein Schnappschuss der ALKIS-Demodaten des Landesamts für Vermessung und Geobasisinformation Rheinland-Pfalz, der sich auf der DELUG-DVD befindet oder alternativ unter [10] zum Download steht. Von dort landen die Datensätze mit der Bezeichnung »Bestandsdatenauszug-Mustermonzel (Format xml)« sowie »Beispieldatensatz NBA-Grundausstattung (NBA-Nutzerbezogene Aktualisierung) für die Mustergemarkung« – mit Unzip entpackt – in einem Unterverzeichnis wie »~/postnas/daten«.

Datenbank mit Postgis

Jetzt braucht der Admin eine Postgis-fähige PostgreSQL-Datenbank mit passenden Zugriffsrechten, die die Beispieldaten aus dem Katasteramt speichert. Eine lokale Datenbankinstallation ohne weitere Sicherheitsanforderungen reicht für Tests vollkommen und gewährt dem standardmäßigen Administrationsbenutzer »postgres« lokalen Vollzugriff ohne Passwortabfrage. Produktiv sollte so ein System jedoch nicht Verwendung finden, mehr Details für sichere Setups bietet die PostgreSQL-Dokumentation.

In der mit Root-Rechten schreibbaren Datei »/etc/postgresql/8.3/main/pg_hba.conf« findet sich im Abschnitt »IPv4 local connections« ein Eintrag, der mit »host« beginnt und in der vierten Spalte die Netzwerkangabe »127.0.0.1/32« enthält. Hier erlaubt der Parameter »trust« alle lokalen Zugriffe:

host  all  all  127.0.0.1/32  trust

Nach dem Speichern lädt »/etc/init.d/postgresql-8.3 reload« die neuen Einstellungen. Jetzt können die GDAL/OGR-Tools über den Benutzer »postgres« mit der Datenbank auf dem Localhost eine Verbindungen aufbauen.

Als letzten Schritt vor dem Import legt der Benutzer eine Testdatenbank mit dem Standardschema »public« an und macht sie Postgis-fähig (Listing 1). Dafür bestückt er sie mit der von PostgreSQL bereitgestellten prozeduralen Sprache PL/pgSQL und führt zwei Skripte zum Erzeugen der Postgis-Funktionalität aus. Wer für Wiederholungsfälle gewappnet sein will, legt die Datenbank unter dem Namen »postgis_template« an und kann sie dank des Template-Mechanismus von PostgreSQL für alle künftigen Geodatenbanken als Vorlage verwenden.

01 createdb -U postgres -h localhost postgis_template
02 createlang -U postgres -d postgis_template plpgsql
03 psql -U postgres -d postgis_template -f /usr/share/postgresql-8.3-postgis/lwpostgis.sql
04 psql -U postgres -d postgis_template -f /usr/share/postgresql-8.3-postgis/spatial_ref_sys.sql

Das Kommando erstellt die eigentliche Datenbank »postnas_test«:

createdb -U postgres -h localhost -T postgis
_template postnas_test

Einen Überblick über die nun vorhandenen Datenbanken verschafft »psql -l -U postgres -h localhost« (Abbildung 7).

Abbildung 7: PostgreSQL mit Postgis in Aktion: Hier fragt der Admin die vorhandenen Datensätze ab.

Erstbelieferung

Jetzt folgt der eigentliche Konvertierungs- und Importvorgang. Dabei kommt das Kommandozeilentool »ogr2ogr« zum Einsatz, das Daten aus einem OGR-Format in ein anderes umwandelt. Im Verzeichnis mit den heruntergeladenen Daten startet der Aufruf aus Listing 2 den initialen Datenimport.

01 /opt/gdal-trunk/bin/ogr2ogr -f "PostgreSQL" -skipfailures PG:"dbname=postnas_test user=postgres host=localhost port=5432" -a_srs EPSG:25832 Bestandsdatenauszug-Mustermonzel-06.05.2010.xml 2>> postnas_err.log

Je nach Datenmenge kann dieser Vorgang viel Zeit in Anspruch nehmen, mit den Testdaten dauert das durchaus 10 bis 20 Minuten. Die Option »-f “PostgreSQL”« nennt den Treiber des Zielformats, »-skipfailures« vermeidet den Programmabbruch im Fehlerfall. Hinter »PG:« folgt ein String mit der Datenbankverbindung. »-a_srs EPSG:25832« ist eine vermessungstechnische Angabe und verweist auf das räumliche Zielbezugssystem, hier das amtliche Lagebezugssystem ETRS89. Es folgt die einzulesende ALKIS-Datei, abschließend leitet die Shell die Standardfehlerausgabe in eine Logdatei um. Die offenbart tatsächlich einige, in der Regel aber vernachlässigbare Fehler in einzelnen Geometrie-Angaben.

Abbildung 8: Schneller Viewer mit ALKIS-Backend: Dank freier Software setzen viele Gemeinden auf sekundäre oder gar tertiäre Datenbanken, die die amtlichen Daten tagesaktuell darstellen.

Für Testzwecke reicht der in Listing 2 beschriebene Ogr2ogr-Aufruf zwar völlig aus, in der Praxis werden Anwender aber häufiger auf die Parameter »-append« oder »-update« zurückgreifen, um bestehende Datenbanken zu aktualisieren oder zu erweitern. Für diese Fälle empfehlen sich auch die SQL-Skripte von der Projektseite [11] sowie die äußerst hilfreichen Shellskripte von [12]. Damit lassen sich sowohl neue Datenbanken anlegen als auch der initiale Datenimport oder eine (Teil-)Aktualisierung im Stapelbetrieb durchführen.

Visualisierung

Jetzt hat der Anwender eine vollständige Spatial-Datenbank mit Katasterdaten im Einsatz, wie sie auch Spezialisten in deutschen Amtsstuben oder bei deren Kunden benutzen, etwa in Ingenieurbüros. Alle Postgis-fähigen Desktop-Programme wie Quantum GIS (auf der DELUG-DVD, [13]) oder Gvsig [14] können auf den Datenbestand zugreifen.

Abbildung 9: Metadaten aus dem Grundbuch im Mapbender. Für die tägliche Arbeit bietet der Web-GIS-Client alle benötigten Funktionen, hier eine (unverbindliche) Auskunft aus dem Grundbuch.

Anspruchsvoller ist die Anbindung der ALKIS-Layer in ein Web-GIS mit dem UMN-Mapserver. Wer das probieren will, findet auf den Postnas-Projektseiten passende Vorlagen für eigene Mapfiles und HTML-Templates [15]. Dann funktioniert auch der Kartenclient Mapbender [16] für den Browser, wie in den Abbildungen 4 bis 5 zu sehen. Eine gute Schritt-für-Schritt-Anleitung von NAS bis ins Web findet sich unter [17], mehrere Artikel des Linux-Magazins beschreiben die Hintergründe ([18], [19], [20]). Die DELUG-DVD bietet mit der Web-GIS-CD des Landes Rheinland-Pfalz eine anschauliche Vorlage und umfangreiche Spielwiese.

Schneller dank Open Source

Als immer wieder problematisch erweisen sich für die Anwender freier GIS-Strukturen die Vorgaben für die Amtlichkeit, die sich mit der Einführung von ALKIS durch eine Vorschrift namens Geo Info Dok (GID) noch deutlich erhöht haben. Doch auch ohne deren vollständige Umsetzung hat Postnas Vorteile: Weil in den ALKIS-DBs Langzeit-Transaktionen häufig eine angemessen performante Benutzung verhindern, haben Gemeinden sekundäre oder tertiäre Auskunftsysteme aufgebaut, die die ALKIS-Daten der Katasterämter nutzen, um schneller und benutzerfreundlicher Auskünfte zu generieren (Abbildungen 8 und 9). Deren Datenbanken importieren Admins per Cronjob mit Postnas. Ihre wochen- oder monatsaktuelle Ausgabe dient Sachbearbeitern als Vorschau und Arbeitshilfe für den späteren, zeitraubenden Export der amtlichen Karte aus ALKIS.