jetzt probiere ich auch einmal hier etwas zu posten.
Mich würde interessieren, ob es in Lizmap möglich ist gefilterte (mit der “Lupe” räumlich gefilterte) Daten zu exportieren. Aktuell ist es bei mir so, dass ich Layer filtern kann und anschließend auch nur die gefilterten Einträge (Polygone) angezeigt werden.
Wenn ich dann jedoch den gefilterten Layer als z.B. GeoJSON exportiere, wird bei manchen Layern der komplette Layer exportiert und bei anderen bekomme ich eine Fehlermeldung in den Logs (Admin Fehlerprotokoll):
An HTTP request ended with an error, please check the main error log. HTTP code 400.
The HTTP OGC request to QGIS Server ended with an error. Check logs on QGIS Server. HTTP code 400 on “MAP” = ……….
willkommen bei der deutschsprachigen Lizmap-Anwendergruppe hier auf Discourse.
Ich habe das gerade bei mir probiert. Funktioniert einwandfrei. Export z.Bsp. als GeoJSon, shp oder Geopackage. Es werden nur die gefilterten Elemente exportiert und sie können einwandfrei in QGIS eingelesen werden. Ich bekomme auch keine Fehlermeldungen.
Mit welchen Versionen arbeitest Du? Bei mir ist es QGIS.3.40.10 und Lizmap 3.9.2.
Das einzige, was ich mir noch wünschen würde wäre, dass nur die Attributspalten exportiert werden, die auch in der Datentabelle angezeigt werden. Im Idealfall könnte man diese Einschränkung noch im Plugin durch eine entsprechende Option aktivieren.
Ich scheine das Problem - zumindest teilweise - inzwischen gelöst zu haben. Ich musste die entsprechenden Layer im Lizmap Plugin unter “Attribute table&selection” noch hinzufügen, dann werden auch nur die gefilterten Daten exportiert. Dort kann man dann auch die Attribute festlegen, die exportiert werden sollen (vielleicht hilft dir das bei deinem Export auch weiter Günter).
Leider werden in den exportieren Layern die Werte in der Attributtabelle als “raw data” angezeigt und nicht die “Übersetzungen” aus den verlinkten Datenbanktabellen (obwohl diese sonst im Lizmap korrekt angezeigt werden).
Den Fehler, den ich oben beschrieben habe, muss ich mir noch genauer anschauen. Ich schätze, dass irgendwelche Einträge in dem exportierten Layer / Datenbanktabelle nicht ganz korrekt bzgl. des entsprechenden Datentyps der jeweiligen Spalte aus der Datenbanktabelle sind.
Dann passiert es nämlich, dass in der WFS Anfrage nicht “flaeche.geometrie_surface” sondern “flaeche_geometrie_surface” als Layername aufttauch, aus einem “.” wird ein “_”. Da dieser Layer aber nicht existiert, funktioniert die Anfrage nicht.
Das scheint also ein Problem zu sein, dass ich selbst nur lösen kann, wenn ich keine Layer mit doppelten Geometrien verwende.
Es war doch einfacher das Problem zu lösen als gedacht.
Ich habe einfach den Layer im QGIS Projekt umbenannt, also den Punkt aus dem Namen entfernt. Jetzt funktioniert der gefilterte Export.
Das Problem ist eben der Punkt im Layer-Namen, denn laut “Copilot” gilt:
Lizmap (und QGIS Server) wandeln Layernamen mit Punktnotation (layer.geometry ) in einen flachen Namen um, indem sie den Punkt durch einen Unterstrich ersetzen. Das ist notwendig, weil WFS keine Punktnotation in TYPENAME erlaubt.
Manchmal hilft einem die KI dann doch die Probleme zu verstehen.
Jetzt hat mir die KI noch ein weiteren Hinweis zu dem Export der “rohen” Daten gegeben:
Wenn die Beziehungen zwischen Tabellen bereits in den QGIS-Projekteigenschaften definiert sind und die Attributtabelle sowie Lizmap die übersetzten Werte korrekt anzeigen, dann ist das grundsätzlich ausreichend für die Anzeige im Webclient.
Warum erscheinen die „rohen“ Werte trotzdem im Export?
Das Problem liegt vermutlich nicht an Lizmap selbst, sondern an der Art, wie die WFS-Exportfunktion arbeitet:
WFS exportiert nur die tatsächlichen Felder des Layers, nicht die dynamisch aufgelösten Beziehungen aus den Projektdefinitionen.
Die Beziehungsdefinitionen in den QGIS-Projekteigenschaften sind primär für die Formulare und GUI gedacht – nicht für den Datenexport.
Daher erscheinen im WFS-Export oft nur die Primärschlüssel oder IDs, nicht die „übersetzten“ Namen aus der Child-Tabelle.
Ich habe jetzt in QGIS mit “Joins” gearbeitet, dann werden auch die “übersetzten” Namen in den Attribut-Tabellen exportiert. Ist in meinen Augen aber ein etwas aufwändiger Workaround, wenn vorher schon alles richtig definiert wurde über die Tabellen-Beziehungen (man bekommt über die Joins zudem noch weitere Spalten in die Tabellen, was auch nicht besonders elegant ist ). Daher werde ich das nur vereinzelt machen, je nachdem ob es von User-Seite gefragt wird.
Dann bleibt mir nur noch euch allen ein schönes Wochenende zu wünschen.
Super, auch von mir vielen Dank fürs Teilen der Lösungen.
(bei den Layernamen kann ich auch nur empfehlen keine Umlaute, Sonderzeichen,usw. zu verwenden). Meistens funktioniert es aber bei besonderen Dingen, wie z.Bsp. Bereitstellen von Diensten, dann doch nicht immer)
>> Ich musste die entsprechenden Layer im Lizmap Plugin unter “Attribute table&selection” noch hinzufügen, dann werden auch nur die gefilterten Daten exportiert. Dort kann man dann auch die Attribute festlegen, die exportiert werden sollen (vielleicht hilft dir das bei deinem Export auch weiter Günter).
Ich ging davon aus, dass Du den Export über die “Attributtabelle” meintest. Hier definiere ich auch die darzustellende Attribute, bzw. die zu versteckenden. Für die Anzeige funktioniert das auch.
Aber beim Export werden dann bei mir doch sämtliche (auch die versteckten) Attribute mit ausgegeben.
Übersehe ich eine Option?
@wagner-it Ich bin mir nicht ganz sicher, aber ich meine zum Steuern des Exports muss man in QGIS die Layer-Eigenschaft “Fields” entsprechend vorbereiten. Felder, die nicht exportiert werden sollen, müssten nach meinem Verständnis mit “Do not expose via WFS” markiert werden.
Ich blicke aber auch nicht ganz durch, wie die verschiedenen Einstellungsmöglichkeiten im Lizmap-Plugin und in den Layer-Eigenschaften zusammen spielen. Da werde ich auch immer wieder überrascht.
@MoTo das könnte funktionieren aber dann kann ich diese Eigenschaften auch nicht mehr editieren.
Vereinfacht gesagt gehe ich immer so vor, dass alles was angezeigt werden soll (Info-Fenster) als WMS und alles mit dem man etwas aktiv machen möchte (editieren, suchen, …) als WFS freigegeben wird.
Nun möchte ich bestimmte Felder als Admin editieren aber der User soll sie nicht exportieren können.
Ich halte das mittlerweile für einen Bug. Wenn die Felder in der Attributtabelle nicht angezeigt werden sollen, dann sollten sie dort auch nicht exportiert werden können!
Optional wäre natürlich die Option “für den Export alle Felder erlauben” oder “nur sichtbare Felder beim Export erlauben” ideal.
Es wäre schön, wenn beim Export nicht der eigentliche Datenbankinhalt exportiert wird, sondern bei Wertbeziehungen über Wertetabellen die entsprechenden Werte aus der Wertetabelle.
@wagner-it Hallo Günter ,
wenn du für die entsprechenden Werte in der “Layer Properties” in QGIS als “Joins” Spalten definierst, werden die Werte aus den Wertetabellen auch im Export übernommen.
Finde ich persönlich etwas umständlich, das scheint aber zumindest zu funktionieren.
Die Copilot KI hatte mir damals das hier dazu geschrieben:
Wenn die Beziehungen zwischen Tabellen bereits in den QGIS-Projekteigenschaften definiert sind und die Attributtabelle sowie Lizmap die übersetzten Werte korrekt anzeigen, dann ist das grundsätzlich ausreichend für die Anzeige im Webclient.
Warum erscheinen die „rohen“ Werte trotzdem im Export?
Das Problem liegt vermutlich nicht an Lizmap selbst, sondern an der Art, wie die WFS-Exportfunktion arbeitet:
WFS exportiert nur die tatsächlichen Felder des Layers, nicht die dynamisch aufgelösten Beziehungen aus den Projektdefinitionen.
Die Beziehungsdefinitionen in den QGIS-Projekteigenschaften sind primär für die Formulare und GUI gedacht – nicht für den Datenexport.
Daher erscheinen im WFS-Export oft nur die Primärschlüssel oder IDs, nicht die „übersetzten“ Namen aus der Child-Tabelle.
Lösung: Zusätzliche Joins oder virtuelle Felder
Es hilft, zusätzlich Joins in den Layer-Eigenschaften zu definieren oder virtuelle Felder zu erstellen, wenn gewollt ist, dass die übersetzten Werte auch im Lizmap-Export (z. B. GeoJSON via WFS) erscheinen.
Vorteile von Joins im Layer:
Die Felder aus der Child-Tabelle sind physisch im Layer sichtbar.
Sie werden beim WFS-Export mitgeliefert.
Sie können gezielt im Lizmap-Webclient angezeigt oder gefiltert werden.
Vorteile von virtuellen Feldern:
Du kannst die übersetzten Werte direkt als neue Felder definieren.
Diese Felder sind stabil und unabhängig von der Beziehungskonfiguration.
Danke für die Rückmeldung.
Ich habe auch noch die KI (claude.ai) gefragt. Die hat mir einen DB-View oder die virtuellen Felder empfohlen. Und gleich auch noch den Code für die virtuellen Felder geliefert. Das ist schon erschreckend aber auch sehr zielführend
Für den View spricht, dass man auch gleich die Felder definieren kann, die exportiert werden sollen und nicht standardmäßig alle exportiert werden.
Schönes Wochenende und Grüße nach Luxemburg
Günter
; s. 
). Daher werde ich das nur vereinzelt machen, je nachdem ob es von User-Seite gefragt wird.
Warum erscheinen die „rohen“ Werte trotzdem im Export?
Lösung: Zusätzliche Joins oder virtuelle Felder
Vorteile von Joins im Layer: