Bitte beachtet auch das Update vom 15.01.2026.
Wer mit Geodaten zu tun hat, kommt oft in die Situation, diese Daten mit geeigneten Werkzeuge zu vereinfachen. Oft wird dazu der lokale GIS-Client mit Funktionen wie Clean oder Simplify genutzt. Das heißt aber auch, dass die Clienten auch bei Nutzung einer Datenbank jeweils nur für sich selbst diese Arbeiten ausführen und ggf. kein Anderer davon partizipiert. Die Datenbank selbst mit ihren spatialen Erweiterungen bietet heutzutage jede Menge leistungsfähiger Funktionen für diese Aufgaben an. Was spricht also dagegen, diese auch gleich dort zu nutzen, z. B. um Abfragen performanter zu machen oder Datenbestände zentral zu vereinfachen? Einen lesenswerten Beitrag dazu „PostGIS Performance: Simplification“ [1] von Paul Ramsey habe ich via X (ehemals Twitter) [2] im crunchydata-Blog [3] gefunden. Dort werden eine Vielzahl nützlicher Vereinfachungs-Funktionen direkt in der Datenbank, aber auch ihre Grenzen vorgestellt:
- ST_Segmentize und ST_RemoveRepeatedPoints
- ST_Simplify und ST_SimplifyVW
- ST_SnapToGrid
- ST_ReducePrecision
- ST_CoverageClean und ST_CoverageSimplify.
[1] … https://www.crunchydata.com/blog/postgis-performance-simplification
[2] … https://x.com/crunchydata/status/1998497697993498791?s=20
[3] … https://www.crunchydata.com/blog
Da sind ja einige wirklich nützliche, neue Funktionen dabei! (e.g. die Coverage Algorithmen). Danke für den Find!
In deinem Text lese ich heraus, dass du im Umkehrschluss meinst, dass bei Nutzung dieser Vereinfachungsfunktionen in der Datenbank auch andere Benutzer mit Zugriff auf die Datenbank davon profitieren, also Redundanz bei der Generalisierung vermieden wird.
—-
-> „Das heißt aber auch, dass die Clienten auch bei Nutzung einer Datenbank jeweils nur für sich selbst diese Arbeiten ausführen und ggf. kein Anderer davon partizipiert.“
—-
Das ist mit den bloßen Datenbankfunktionen aber noch nicht gegeben, die werden ja, so wie sie sind, erst wieder bei jedem einzelnen Aufruf ausgeführt. Da muss ein Ingenieur zum Beispiel noch einen zusätzlichen Cache mit den generalisierten Daten einziehen, damit das Redundanz vermeidet. Und damit sind wir bei der ganzen Komplexität, die MRDBs („multi representation database system“s) mit sich bringen.
Möglicherweise meintest du das bereits so, es liest sich für mich aber wie oben beschrieben.
Danke für den Hinweis. Ich meinte das zentrale Vereinfachen von Datenbeständen direkt in der Datenbank, also z. B. ein Clean mit dem Ergebnis einer neuen, bereinigten Tabelle, die dann allen zur Verfügung steht. Ungefähr so:
-- Clean the coverage, merging gaps with width <= 1CREATE TABLE example_clean ASSELECT id, ST_CoverageClean(geom, 1) OVER () AS GEOM
FROM example;
Ergänzung: es gibt noch ein Update inkl. Beispiel zum Thema, siehe https://geoobserver.de/2026/01/15/update-vereinfachung-bereits-in-der-geo-datenbank/