Metainformationen zur Seite
Das GeoPackage (GPKG)
Ein GeoPackage (GPKG) ist ein offenes, plattformübergreifendes Format für geografische Informationen, das auf einer SQLite-Datenbank basiert. Es wurde entwickelt, um eine effiziente Speicherung und den Austausch von geografischen Daten zu ermöglichen.
Das GeoPackage (*.gpkg) ist ein ausgesprochen leistungsstarkes Geodatenformat 1). Es kommt augenscheinlich als einfache (Geo-)Datei daher (wie viele andere: GeoJSON, Shapefile, KML/KMZ…), tatsächlich handelt es sich aber um eine „Ein-Datei-Datenbank“ auf SQLite3-Basis (Ähnlich: SpatiaLite). Das heißt, das GeoPackage vereint alle Vorteile einer GeoDatenbank mit dem Komfort einer einzelnen, kleinen und leicht austauschbaren Datei. In einer einzigen *.gpkg lassen sich sowohl (Multi-)Linien, (Multi-)Punkte, (Multi-)Polygone, (Multi-)Kurven… sowie Rasterdaten, geometrielose Tabellen und Texte abspeichern. Es gibt dabei kaum Einschränkungen:
- Zeichen- und Feldlängen: unbegrenzt (nur durch SQLite-Limits beschränkt)
- Dateigröße: Nahezu unbegrenzt (bis zu 140 TB, abhängig vom Dateisystem des OS)
- Anzahl der darin enthaltenden Objekte: unbegrenzt
- Austauschbarkeit: Offener Standard, daher mit OpenSource-Werkzeugen für alle verwendbar
Vorteile des GeoPackages
- Einheitliches Format: Ein GeoPackage kann sowohl Vektor- als auch Rasterdaten in einer einzigen Datei speichern. Dies vereinfacht den Datenaustausch und die Verwaltung massiv.
- Hohe Performance: Dank der SQLite-Basis bietet das GeoPackage eine schnelle Datenzugriffs- und Abfrageleistung (Indizierung).
- Plattformunabhängig: Da es auf SQLite basiert, kann ein GeoPackage auf verschiedenen Betriebssystemen (Linux, macOS, Windows, Android) und Geräten verwendet werden.
- Offener Standard: GeoPackage ist ein offener Standard, der vom Open Geospatial Consortium (OGC) entwickelt wurde; es gibt keine Lizenzkosten.
- Effiziente Speicherung: Gekachelte Rasterdaten lassen sich komprimiert ablegen (PNG oder JPEG je Kachel). Vektordaten werden nicht komprimiert – eine GeoPackage-Datei ist bei gleichem Inhalt oft größer als ein Shapefile, dafür enthält sie alles in einer Datei.
- Erweiterbarkeit: Nutzende können benutzerdefinierte Tabellen und Schemata hinzufügen (z.B. für QGIS-Projekteinstellungen innerhalb der DB).
- Indexerzeugung: GeoPackage nutzt R-Tree Spatial Indizes, was die Abfragegeschwindigkeit auch bei Millionen von Objekten hoch hält.
- FID (Feature ID): GeoPackage garantiert stabile, eindeutige Feature-IDs (Primary Keys).
- Stile speichern: Es können mehrere QGIS-Stile direkt innerhalb eines GeoPackages gespeichert werden.
- Zeichensatz und KBS: UTF-8 Encoding und Koordinatenbezugssysteme (KBS) sind fest definiert – das beendet das „Umlaute-Chaos“ alter Formate.
Mögliche Geometrietypen in einem GeoPackage
| Geometrietyp | Beschreibung |
|---|---|
| Punkt | Ein einzelner Ort im Raum, definiert durch Koordinaten (x, y). |
| Linie | Eine Verbindungslinie zwischen zwei oder mehr Punkten. |
| Polygon | Eine Fläche, definiert durch einen geschlossenen Linienzug aus mindestens vier Koordinatenpaaren – das erste und das letzte sind identisch. |
| Multipunkt | Eine Sammlung von Punkten (als ein Datensatz). |
| Multilinie | Eine Sammlung von Linien (als ein Datensatz). |
| Multipolygon | Eine Sammlung von Polygonen (als ein Datensatz). |
| Kurve | Eine gekrümmte Linie (Circular String). |
| Multikurve | Eine Sammlung von gekrümmten Linien. |
| Oberfläche (Surface) | Eine komplexe Fläche, die aus mehreren Polygonen bestehen kann. |
| Geometriesammlung | Eine Sammlung von verschiedenen Geometrien (Punkte, Linien, Polygone gemischt). |
Anwendungsbeispiele für GeoPackage
- Katasterverwaltung: Eine Behörde nutzt GeoPackage, um Flurstücksdaten (Polygone) und Eigentumsinformationen (geometrielose Tabellen) effizient in einer einzigen Datei zu speichern. Der Vorteil: Alle Daten sind stets synchron (Relationen) und können leicht ausgetauscht werden.
- Umweltmonitoring: Ein Umweltüberwachungsprojekt speichert sowohl Echtzeit-Daten von Sensoren (z. B. Luftqualitätsmessungen als Punktdaten) als auch historische Wetterdaten (Tabellen ohne Geometrie) in einem GeoPackage. Die Kombination erlaubt SQL-basierte Analysen in einem einzigen, kompakten Dateiformat.
- Krisenmanagement: Ein Team zur Katastrophenvorsorge speichert Evakuierungsrouten (Linien), Risikogebiete (Polygone) und Hilfseinrichtungen (Punkte) in einem GeoPackage. Im Notfall kann dieses Paket schnell an Einsatzkräfte (auch mobil) verteilt werden.
- Landwirtschaft: Ein Beratungsunternehmen speichert Satellitendaten (Raster), Bodentypen (Polygone) und Wetterstationen (Punkte) in einem GeoPackage. Durch die Kombination können landwirtschaftliche Betriebe detaillierte Analysen durchführen.
- Tourismus: Eine Gemeinde speichert Wanderwege (Linien), Sehenswürdigkeiten (Punkte) und Unterkunftsangebote (geometrielose Tabellen) in einem GeoPackage. Digitale Karten können so einfach an Gäste verteilt werden.
Vergleich: GeoPackage in der Praxis
| Merkmal | GeoPackage | CSV + Shapefile | PostgreSQL/PostGIS |
|---|---|---|---|
| Speicherung | Alles in einer Datei (Vektor, Raster, Tabellen, Styles) | Geometrien in Shapefile (min. 3 Dateien), Attribute teils ausgelagert | In einer zentralen Server-Datenbank |
| Austausch | Sehr einfach (Copy & Paste einer Datei) | Umständlich (mehrere Dateien zwingend erforderlich) | Komplex (Dump/Restore oder Schnittstelle nötig) |
| Logik | Datenbank-Funktionalität (SQL, Views, Trigger) | Keine Datenbankfunktionalität | Sehr leistungsfähig (Enterprise Level) |
| Performance | Hoch (Dank R-Tree Indizes) | Niedrig (kein echter Raumindex bei CSV) | Sehr hoch, aber aufwändige Einrichtung |
Vergleich von GeoPackage mit anderen Formaten
| Merkmal | GeoPackage | SpatiaLite | ESRI® FileGDB | ESRI® ShapeFile | GeoJSON | KML |
|---|---|---|---|---|---|---|
| Datenstruktur | Vektor, Raster, Kacheln | Vektor, (Raster via Extension) | Vektor, Raster | Nur Vektor | Nur Vektor | Vektor, (Raster als Overlay) |
| Dateigröße | Unkomprimiert (Raster-Kacheln optional komprimiert) | Unkomprimiert | Komprimiert | Groß (dBase IV Basis) | Textbasiert (Groß) | Textbasiert (oder KMZ gepackt) |
| Plattform | Alle (Cross-Platform) | Alle | Eingeschränkt (Proprietär*) | Alle | Alle | Alle |
| Open Source | Ja | Ja | Nein | Ja (Spezifikation) | Ja | Ja |
| Erweiterbarkeit | Hoch | Hoch | Mittel | Gering | Mittel | Mittel |
| Geometrien | Alle (OGC Standard) | Alle | Alle | Punkt, Linie, Polygon | Punkt, Linie, Polygon | Punkt, Linie, Polygon |
| Multi-Layer | Ja | Ja | Ja | Nein (1 Layer pro Datei) | Nein (meist Single Feature Collection) | Ja |
| Performance | Hoch | Hoch | Hoch | Mittel bis Schlecht | Schlecht (Parsing) | Schlecht |
| SQL-Fähig | Ja (Vollständig) | Ja | Ja (Eingeschränkt via API) | Ja (Eingeschränkt via OGR) | Nein | Nein |
| Encoding | UTF-8 (Fix) | UTF-8 | UTF-8 | Systemabhängig (Fehleranfällig!) | UTF-8 | UTF-8 |
| Speicherart | Datei (SQLite DB) | Datei (SQLite DB) | Verzeichnis (Ordnerstruktur) | Dateipaket (min. .shp, .shx, .dbf) | Textdatei | Text-/XML-Datei |
GeoPackage: das Standardformat von QGIS
QGIS kann schon lange mit GPKGs umgehen und behandelt das GeoPackage als Standard und bevorzugtes Format - das merkt man deutlich! Und es funktioniert! Das Arbeiten mit einer *.gpkg in QGIS ist kinderleicht und stellt einen selten vor Konflikte - anders als beim ShapeFile.
Übrigens: Das GeoPackage ist auch mit ArcGIS Pro® kompatibel! Alte ArcMap Versionen benötigen ggf. Updates oder Erweiterungen.
Ziehen Sie doch einmal in QGIS3 mit Drag'n'Drop einen beliebigen Layer aus dem Layerfenster auf eine GeoPackage-Datei im Browserfenster. Der Layer wird sofort importiert und funktioniert hier mit all den Vorzügen einer Geo-Datenbank. So hat man im Handumdrehen ein stark beschränktes ShapeFile in eine Datenbank integriert!
Man kann ein Shapefile in ein GeoPackage importieren. Man kann aus dem GeoPackage heraus auch ShapeFiles erstellen (exportieren) - es muss aber beachtet werden, dass ein Shapefile nur 10 Zeichen in den Attributnamen zulässt und max. 2 GB groß sein darf! Ein GeoPackage kennt diese Limits aus den 90er Jahren nicht.
Warum GeoPackage "State-of-the-Art" ist (IT-Perspektive)
Für IT-Profis, Data Scientists und GIS-Administratoren ist das GeoPackage weit mehr als nur ein Container. Es ist eine Serverless Database. Hier sind die harten Fakten, warum es technisch notwendig ist:
- ACID-Konformität: Da GeoPackage auf SQLite basiert, ist es transaktionssicher (Atomicity, Consistency, Isolation, Durability). Bei einem Systemabsturz oder Stromausfall während eines Schreibvorgangs ist die Datenbank in der Regel geschützt. Ein Shapefile (dBase) ist danach oft korrupt.
- Full SQL Support & Views: Man kann komplexe SQL-Abfragen (inklusive Joins und Aggregationen) direkt auf der Datei ausführen und sogar Views (virtuelle Layer) dauerhaft speichern. QGIS kann diese Views laden – das ermöglicht eine dynamische Datenhaltung ohne Redundanz.
- No „Sidecar-Hell“: Das Versenden von Geodaten per E-Mail scheitert bei Shapefiles oft, weil Absendende vergessen, die zwingend notwendigen
.shxoder.dbfDateien anzuhängen. Ein GeoPackage ist eine Datei. Punkt. - Grenzen: Beim gleichzeitigen Schreiben durch mehrere Personen und auf Netzlaufwerken kommt es zu Sperrkonflikten – SQLite ist darauf nicht ausgelegt. Sobald mehrere Arbeitsplätze denselben Bestand bearbeiten, ist eine echte Datenbank (PostGIS) die bessere Wahl.
- Direct Edit: Im Gegensatz zu CSV oder GeoJSON, die oft komplett in den Arbeitsspeicher geparst werden müssen, erlaubt GeoPackage das direkte, performante Bearbeiten (Update/Insert) riesiger Datensätze direkt auf der Festplatte.