Masterportal und Elasticsearch : Verwendung der "Match" - Query mit dem Operator "And"

[Karl-Hans Heinemann]

Eine einfache "match" Query für ElasticSearch ist im Masterportal in der config.json ist wie folgt definiert:

                ... 
                "payload": 
                 {
                      "sort": [
                        { 
                          "_score": "desc"
                        }
                      ],
                      "query": {
                        "match": {
                          "searchfield": {
                              "query":"",
                              "operator":"and"
                          }
                        }
                      },
                      "size": 100
                 },
                 "searchStringAttribute": "searchfield",
                ...

Dabei ist aufgefallen, dass die Abfrage nicht wie abgebildet für ElasticSearch übernommen wird, denn die folgenden Teile der Abfrage werden ignoriert:

  "query":"",
  "operator":"and"

Das Masterportal übernimmt bei einer Volltextsuche die Abfrage für ElasticSearch beispielsweise wie folgt:

{"sort":[{"_score":"desc"}],"query":{"match":{"searchfield":"kref rhein 123"}},"size":100}

Dabei ist es eigentlich wichtig, dass der Operator "and" in der Query verwendet wird, und nicht der Operator "or", da dieser
zu viele Ergebnisse zurückliefert. Das Settings für den Index ist in ElasticSearch so aufgebaut, dass der Tokenizer
die eingegebenen Teilstrings trennt und mit dem Operator "and" nur die Ergebnisse zurückgibt, wo alle Teilstrings in dem
Suchfeld vorkommen. Bei dem "OR" - Operator braucht nur ein Teilstring im Suchfeld vorkommen und es werden alle Datensätze zurückgeliefert, bei der diese Bedingung erfüllt ist, wobei das erste Ergebnis natürlich auch stimmt, weil die zurückgelieferte Suchliste über den Score sortiert ist.

Eine adäquate Abfrage, die z.B. im Masterportal in der Volltextsuche eingegeben werden kann, sieht in ElasticSearch
in der Adresssuche beispielsweise wie folgt aus:

‌

POST test_3/_search
{
  "sort": [
    {
      "_score": "desc"
    }
  ],
  "query": {
    "match": {
      "searchfield": {
        "query": "kref rhein 123",
        "operator": "and"
      }
    }
  },
  "size": 100
}

Mit dem Operator "and" wird hier beispielsweise nur ein Ergebnis : "Rheinbabenstraße 123, Krefeld (47809)" zurückgeliefert. Der Operator "OR" liefert zwar auch dieses Ergebnis an erster Stelle zurück, liefert aber noch viele weitere Ergebnisse, z.B. aus anderen Kommunen entsprechend der definierten "size": 100 zurück, was so nicht gewünscht ist und auch Zeit und Performance kostet.

Derzeit sehe ich keine Möglichkeit, die "match" Abfrage auf den Operator "and" zu erweitern. Handelt es sich hierbei um einen Bug? Gibt es eine Möglichkeit das Problem zu lösen oder zu umgehen?

[Dennis Sen]

Hallo Herr Heinemann,

es handelt sich hier meiner Einsicht nach um ein Konfigurationsproblem. Als Wert für searchStringAttribute sollte "query" eingetragen werden, da hiermit festgelegt wird, welcher Teil des konfigurierten Objektbaumes überschrieben wird.

Hier gibt es allerdings noch ein zusätzliches Problem: query tritt auf dem “Weg durch das Objekt” bis zum Suchstring zwei mal auf. Das Masterportal entscheidet sich dann leider bislang dafür, den ersten aufgefundenen Key "query" durch den Suchstring zu ersetzen. Aktuell würde also {"sort":[{"_score":"desc"}],"query":"kref rhein 123","size":100} produziert werden.

Ich habe dies im MR https://bitbucket.org/geowerkstatt-hamburg/masterportal/pull-requests/3189/issue-666-fix-information-loss-on-nested behoben. Ab der nächsten Version nach Merge sollte es dann reichen, "searchStringAttribute": "query” einzutragen.

Viele Grüße

[Karl-Hans Heinemann]

Hallo Herr Sen,

ich habe mir ihren Branch mal heruntergeladen, installiert und getestet. Dabei ist aufgefallen, dass die Abfrage eine “Parsing Exception” auslöst. Die Abfrage wird wohl korrekt aufgebaut, allerdings wir vor den Anführungszeichen ein Backslash eingebaut, was zu diesem Problem führt. Entfernt man die Backslash Zeichen und fügt die Abfrage z.B. in Kibana ein, so wird diese korrekt ausgeführt.

"{\"sort\":[{\"_score\":\"desc\"}],\"query\":{\"match\":{\"searchfield\":\"kref rhein 123\"}},\"size\":20}"

Der “AND” Operator wird leider nach wie vor nicht verwendet, obwohl er im Payload definiert wurde.

Mit freundlichen Grüßen

Karl-Hans Heinemann

[Dennis Sen]

Hallo Herr Heinemann,

haben Sie zum Testen auf dem Branch "searchStringAttribute": "query” konfiguriert? Das sollte verhindern, dass der operator als Kindelement von searchfield überschrieben wird.

Das mit den Backslahes bekomme ich leider nicht nachgestellt – würden Sie mir hier bitte einmal die komplette Konfiguration (also den Portal-Ordner) in das Ticket laden? Dann kann ich einmal dagegen debuggen, um mehr herauszufinden.

Viele Grüße

[Karl-Hans Heinemann]

Hallo Herr Sen,

verwendet hatte ich gestern den Branch BG-1828_elasticSearch . Anbei die komplette Konfiguration von Elastic Search, die mit den Standardversionen funktioniert:

        "elasticSearch":
        {
             "minChars": 3,
             "maxFeatures": 1,
             "serviceId": "elastic",
             "type": "POST",
             "payload": 
             {
                  "sort": [
                    { 
                      "_score": "desc"
                    }
                  ],
                  "query": {
                    "match": {
                      "searchfield": {
                          "query":"",
                          "operator":"and"
                      }
                    }
                  },
                  "size": 20
             },
             "searchStringAttribute": "searchfield",
             "responseEntryPath": "hits.hits",
             "hitMap": 
             {
                 "name": "_source.searchfield",
                 "id": "_source.id",
                 "source": "_source",
                 "coordinate": "_source.geometry.coordinates",
                 "geometryType": "_source.geometry.type",
                 "type":"_source.source"
             },
             "hitType": "Adresssuche",
             "hitGlyphicon": "glyphicon-star-empty"
             }
    },

Ersetze ich “searchStringAttribute”: “searchfield” durch “searchStringAttribute”:”query”, dann wird die im Masterportal definierte Query komplett überschrieben und es steht z.B. in der Anfrage des Browsers nur noch folgendes:

‌

{"payload":{"sort":[{"_score":"desc"}],"query":"kref rhein 123","size":20},"headers":{"Content-Type":"application/json;charset=UTF-8"},"signal":{}}

‌

die Backslashs kommen m.E. zustande, weil in …/src/api/elasticsearch.js in Zeile 86

payload: JSON.stringify(payload),

Das ist m.E. für POST nicht notwendig. Die Abfrage wird dennoch nicht ausgeführt.

Mit freundlichen Grüßen

Karl-Hans Heinemann

‌

[Dennis Sen]

Hallo Herr Heinemann,

das ist nicht der Branch, auf dem ich aktiv war. issue-666-elastic-border-case heißt der, auf dem "searchStringAttribute": "query” funktionieren sollte.

Den Rest schaue ich mir noch an, das Problem mit den Backslashes wird von meinen bisherigen Änderungen unberührt sein.

Viele Grüße

[Karl-Hans Heinemann]

Hallo Herr Sen,

danke für ihre Antwort. Mit dem von ihnen benannten Branch wird der “and” Operator berücksichtigt. Allerdings läßt sich der Request nicht absetzen. Die Requests in den Versionen unterscheiden sich wie folgt:

Nicht funktionierende Entwicklerversion 2.18.0, dabei ist es unerheblich, ob payload direkt oder mit JSON.stringify(payload) ausgegeben wird.

{"payload":{"sort":[{"_score":"desc"}],"query":{"match":{"searchfield":{"query":"kref rhein 123","operator":"and"}}},"size":20},"headers":{"Content-Type":"application/json;charset=UTF-8","signal":{}}

Hier der response von ElasticSearch aus ihrer Entwicklung:

{"error":{"root_cause":[{"type":"parsing_exception","reason":"Unknown key for a START_OBJECT in [payload].","line":1,"col":12}],"type":"parsing_exception","reason":"Unknown key for a START_OBJECT in [payload].","line":1,"col":12},"status":400}

Request für funktionierende Standardversion:

{"sort":[{"_score":"desc"}],"query":{"match":{"searchfield":"kref rhein 123"}},"size":20}

Mit freundlichen Grüßen

Karl-Hans Heinemann

[Dennis Sen]

Hallo Herr Heinemann,

hätten Sie bitte einmal die Konfiguration für den Service "elastic" für mich? (Aus der rest-services-internet.json) Dann kann ich das direkt gegen den Dienst bearbeiten, bis es geht.

Viele Grüße

[Karl-Hans Heinemann]

Hallo Herr Sen,

derzeit haben wir ElasticSearch noch nicht in Produktion, ein Zugriff über das Internet ist noch nicht möglich. Die Konfiguration sieht wie folgt aus:

‌

{
    "id": "elastic",
    "name": "Elastic Test",
    "url": "https://servername/index/_search",
    "typ": "Search"
  },

Ich habe den Request, den ihre Entwicklerversion erzeugt auch direkt mit Kibana über POST an ElasticSearch abgesetzt, da bekomme ich die gleiche Fehlermeldung wie aus dem Masterportal heraus.

Mit freundlichen Grüßen

Karl-Hans Heinemann

[Dennis Sen]

Hallo Herr Heinemann,

ich habe mich einmal des Frankfurter ElasticSearch-Servers bedient und dort den Fehler nachstellen können. Ein PullRequest zur Behebung des Bugs ist auf dem Weg: https://bitbucket.org/geowerkstatt-hamburg/masterportal/pull-requests/3205

Viele Grüße

[Karl-Hans Heinemann]

Hallo Herr Sen,

vielen Dank für die Umsetzung. In diesem Zusammenhang ist mir eingefallen, dass die Stadt Frankfurt die Erweiterung zur Icon Anzeige der Klassifizierungen in der Trefferliste nutzt. Damit ist die Anzeige unterschiedlicher Symbole und Texte entsprechend angezeigter Klassifizierung in der Suchliste möglich, z.B. wenn als Treffer Poi’s unterschiedlicher Kategorien, Strassen, Adressen oder Flurstücke angezeigt werden.

Wir haben dies bei uns in der Testumgebung auch eingebaut und getestet. Es funktioniert ausgezeichnet. Daher meine Bitte, diese Erweiterung in den Core des Masterportals einzuarbeiten.

Die entsprechende Dokumentation hat die Stadt Frankfurt dem LGV zur Verfügung gestellt und ist unter folgender URL zu finden:

https://kundenportal.dataport.de/websites/0502/Freigegebene Dokumente/Configuration Dateien/Elasticsearch/Dokumentation_Geoportal_Elasticsearch.pdf

Mit freundlichen Grüßen

Karl-Hans Heinemann

[Dennis Sen]

Hallo Herr Heinemann,

der Branch ist jetzt in den Dev-Stand gemerged. Ich nehme an, dass der Bug damit in der nächsten Version behoben ist, und schließe das Ticket von daher. Sollte doch noch etwas nicht funktionieren, können Sie das Issue gern wieder öffnen.

Bzgl. der Erweiterung muss ich leider an das Produktmanagement verweisen. Ich arbeite zunächst nur die Bug-Issues ab.

Viele Grüße und schönes Wochenende

[Karl-Hans Heinemann]

Hallo Herr Sen,

danke für die Info. Ebenso ein schönes Wochenende.

Mit freundlichen Grüßen

Karl-Hans Heinemann