keine Infofenster-Anzeige von gfi für QGIS-Server-WMS

Issue #871 resolved
Former user created an issue

Im Gegensatz zu ESRI-Server-WMS-gfi, wie z. B.

<?xml version="1.0" encoding="UTF-8"?>
<FeatureInfoResponse xmlns:esri_wms="http://www.esri.com/wms" xmlns="http://www.esri.com/wms">
<FIELDS OBJECTID="144" NAME="Moore bei Buxtehude" BL="NI" BIOGEO="atlantisch" FLAECHE="1289" LINK="https://www.bfn.de/natura-2000-gebiet/moore-bei-buxtehude" SITECODE="DE2524401" WRRL="ja" SHAPE="Polygon" MARIN_AREA="0"></FIELDS>
</FeatureInfoResponse>

oder deegree-WMS-gfi, wie z. B.

<?xml version='1.0' encoding='UTF-8'?>
<FeatureCollection xmlns="http://www.opengis.net/wfs" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:gml="http://www.opengis.net/gml" xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd http://www.deegree.org/app https://geodienste.hamburg.de/HH_WMS_Verwaltungsgrenzen?request=GetFeatureInfoSchema&amp;layers=bezirke">
<gml:boundedBy>
<gml:Box srsName="EPSG:25832">
<gml:coordinates decimal="." cs="," ts=" ">548365.316,5932903.076 564705.222,5942789.750</gml:coordinates>
</gml:Box>
</gml:boundedBy>
<gml:featureMember>
<app:bezirke xmlns:app="http://www.deegree.org/app" fid="APP_BEZIRKE_968">
<app:bezirk>2</app:bezirk>
<app:bezirk_name>Altona</app:bezirk_name>
</app:bezirke>
</gml:featureMember>
</FeatureCollection>

wird der gfi-Response des QGIS-Servers, z. B.

<?xml version="1.0" encoding="UTF-8"?>
<GetFeatureInfoResponse>
 <Layer name="mv_nn_lsg_f">
  <Feature id="118">
   <Attribute name="Landeskennziffer" value="LSG_125"/>
   <Attribute name="Name" value="Wesselstorf"/>
   <BoundingBox CRS="EPSG:5650" maxx="33340023.7" miny="5980940.3" maxy="5989333.2" minx="33325365.3"/>
  </Feature>
 </Layer>
</GetFeatureInfoResponse>

nicht im Infofenster angezeigt, sondern ungestylt in einem separaten Tab geöffnet. Woran könnte das liegen?

Mit bestem Dank im Voraus, viele Grüße, Inka Tauber

Comments (22)

  1. mbgvhh

    Können sie bitte Screenshots zufügen und die entsprechenden Konfigurationsobjekte des Layers aus config.json und services.json? Könnte evtl. am Parameter “infoFormat” liegen…

  2. Inka Tauber

    Screenshots (Browserfenster vor Info-Klick, Browserfenster nach Info-Klick):

    Layerdefinition in der services-internet.json:

      {
        "id": "149",
        "name": "Landschaftsschutzgebiete in Mecklenburg-Vorpommern",
        "url": "http://10.20.16.93:81/dienste/schutzgebiete",
        "typ": "WMS",
        "layers": "mv_nn_lsg_f",
        "format": "image/png",
        "version": "1.3.0",
        "singleTile": false,
        "transparent": true,
        "transparency": 0,
        "urlIsVisible": true,
        "tilesize": 512,
        "gutter": 0,
        "minScale": "0",
        "maxScale": "2500000",
        "gfiAttributes": "showAll",
        "gfiTheme": "default",
        "layerAttribution": "nicht vorhanden",
        "legendURL": "",
        "cache": false,
        "featureCount": 5,
        "datasets": [
          {
            "md_id": "3DBF1F46-4EB8-4A14-9828-E97208A3F220",
            "csw_url": "https://metaver.de/csw",
            "show_doc_url": "https://metaver.de/trefferanzeige?docuuid=",
            "rs_id": "UDK_Mecklenburg-Vorpommern/3DBF1F46-4EB8-4A14-9828-E97208A3F220",
            "md_name": "Landschaftsschutzgebiete",
            "bbox": "606676.059410434,5885697.26300464,848743.368321651,6073178.57691151",
            "kategorie_opendata": [
              "Sonstiges"
            ],
            "kategorie_inspire": [
              "Schutzgebiete"
            ],
            "kategorie_organisation": "Landesamt für Umwelt, Naturschutz und Geologie Mecklenburg-Vorpommern (LUNG)"
          }
        ],
        "notSupportedFor3D": false
      },
    

    Layereinbindung in der config.json:

    {
      "id": "149",
      "name": "Landschaftsschutzgebiete",
      "visibility": false
    },
    

    Das Infoformat ist nicht explizit angegeben, insofern müsste es der default xml sein. XML wird auch abgerufen, allerdings eben nicht im Attributinfofenster angezeigt, sondern in einem neuen Tab.

    Danke und viele Grüße,

    Inka Tauber

  3. mbgvhh

    Mmh. Die configs sehen ok aus! Auf dir URL kann ich leider nicht zugreifen.

    Kann es sein, dass der Mimetype der QGIS-Server-Antwort trotz abgefragtem xml “text/html” ist?

  4. Inka Tauber

    Seiteninfo und Netzwerkanalyse im FF zeigen text/xml bzw. xml an:

    Kann es sein, dass das Problem so ähnlich gelagert ist wie jenes in https://bitbucket.org/geowerkstatt-hamburg/masterportal/issues/560/kein-gfi-result-f-r-layer-mit-infoformat, dass das “GetFeatureInfoResponse” des QGIS-Servers im Gegensatz z. B. zum “FeatureInfoResponse” des deegree nicht als gültig erkannt wird?

    Nachtrag:

    Wir sind noch nicht online, so dass ich leider keinen öffentlich verfügbaren Link posten kann. Bezüglich der Version hatte ich mich bei der Erstellung des Issues leider vertan. Es ist natürlich 2.29.0.

  5. Inka Tauber

    Nach Änderung von infoFormat auf "application/vnd.ogc.gml" wird im Edge und im FF jeweils ein Dateidownload angeboten:

    Ich weiß nicht, ob das für das Problem relevant ist - für WFS funktioniert die Anzeige der Attribute einwandfrei:

  6. Moritz Plachta

    Hallo,

    wir hatten das Problem in Remscheid auch. Es lag an der Konfiguration des Web-Servers, der den WMS/ WFS nur unter http ausgeliefert hat. Nach der Umstellung auf https hat das Masterportal bei dem gleichen Dienst keinen neuen Tab mehr geöffnet, sondern das GetFeatureInfo korrekt angezeigt.

  7. Inka Tauber

    Hallo Herr Plachta,

    das ist ein interessanter Ansatz, vielen Dank für die Information. Da wir vorerst intern testen, liefert unser Server nur http aus. Das Seltsame ist, dass das Problem nur beim WMS, nicht aber beim WFS auftritt. Wir werden das aber im Auge behalten.

  8. Dennis Sen

    Hallo Frau @Inka Tauber ,

    ich habe das einmal untersucht und schätze das Verhalten des Masterportals hier als einen Bug ein. Verhindert werden soll in einem HTTPS-Deployment eine HTTP-Seite aufzurufen, da Browser in diesem Fall aus Sicherheitsgründen einen Fehler werfen. Die GFI in dem Szenario anzuzeigen ginge nur über ein neues Fenster.

    Ich nehme an, dass Ihr interner Test auch unter HTTP läuft, und von dort aus ist es wieder möglich das GFI direkt im Portal anzuzeigen.

    Hierzu läuft nun folgender Pull Request:

    https://bitbucket.org/geowerkstatt-hamburg/masterportal/pull-requests/4005

    Mal schauen, ob ich bei meiner Überlegung vielleicht ein Sicherheitsbedenken übersehen habe. Wenn nicht, sollte Ihre Konfiguration in der nächsten Version nach Merge lauffähig sein.

    Viele Grüße

  9. Dennis Sen

    Der MR ist nun gemerged und ab der nächsten Version nach v2.30.0 sollte es nun funktionieren wie erwartet.

  10. Inka Tauber

    Hallo Herr Sen,

    vielen Dank für die Bearbeitung des Problems. Ich habe es mit Version 2.31.0 getestet. Der Effekt ist nun, dass GFI gar nicht angezeigt wird (keine Reaktion nach Klick auf ein WMS-Objekt in der Karte, die Netzwerkanalyse zeigt aber Status 200 für den GFI-Response an). Ein bereits geöffnetes Attributinfo-Fenster (vom WFS, für diesen funktioniert es ja) wird geschlossen.

    Viele Grüße, Inka Tauber

  11. Kristian Delov

    Hallo zusammen,

    in Frankfurt haben wir ebenfalls das Problem, nachdem wir jetzt erstmals einen QGIS-Server WMS integrieren wollen.

    In Version 2.20.0 (oder auch 2.31.1) funktioniert die GFI zwar mit dem infoFormat: “application/json”, wird allerdings alphabetisch sortiert, was vom Diensteanbieter nicht erwünscht ist. Mit infoFormat: “text/xml“ tritt das von Frau Tauber geschilderte Problem auf: keine GFI Anzeige, in der Netzwerkanalyse wird aber sauber in xml-Struktur geantwortet.

    Achso, das Verhalten tritt bei uns mit HTTPS Diensten auf (das Verhalten GFI öffnet im neuen Tab hatten wir mit http ebenfalls - mit https nicht mehr)

    Edit: https://geoportal.frankfurt.de/v2.31.1/test

    VG

    Kristian

  12. Dennis Sen

    Hallo zusammen,

    vielen Dank für die Beispielkonfiguration aus Frankfurt. Damit konnte ich das Problem sehr gut untersuchen.

    “application/json”, wird allerdings alphabetisch sortiert, was vom Diensteanbieter nicht erwünscht ist

    Aufruf application/json

    Ich habe hier einmal einen Beispielaufruf verlinkt. Soweit ich sehe, sind die Felder bereits backendseitig alphabetisch sortiert. Das Masterportal übernimmt diese Reihenfolge nur. Leider weiß ich nicht, wie man das in QGIS anders konfiguriert, aber mit diesem Beispiellink könnten Sie sich an den Diensteanbieter wenden.

    Der Effekt ist nun, dass GFI gar nicht angezeigt wird

    Hierzu ist mir jetzt aufgefallen, dass im Masterportal kein Interpreter für das von QGIS gelieferte Antwortformat existiert.

    Das Problem bei WMS-GFI-Antworten ist, dass sie im Standard eher unterspezifiziert sind. In der WMS-Spezifikation steht unter “7.4.4 GetFeatureInfo response“ schlicht: “The nature of the response is at the discretion of the service provider“. Das Format, das QGIS zurückgibt, kann das Masterportal bislang nicht lesen, und erkennt deshalb “0” Features.

    Ich habe im PR https://bitbucket.org/geowerkstatt-hamburg/masterportal/pull-requests/4056/issue-871-add-qgis-wms-gfi-response einmal einen Interpreter für QGIS hinzugefügt. Der basiert aber nur darauf, dass der äußere Tag “GetFeatureInfoResponse“ heißt. Ein besseres Kriterium scheint es da an der QGIS-Antwort nicht zu geben.

  13. Inka Tauber

    Hallo Herr Sen,

    vielen Dank für die nochmalige Analyse und für die Korrektur. Der Test mit den Dateien aus 871.zip funktioniert bei uns nicht, da die masterportal.js und die masterportal.css aus den build-Unterverzeichnissen nicht enthalten sind. Könnten Sie die beiden Dateien noch zur Verfügung stellen? Die Ablage in der Verzeichnisstruktur können wir uns entsprechend anpassen.

    VG Inka

  14. Dennis Sen

    Hallo Frau Tauber,

    ah, ich habe vergessen zu der Datei hinzuzuschreiben, wofür sie ist. Die ist für das Review des PRs seitens LGV, und die Kolleginnen und Kollegen dort spielen die Konfiguration wie hier hochgeladen im Entwicklungsmodus durch, um zu testen.

    Die Dateien sind einfach nur die von https://geoportal.frankfurt.de/v2.31.1/test/#, und ich glaube, Sie brauchen die gar nicht. In der nächsten Masterportalversion sollte Ihre Konfiguration dann aber auch laufen. (Ich nehme mal an, dass QGIS das immer gleich handhabt.)

    Viele Grüße

  15. Dennis Sen

    Super. :)

    Der PR ist jetzt auch gemerged, und ab der nächsten Version >2.31.1 sollte dann auch diese zweite Ebene des Problems gelöst sein.

  16. Dennis Sen

    Mit der Veröffentlichung der v2.32.0 heute sollte das Problem gelöst sein. Da es schon positive Rückmeldung gab, schließe ich einmal optimistisch. Sollte es doch noch Probleme geben, gern wieder öffnen.

    Viele Grüße

  17. Log in to comment