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:
Die technischen Spezifikationen des Shape-Formats können hier nachgelesen werden.
Das Shape-Format ist darüber hinaus ein sog. Mehrdateien-Format (multi file format), d.h. es sind mindestens drei Dateien notwendig, um eine benutzbare Datei laden zu können: Das sind die Dateien .shp (Geometriedaten), .dbf (Sachdaten = Datenbank) und .shx (Geometrieindex zur Verknüpfung der Attribute der .dbf-Datei). Darüber hinaus gibt es pro Shape-Datei zahlreiche (optionale) Dateien, die z.B. Informationen zur Projektion oder Zeichencodierung enthalten. Ein Verzeichnis kann daher rasch mit Shape-Dateien »vollaufen«. Manchmal geht der Überblick verloren, und die Weitergabe der Dateien ist nur als (komprimiertes) Archiv sinnvoll.
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:
Es können mehrere Geometrietypen pro Datei gespeichert werden, d.h. man kann ein gesamtes GIS-Projekt mit allen Features in einer einzigen Datei speichern. Das erleichtert die Weitergabe der Daten enorm.
Das kann GeoPackage außerdem:
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.:
Man kann selbstverständlich auch alles in eine große GeoPackage-Datenbank quetschen.
Die Verwaltung der Inhalte einer GeoPackage-Datenbank erfolgt vorzugsweise im QGIS-eigenen Datenbank-Manager (DB-Verwaltung), aufzurufen über den bezeichnenden QGIS-Menüpunkt "Datenbank".
Zunächst muß die Datenbank hinzugefügt werden. Über einen Rechtsklick auf "GeoPackage" (Abb., grüner Pfeil) kann eine neue Verbindung hergestellt werden. Es können beliebig viele GeoPackage-Datenbanken angefügt (und per Rechtsklick | Entfernen) wieder entfernt werden.
Nun kann man alle darin enthaltenen Layer erkennen (Abb., pinke Pfeile). Rechts im Fenster erhält man Infos über den Inhalt (z.B. Anzahl der Datensätze) sowie eine Vorschau auf Attribut-Tabelle und Geometrie. Per Rechtsklick auf die einzelnen Layer können diese gelöscht oder zum Kartenprojekt hinzugefügt werden (falls noch nicht geschehen).
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:
QGIS-Attributtabellen unterstützen die Fixierung von Spalten und auch bedingte Formatierungsregeln, d.h. ich kann mir Einträge farblich hervorheben, die ein bestimmtes Kriterium erfüllen (z.B. alle Bohrungen, deren Endteufe > 2000 m ist).
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.