ALKIS-NAS importieren mit Open Source: von der NAS-Datei zur PostGIS-Datenbank

Für den Import Ihrer ALKIS-Daten zahlen viele Ämter den Aufpreis für eine proprietäre Black-Box – obwohl das verbreitetste Werkzeug dafür quelloffen ist und nichts kostet. Die NAS-Lieferung liegt auf der Platte, aber niemand kann sie direkt nutzen: kein Klick öffnet das Buchwerk, kein Doppelklick zaubert Flurstücke auf die Karte. Genau diese Lücke – von der rohen NAS-Datei zum nutzbaren ALKIS-Bestand – nährt den Mythos, man brauche ein teures Spezialprodukt. Das stimmt nicht. Es gibt eine durchgängig offene Werkzeugkette, sie ist im Produktivbetrieb erprobt, und dieser Beitrag zeigt Schritt für Schritt, wie Sie damit aus NAS eine PostGIS-Datenbank bauen.

Das AAA-Modell und die NAS in fünf Minuten

ALKIS ist kein isoliertes System, sondern eine von drei Säulen des AAA-Modells der AdV: AFIS (Festpunkte), ALKIS (Liegenschaftskataster) und ATKIS (Topografie) teilen sich ein gemeinsames Anwendungsschema, das in der GeoInfoDok definiert ist [1]. ALKIS selbst führte die früher getrennten Welten von Liegenschaftsbuch (ALB) und Liegenschaftskarte (ALK) in einem einzigen Datenmodell zusammen [3]. Maßgeblich ist bundesweit die AdV-Referenzversion 7.1; in Niedersachsen etwa ist die GeoInfoDok 7.1.2 seit dem 7. Dezember 2023 im produktiven Einsatz [2].

Ausgeliefert werden diese Daten über die NAS – die Normbasierte Austauschschnittstelle. Sie ist neben Basis- und Anwendungsschema fester Bestandteil der GeoInfoDok [1] und technisch alles andere als trivial: ein XML-basiertes Format auf Grundlage der W3C-XML-Standards, das ein komplexes GML-3-Profil mit OpenGIS-konformem GML/WFS/Filter-Encoding nutzt [3]. Selbst die GDAL-Dokumentation beschreibt die NAS als „GML-Profil mit recht komplexen GML3-Objekten, die sich mit dem allgemeinen OGR-GML-Treiber nicht ohne Weiteres lesen lassen” [4].

Die NAS ist ein Transportformat, kein Arbeitsformat. Sie transportiert das Modell vollständig und normgerecht – aber für eine Auskunft, eine Karte oder eine Analyse müssen die Objekte erst in eine Datenbank überführt und nach GeoInfoDok aufbereitet werden.

Der Mythos vom teuren Spezial-Import

In Ausschreibungen und Beschaffungsgesprächen hält sich hartnäckig die Annahme, der ALKIS-Import sei ein proprietäres Geheimwissen, das man teuer einkaufen müsse. Der Reflex ist verständlich – die NAS ist komplex, und wer einmal versucht hat, sie „mal eben” mit einem Standard-GIS zu öffnen, ist gescheitert.

Die Realität ist eine andere: Der Weg von der NAS-Datei zur nutzbaren Datenbank ist ein gelöstes Problem mit offenen Werkzeugen. Das Kernstück – der NAS-Treiber – ist seit Jahren offizieller Bestandteil von GDAL/OGR, und das gängigste Frontend dafür, der norGIS-ALKIS-Import, steht unter einer freien Lizenz. Wer das weiß, verhandelt in der Beschaffung nicht mehr über den Import selbst, sondern nur noch über Betrieb, Integration und Support – und das ist eine ganz andere Gesprächsgrundlage.

Die offene Werkzeugkette im Detail

Die Kette besteht aus drei Bausteinen, die sauber ineinandergreifen.

Der GDAL/OGR-NAS-Treiber liest das NAS/ALKIS-Format. Er wurde im Rahmen des PostNAS-Projekts entwickelt und ist seit GDAL/OGR 1.8.0 unter dem Formatnamen „NAS” offizieller Bestandteil der Bibliothek [5] [6]. Er benötigt ein mit der Xerces-XML-Bibliothek gebautes GDAL und übersetzt die komplexen GML3-Objekte in OGR-Layer [4].

norGIS-ALKIS-Import von norBIT ist das Frontend darüber: „ein Frontend zum Import ALKIS über den NAS-Treiber in GDAL/OGR in PostgreSQL/PostGIS” [7]. Es legt das Datenbankmodell an, ruft ogr2ogr für die gewählten NAS-Dateien auf und übernimmt die „Vorbereitung der graphischen Darstellung nach GeoInfoDok (insb. Ableitungsregeln des Signaturkatalogs)” sowie die Aufbereitung der Liegenschaftsbuchdaten [7] [10]. Die zugehörigen GFS-Templates und PostgreSQL-Schemata für GeoInfoDok 6 und 7.1.2 sind Teil des norGIS-Projekts und werden mit xmi2db aus dem Modell generiert [4].

PostgreSQL/PostGIS ist der Zielspeicher. Von dort lassen sich die Daten in QGIS anzeigen – etwa über das ebenfalls quelloffene QGIS-Plugin alkisplugin, das „zur Einbindung von ALKIS-Daten aus durch norGIS ALKIS-Import (über GDAL/OGR) erzeugten PostgreSQL/PostGIS-Datenbanken” dient [11] – oder per WMS/WFS aus einem Kartenserver heraus in ein Geoportal wie das Masterportal einspeisen.

Die Lizenzfrage – sauber belegt

Weil in der Vergabe genau das zählt, hier präzise: norGIS-ALKIS-Import ist echte freie Software, lizenziert unter der GPLv2. Die README des Projekts nennt ausdrücklich „Lizenz: GPLv2” [7], die mitgelieferte LICENSE-Datei enthält den vollständigen GPLv2-Text [8], und die Quellcode-Header formulieren „version 2 of the License, or (at your option) any later version” – also GPLv2 oder neuer [9]. Der Quellcode liegt öffentlich auf GitHub. Auf ihrer eigenen Produktseite beschreibt norBIT das Werkzeug als „freie Software” und verweist auf das Repository [10].

Ein ehrlicher Hinweis zur Genauigkeit: Die Produktseite selbst nennt nur „freie Software”, ohne die Lizenzversion auszuschreiben – die verbindliche GPLv2-Aussage steht im Repository, nicht auf der Marketingseite. Wer das in einer Leistungsbeschreibung zitiert, sollte also auf GitHub verweisen. Und um es klar zu sagen: Dass norBIT dieses Werkzeug offen bereitstellt, ist eine Stärke, kein Makel – die ganze Argumentation dieses Beitrags ruht darauf.

Schritt für Schritt: mit norGIS aus NAS eine PostGIS-Datenbank bauen

Das ist der Kern. Die folgende Anleitung beschreibt den dokumentierten Weg über die grafische Oberfläche; für den automatisierten Betrieb gibt es zusätzlich das Shellskript alkis-import.sh und die PyQt-Oberfläche alkisImport.py aus dem Repository [10].

Voraussetzungen: eine funktionierende QGIS-Installation, PostgreSQL mit PostGIS-Erweiterung, der norGIS-ALKIS-Importer sowie das QGIS-Plugin „norGIS ALKIS-Einbindung” [12].

1. PostgreSQL/PostGIS bereitstellen. PostgreSQL installieren (z. B. über den EnterpriseDB-Installer) und PostGIS per StackBuilder nachrüsten. In pgAdmin eine neue Datenbank anlegen und über Extensions → Create → Extension die Erweiterung postgis hinzufügen [12].

2. Den ALKIS-Importer installieren. Am einfachsten über den OSGeo4W-Installer im „Advanced Mode” das Paket alkis-import auswählen und die Routine mit den Standardeinstellungen abschließen [12]. Damit liegen der GDAL/OGR-NAS-Treiber und die norGIS-Werkzeuge gemeinsam vor.

3. Datenbankverbindung im Importer eintragen. Im Importer die Zugangsdaten der PostGIS-Datenbank hinterlegen (Host, Port, Datenbankname, Benutzer, Passwort).

4. Datenmodell anlegen und Koordinatensystem setzen. Die Option „Datenbestand (neu) anlegen” aktivieren und das passende Koordinatensystem wählen [12]. Für aktuelle Lieferungen ist das in der Regel ETRS89/UTM (je nach Land z. B. EPSG:25832 oder 25833); der Importer unterstützt darüber hinaus ältere Bezugssysteme wie Gauß-Krüger und Soldner-Berlin. In diesem Schritt erzeugt norGIS das vollständige ALKIS-Datenmodell in der Datenbank – das ist die „automatische Datenmodell-Generierung”, die Ihnen das manuelle Anlegen Dutzender Objektart-Tabellen erspart.

5. NAS-Dateien hinzufügen. Über „Datei hinzufügen…” einzelne NAS-Dateien oder über „Verzeichnis hinzufügen” einen ganzen Ordner einer Lieferung auswählen [12].

6. Import starten. Mit „Starten” läuft der Import: norGIS ruft im Hintergrund ogr2ogr über den NAS-Treiber auf, schreibt die Objekte in die PostGIS-Tabellen und bereitet die Darstellung nach GeoInfoDok-Signaturkatalog vor [10]. Bei Bedarf helfen die Optionen „Importfehler überspringen” (robust gegen einzelne fehlerhafte Objekte) und „COPY benutzen” (schnellerer Masseninsert) [12]. Das Protokoll zeigt Fortschritt und Fehler in Echtzeit.

7. Ergebnis anzeigen. In QGIS das Plugin „norGIS ALKIS-Einbindung” über Datenbank → ALKIS → Einstellungen mit derselben PostGIS-Verbindung konfigurieren – danach sind Flurstücke, Gebäude und Buchwerk kartografisch korrekt sichtbar [11] [12].

Damit haben Sie aus einer rohen NAS-Lieferung eine vollwertige, abfragbare ALKIS-Datenbank gebaut – ohne eine einzige proprietäre Lizenz.

Wo der Import in der Praxis hakt

„NAS eingelesen” ist nicht dasselbe wie „Auskunft stimmt”. Diese Stolpersteine kosten in der Praxis die meiste Zeit:

• GeoInfoDok-Version und Template. Das GFS-Template und das PostgreSQL-Schema müssen zur Version Ihrer Lieferung passen – norGIS liefert getrennte Varianten für GeoInfoDok 6 und 7.1.2 [4]. Eine v6-Lieferung gegen ein 7.1-Schema zu importieren, führt zu stillen Mapping-Fehlern. Klären Sie die Version, bevor Sie starten.
• GDAL-Versionsfallen. Ab GDAL 3.7 ist die Umgebungsvariable NAS_GFS_TEMPLATE erforderlich (sie darf leer gesetzt werden, um das Schema aus dem Dateiinhalt abzuleiten); seit GDAL 3.10 lässt sich der Treiber zusätzlich über -if NAS erzwingen, und NAS_NO_RELATION_LAYER ist mit GDAL 3.8 entfallen [4]. Ein GDAL ohne Xerces-Unterstützung kann die NAS gar nicht erst lesen [4].
• Koordinatensystem. Das im Importer gewählte EPSG muss zur Lieferung passen. Ein falsch gesetztes Bezugssystem verschiebt die Geometrien – die Daten sind „da”, liegen aber an der falschen Stelle.
• Encoding und Geometrievalidität. Umlaute und Sonderzeichen in Eigentümer- und Lagebezeichnungen sowie ungültige Geometrien sind die Klassiker. Die Option „Importfehler überspringen” hilft, das eigentliche Problem aber sollte protokolliert und geprüft werden, statt es zu verschlucken.
• Performance bei großen Beständen. Bei kreis- oder landesweiten Lieferungen lohnt „COPY benutzen”, ausreichend dimensionierte Hardware und – nach dem Import – das Setzen räumlicher Indizes. Der Erstimport ist der teure Lauf; planen Sie ihn auf dem Produktivserver in eine lastarme Zeit ein.

Brücke zum Geoportal und zur Datenhoheit

Ein offener Import ist mehr als eine Kostenersparnis – er ist eine Architekturentscheidung. Wer die NAS über eine nachvollziehbare, quelloffene Kette in eine eigene PostGIS-Datenbank überführt, behält die Datenhoheit: Die Daten liegen im eigenen Rechenzentrum, das Schema ist offen dokumentiert, und kein Hersteller kann den Zugang zum eigenen Kataster verriegeln. Aus dieser Datenbank speisen Sie dann genau die Werkzeuge, die Sie brauchen – QGIS am Arbeitsplatz, WMS/WFS-Dienste für Fachverfahren, ein Masterportal als Bürger- und Fachportal.

Das passt zur Linie, die Bund und Kommunen zunehmend einschlagen: Open Source lässt sich rechtssicher beschaffen [13], und digitale Souveränität – Unabhängigkeit von einzelnen Anbietern, Kontrolle über die eigenen Daten – wird in der Verwaltung explizit als Ziel formuliert [14]. Eine offene Importkette ist genau das in der Praxis: kein Vendor-Lock-in beim Fundament Ihrer gesamten Geodatenhaltung.

Wer den Import offen im Griff hat, ist nicht im Produkt eingesperrt. Der norGIS-Import läuft dabei sauber gekapselt als eigener Prozess – die darüberliegende Auskunfts-, Fundlisten- und Portal-Schicht bleibt davon unberührt und frei gestaltbar. Wie diese Kette in einem betriebsfertigen Produkt zusammenläuft – Importpipeline, PostGIS-Datenbank, Backend-API und Portalschicht –, zeigt der Abschnitt Datenfluss von der Lieferung zur Auskunft in ALKIS Direkt.

Handlungsempfehlung

1. NAS-Bestand und GeoInfoDok-Version klären. Welche Version liefert Ihr Land (6 oder 7.1.x), in welchem Bezugssystem? Das entscheidet über Template und Schema.
2. PostGIS-Zielumgebung aufsetzen. PostgreSQL + PostGIS installieren, eine dedizierte Datenbank mit aktivierter PostGIS-Erweiterung anlegen.
3. norGIS-ALKIS-Import / GDAL-NAS-Treiber einrichten. Über OSGeo4W das Paket alkis-import installieren; auf eine Xerces-fähige, ausreichend neue GDAL-Version achten.
4. Import durchführen und validieren. Datenmodell anlegen, EPSG korrekt setzen, NAS-Dateien importieren – und anschließend Geometrievalidität, Vollständigkeit und Lage stichprobenhaft prüfen.
5. Anzeige- und Auskunftsschicht andocken. Ergebnis in QGIS über das alkisplugin sichtbar machen bzw. per WMS/WFS in Geoportal/Masterportal einbinden – und für den laufenden Betrieb die Aktualisierung planen.

Fazit

Der ALKIS-NAS-Import ist kein proprietäres Geheimnis, sondern ein offen gelöstes Problem. Mit dem GDAL/OGR-NAS-Treiber, dem GPLv2-lizenzierten norGIS-ALKIS-Import und PostgreSQL/PostGIS steht eine vollständige, im Produktivbetrieb erprobte und herstellerunabhängige Kette bereit – von der rohen NAS-Datei bis zum sichtbaren Buchwerk. Gewinner ist, wer diese Kette beherrscht und sauber betreibt: Er spart Lizenzkosten, behält die Datenhoheit und ist in der Beschaffung frei, über das zu verhandeln, was wirklich Aufwand macht – Betrieb, Integration und Aktualisierung. Die teure Black-Box braucht für diesen Schritt niemand.

Quellen

• [1] Arbeitsgemeinschaft der Vermessungsverwaltungen (AdV): GeoInfoDok – Dokumentation zur Modellierung der Geoinformationen des amtlichen Vermessungswesens (AAA-Modell). adv-online.de
• [2] LGLN Niedersachsen: AAA-Datenmodell (AFIS, ALKIS, ATKIS). lgln-geodaten.niedersachsen.de
• [3] Markus Seifert: Das AFIS-ALKIS-ATKIS-Anwendungsschema als Komponente einer Geodateninfrastruktur, zfv 2/2005. PDF, geodaesie.info
• [4] GDAL Documentation: NAS – ALKIS (vector driver). gdal.org
• [5] PostNAS-Suite: PostNAS – Open-Source-Werkzeuge für ALKIS/NAS (Erweiterung von OGR/GDAL). postnas-suite.github.io
• [6] OSGeo: GDAL/OGR 1.8.0 Released (NAS unter den neuen OGR-Treibern). osgeo.org
• [7] norBIT: alkisimport – README (Frontend zum NAS-Import nach PostgreSQL/PostGIS, Lizenz GPLv2). github.com/norBIT/alkisimport
• [8] norBIT: alkisimport – LICENSE (GNU General Public License, Version 2). github.com
• [9] norBIT: alkisimport – alkisImport.py (Quellcode-Header: „version 2 of the License, or (at your option) any later version”). github.com
• [10] norBIT GmbH: norGIS ALKIS-Import (Produktseite: „freie Software”, Aufruf von ogr2ogr, Code auf GitHub). norbit.de/68
• [11] norBIT: alkisplugin – QGIS-Plugin zur Einbindung von ALKIS-Daten aus norGIS-Importen (GPLv2). github.com/norBIT/alkisplugin
• [12] map-site.de (Lernplattform): ALKIS-NAS-Import mit norGIS – Schritt für Schritt. lernplattform.map-site.de
• [13] Bundesministerium für Digitales und Staatsmodernisierung (BMDS): Open Source rechtssicher beschaffen. bmds.bund.de
• [14] Deutsches Institut für Urbanistik (Difu): Digitalisierung in Kommunen souverän gestalten. difu.de