Eingeführt Anfang der 1990er von ESRI, ursprünglich für ArcView entwickelt.

Das Shape-Format (Datei-Endung .shp und andere) ist das am weitesten verbreitete und vermutlich immer noch am meisten benutzte Format für Geodaten. Dabei ist es eigentlich obsolet und genügt modernen Anforderungen für das Datenbank-basierte Speichern von Geodaten schon lange nicht mehr. Das Shape-Format kann für die Speicherung einfacher Geodaten tatsächlich gut genug sein, sofern man keinen hohen Anspruch auf Feld-Formate und Sachdaten-Inhalte hat.

Vielen Nutzern ist nur selten bewußt, daß dieses Format erhebliche Nachteile mit sich bringt, die überwiegend auf das verwendete Datenbank-Backend zurückzuführen sind:

• Es dürfen nur maximal 10 Zeichen für einen Feldnamen vergeben werden. Das führt oft zu unverständlichen Abkürzungen.
• Es dürfen maximal 255 Attribute (= Felder) pro Tabelle gesetzt werden.
• Ein Textfeld kann maximal 254 Zeichen aufnehmen.
• Numerische Werte und Datumsangaben werden als Zeichen gespeichert. Das kann Probleme beim Rechnen und Runden erzeugen.
• Es gibt keine Möglichkeit, ein Feld mit NULL (im engeren Sinn) zu belegen! Tatsächlich werden Werte kleiner -10³⁸ als "no data" gewertet.
• Es gibt keine Feldtypen für Boolean, BLOB u.a.
• Eine Shape-Datei darf maximal 2 GB groß sein. Das klingt viel, muß aber nicht für alle Aufgaben reichen.
• Es kann nur 1 Geometrietyp (Punkt, Linie oder Polygon) pro Datei gespeichert werden.
• Es können keine topologischen Informationen gespeichert werden. Das Shape-Format wurde ursprünglich ohne Topologie zugunsten höherer Performance konzipiert.
• Die Unterstützung von Unicode ist nur rudimentär, meist sind ASCII-konforme Abkürzungen erforderlich.
• Die 3D-Unterstützung ist im Prinzip nicht vorhanden.

Die technischen Spezifikationen des Shape-Formats können hier nachgelesen werden.

Das Shape-Format ist proprietär und wird von ESRI kontrolliert. Gleichwohl sind dessen Spezifikationen offen, weshalb das Format so gut von GIS-Systemen verarbeitet werden kann.

Wie oben erwähnt, werden Shape-Dateien auch heute noch für den Austausch von Geodaten (hauptsächlich Geometrien!) bevorzugt. Hauptgrund ist das problemlose Einlesen des Formats in nahezu jede GIS-verarbeitende Software. Das Format kann plattformübergreifend und sehr unkompliziert den Datenaustausch ermöglichen. Zahlreiche Geo-Fachsoftware, die von Ingenieurbüros und Staatlichen Geologischen Diensten (SGD) zur Verarbeitung von Geoinformationen verwendet werden, kennen sogar ausschließlich den Im- oder Export des Shape-Formats. Dies ist beispielsweise der Fall bei der weitverbreiteten Software GeODin, die von SGDs zur Verwaltung von Schichtenverzeichnissen, Laboranalysen etc. verwendet wird. Eine andere weitverbreitete Software zur 3D-Modellierung »GoCAD« kann das Shape-Format zwar lesen, aber nicht schreiben. Für den Export zu einem GIS gelingt hier der Umweg über das CAD-Format .dxf

Auch von »offizieller Seite« (Behörden-Webseiten) werden Geodaten fast ausschließlich im Shape-Format angeboten. In den meisten Fällen ist dieser Rückgriff auf den »kleinsten gemeinsamen Nenner« beim Geodaten-Austausch übertrieben und besser mit einer Geodatenbank wie GeoPackage gelöst.

Eines der jüngsten Beispiele ist die Bereitstellung der BGE-Ausweisungsgebiete für die bundesweite Suche nach einem Endlager für radioaktive Abfallstoffe (Link). Die Shape-Dateien kommen als ZIP gebündelt, außerdem ist jede Shape-Datei (mit ihren Mehrfachdateien) in einem eigenen Verzeichnis gelagert, obwohl sie nach Ausweisungskategorien sinnvoll hätten zusammengefaßt werden können. Von den vielen topologischen Fehlern der Daten abgesehen, ist dies keine bürgerfreundliche Bereitstellung von Fachdaten.

Über die Jahre sind diverse Dateiformate erschienen, die das Shape-Format ablösen wollen, darunter das bemerkenswerte SQLite und GeoJSON. An dieser Stelle möchte ich nur auf das GeoPackage eingehen, das für die Nachfolge am würdigsten erscheint. Außen vor bleiben bei dieser Betrachtung Server-gestützte Formate (PostgreSQL u.a.).

Das GeoPackage-Format (Endung .gpkg) wurde 2014 von OGC (Open Geospatial Consortium) eingeführt und ist quelloffen.

GeoPackage basiert auf SQLite (Version 3), das um räumliche Datentypen erweitert wurde. Es ist plattformunabhängig. Es braucht keine Server-Struktur, und der Zugriff auf die Geodaten kann ohne Zusatzsoftware erfolgen. Schon jetzt wird GeoPackage von allen wichtigen Desktop-GIS unterstützt.

Warum ist dieses Format nun besser als Shape?

Zunächst einmal hat es nicht die Datenbank-bezogenen Mankos, die das Shape-Format so plagen:

• Unicode-Support
• Keine Begrenzung bei der Länge von Feldnamen oder Zeichenfolgen (bei Feldinhalten)
• Feldtypen für ganzzahlige oder Dezimalzahlen, Boolean, BLOB etc.
• NULL-Werte
• Maximale Dateigröße liegt bei 140 TB
• Die Speicherung von topologischen Informationen ist selbstverständlich.

Das kann GeoPackage außerdem:

• Neben Vektordaten können auch Rasterdaten in der GeoPackage-Datei gespeichert werden. Das Erstellen von Rasterkatalogen ist daher kein Problem.
• Es können nichtlineare Geometrietypen (Kreisbögen, Splines) gespeichert werden.
• Metadaten und Informationen zur Projektion sind integriert.
• Attributdomänen (Stichwort »Gültigkeitsbereiche«) und Subtypen können definiert werden.
• Die Erstellung von Tabellenbeziehungen ist möglich.
• Flächen und Längen können automatisch berechnet werden.
• Es können Annotation-Feature-Classes genutzt werden.
• Zahlreiche zusätzliche Informationen können in der GeoPackage-Datei hinterlegt werden: Drucklayouts, Style-Dateien, SVGs oder Bilddateien (Logos), sogar eine oder mehrere QGIS-Projektdateien!
• Da das Format auf SQLite basiert, ist die Unterstützung von SQL-Kommandos vorzüglich.
• Die Datenbank kann leicht durch Plug-Ins erweitert werden.
• Gegenüber dem Shape-Format gibt es einen Dateigröße-Vorteil bei der Speicherung derselben Geodaten. Gegenüber anderen Formaten (z.B. ESRI Geodatabase) kann es auch einen Geschwindigkeitsvorteil beim Laden der Geodaten geben.

Bei all den Vorzügen ist das GeoPackage-Format nicht für die parallele bzw. synchrone Bearbeitung durch mehrere Nutzer geeignet (Multi-user-GIS-Projekte!). Ein Schreibvorgang erzeugt einen Datenbank-weiten lock, während das Lesen von Daten derselben Quelle durch mehrere Benutzer kein Problem ist. An dieser Stelle nutzt man lieber PostgreSQL oder vergleichbares.

Übersichtliche Informationen zum GeoPackage-Format werden außerdem auf GitHub bereitgestellt.

Der Layer erscheint nun als Duplikat im QGIS-Projekt – nämlich einmal aus der ESRI Shape-Datei, und einmal aus der neuen Quelle (Geopackage-Datei). Derjenige Layer, der auf Shape basiert, kann mit Strg+D gelöscht werden. Die Arbeitsschritte sind mit allen Layern zu wiederholen, die man in die GeoPackage-Datei übertragen möchte. Auch Rasterdaten können dort abgelegt werden (Vorsicht vor riesigen Datenbank-Dateien!).

Es empfiehlt sich, zusammengehörige Geo-Themen jeweils in einer GeoPackage-Datei abzulegen, z.B.:

• Hydro.gpkg -> Umrisse von Seen, Flüssen usw.
• Infrastruktur.gpkg -> Straßennetz, Eisenbahn, Fähren usw.
• Umwelt.gpkg -> Flächennutzung, Waldbestand usw.

Man kann selbstverständlich auch alles in eine große GeoPackage-Datenbank quetschen.

Wurde viel in einer Datenbank verändert (Löschungen usw.), kann eine Neustrukturierung über den Menüpunkt "Datenbank | VACUUM ausführen" erfolgen.

Allem voran: Das ESRI Geodatabase-Format (Personal Geodatabase, File Geodatabase) ist proprietär und funktioniert nur im ESRI/ArcGIS-Ökosystem sinnvoll. Die Nutzung dieses Geodaten-Formats ist daher auf diejenigen Plattformen beschränkt, auf denen auch ein ArcGIS funktioniert. Schreibzugriffe auf die Daten sind nur mit ArcGIS möglich, während Lesezugriffe auch von anderen GIS (auch QGIS) unterstützt werden.

Gegenüber Shape-Dateien haben ESRI Geodatenbanken viele der Vorzüge, die auch beim GeoPackage genannt wurden: Keine Größenbeschränkung auf 2 GB, viele Datentypen, Integration von Metadaten, Zeichencodierung, Koordinatensystem etc. ESRI Geodatenbanken sind eben moderne Datenbanken, die selbstverständlich weiterentwickelt sind als das sehr alte Shape-Format.

Neben dem nicht zu unterschätzenden Nachteil, daß ESRI Geodatenbanken allein im ArcGIS-Ökosystem bearbeitet werden können, tritt ein weiterer Nachteil, der die Datenweitergabe betrifft: Wer sich bislang daran gestört hat, daß ein halbes Dutzend Shape-Dateien ein ganzes Verzeichnis bis zur Unübersichtlichkeit füllen, wird es mit ESRIs Geodatenbanken nicht anders sehen: Eine einzelne Datenbank wird als Verzeichnis angelegt, darin liegen Dutzende Datenbank-Dateien. Auch hier ist die Weitergabe der Daten nicht ohne Zwischenschritt (komprimiertes Archiv) sinnvoll.

Zur Verteidigung muß man sagen, daß ArcMap die Möglichkeit bietet, das gesamte GIS-Projekt als sog. Kartenpaket (.mpk, map package) abzuspeichern. Das ist dann tatsächlich eine einzelne Datei, die neben der Projektdatei auch alle referenzierten Layer enthält. Selbstverständlich läßt sich so ein Kartenpaket nur von ArcMap lesen. Und zur Weitergabe eines einzelnen Geodaten-Standes (z.B. Austausch gerade bearbeiteter Umrisse von Moorflächen) ist dieser Weg viel zu umständlich.

Nun, was hat die Desktopdatenbank Access mit GeoPackage zu tun? Eines meiner Projekte beispielsweise! Und die Überlegung, von Access zu GeoPackage zu migrieren.

Tatsächlich ist es beruflich so, daß ich eine meiner Datensammlungen in einer Access-Datenbank verwalte, und die Daten zusätzlich in einem QGIS-Projekt visualisieren möchte. Es handelt sich um eine Datenbank über Bohrungen und Aufschlüsse, deren Informationen ich im GIS darstellen möchte. Um den Geobezug herzustellen, ist jedem Datensatz ein Koordinatenpaar zugeordnet (z.B. Gauß-Krüger-Koordinaten eines Bohrpunktes). In regelmäßigen Abständen exportiere ich die Gesamttabelle zu einem Excel-Dokument, und dieses wiederum ins .csv-Format. Anschließend lade ich die .csv-Datei in QGIS ein und benennen die Spalten, die Koordinaten enthalten. So erscheinen die Punkte auf meiner Karte.

Das klingt nicht nur unnötig kompliziert, sondern ist es auch. Insbesondere, wenn ich dieselben Daten auch in einer GeoPackage-Datenbank vorhalten könnte. Warum sollte ich diesen Schritt also tun?

Zunächst einmal würde ich mich von der Access-Abhängigkeit lösen. Ich wäre nicht länger auf ein MS Office-Ökosystem angewiesen, sondern könnte die Daten im GeoPackage beispielsweise genauso auf meinem Linux-System bearbeiten. Dann dachte ich über weitere Vorzüge und Nachteile der Migration nach:

Im GIS könnte ich unmittelbar raumbezogene Abfragen machen, z.B. (bei Überlagerung mit einer Umrißkarte der Bundesländer Deutschlands) »Zeige mir alle Einträge, die in Hessen liegen«. Das wäre in der Access-Datenbank nur dann möglich, wenn ich in einem zusätzlichen Feld die Namen der Bundesländer hinterlegen würde.

Bei der Arbeit in der QGIS-Attributtabelle würden mir außerdem folgende Bequemlichkeiten geboten:

• Ich kann mir übersichtliche SQL-Abfragen zusammenstellen und unter spezifischen Namen speichern. (Na gut, fast dasselbe mache ich in Access mit Abfragen.)
• Das Setzen von Werten für viele Felder ist einfacher: Einträge markieren, dann in der Bearbeitungsleiste Feld auswählen, Wert setzen, bestätigen (nächstes Bild, roter Pfeil). Auf diese Weise kann ich Hunderte Datensätze auf einmal mit derselben Information füllen, ohne auf umständliche SQL-Aktualisierungsabfragen zurückgreifen zu müssen.
• Mithilfe der Spaltenstatistik kann ich mir rasch einen statistischen Überblick zu einem numerischen Feld verschaffen (Min-Max, Mittelwert, Histogramm etc.)

Auf der Gegenseite fällt mir eigentlich nur noch ein Vorzug ein, den ich bei Access gerne nutze: Ich kann mir Startformulare basteln, auf denen ich selbstberechnende Statistiken anordne, und auch Buttons und Links, die auf andere Tabellen, Abfragen, Formulare, externe Dateien etc. verlinken. Ich glaube, das könnte ich verschmerzen.