Re: [FOSSGIS-Talk] QGIS - Flächenberechnung per Trigger für GeoPackage auch ellipsoidisch möglich?

[Nane]

Hallo Bernd,

vielen Dank für Deine Hilfe und Erklärungen! Das was ich schon vermutet 
habe, habe ich nun auch verstanden! Bisher haben wir das immer mit dem 
Vorgabewert so gemacht wie du vorgeschlagen hast. Es war etwas 
ungeschickt von mir nach dem Trigger zu fragen, den man ja wirklich 
einfach umgehen kann. Aber es gibt auch noch ein View in dem GeoPackage, 
in dem aus einem Layer Flächen nach verschiedenen Gruppierungen und 
Filtern als Ergebnistabelle berechnet werden. In QGIS ist das sehr 
aufwendig (mit festen Feldern) oder macht das Projekt sehr langsam (mit 
virtuellen Feldern). Mit einem View geht das nun ganz wunderbar und ich 
bin begeistert wie performant das ist. Aber auch hier nutze ich die 
Funktion ST_Area(). Auf den Trigger können wir also gut verzichten, auf 
den View aber nicht. Es bleiben meinem Verständnis nach zwei 
Möglichkeiten (es handelt sich um ca. 10.000 Flächen 
(Kleingartenanlagen, aufgeteilt nach ihrer Nutzung), verteilt innerhalb 
einer Großstadt, im Koordinatensystem ETRS89 (EPSG 25832):

1. Wir steigen auf SpatiaLite um (da ist mir noch nicht ganz klar, wo 
ich überall den Code ändern müsste und will das mal testen, ob ich das 
hinbekomme)
2. Wir bleiben bei GeoPackage und nutzen planimetrische Berechnungen

Wäre einer dieser Varianten aus QGIS-fachlicher Sicht die zu 
bevorzugende? Weil z.B. ellipsoide Berechnungen die besser geeigneten 
sind als die planimetrischen. Oder weil GeoPackage nun mal der bessere 
Standard für QGIS ist? Ich kann nicht einschätzen, ob durch die 
Umstellung auf SpatiaLite Änderungen/ Schwierigkeiten kommen können, die 
ich im Moment noch nicht kenne. Übersehe ich da noch etwas?

Herzliche Grüße von

Nane


Am 20.10.2026 um 10:44 schrieb Bernd Marcus via FOSSGIS-Talk-Liste:
> Hallo Nane,
>
> ein Blick in die Referenzliste der libspatialite Bibliothek (https://www.gaia-gis.it/gaia-sins/spatialite-sql-5.1.0.html#p8) offenbart, dass die Funktion
> st_area() dank der RTTOPO Erweiterung auch die ellipsoide Fläche von Polygonen
> berechnen kann. Allerdings müssen bei Verwendung von
> ST_Area( s Surface , use_ellipsoid Boolean )
> die Koordinaten in Längen- und Breitengraden vorliegen. Ist dies nicht der
> Fall, wird NULL als Resultat zurückgegeben.
>
> Liegen deine Polygone in einem metrischen Koordinatensystem vor, steht also
> erst einmal eine Reprojektion der Geometrien an. Dies lässt sich natürlich
> auch innerhablb eines Trigges realisieren, scheitert jedoch innerhalb eines
> Geopackages, da die für die Transformation notwendige Meta-Tabelle
> "spatial_ref_sys" nicht zur Verfügung steht.
>
> Mit libspatialite lassen sich zwar Geopackages erstellen, abfragen und
> manipulieren, die Bibliohek hatte allerdings nie den Anspruch, alle Funktionen
> dieser räumlichen Erweiterung für SQLite auf Geopackages zu übertragen. Willst
> du also den vollen Funktionsumfang von libspatialite ausschöpfen, so ist ein
> Umstieg von Geopackage auf SpatiaLite unabdingbar.
>
> Für deinen angefragten Anwendungsfall empfehle ich jedoch einen anderen
> Ansatz. Anstatt mit ON INSERT, ON UPDATE Triggern rumzuhantieren, um die
> Fläche eines Polygons zu berechnen, kannst du auch QGIS die Arbeit machen
> lassen. Trage hierzu einfach $area als Vorgabewert für dein Flächenfeld im
> Attribut Formular ein und aktiviere die Option zur Übernahme des Vorgabewertes
> bei Aktualisierung. Dieses Vorgehen ist wesentlich einfacher und
> pflegeleichter.
>
> Schöne Grüße
> Bernd
>
>