wfssearch mit StoredQuery und wfs 2.0.0
Mit dem neuen Tool wfsSearch in der Version 2.14.0 werden über StoredQuery und dem WFS in der Version 2.0.0 keine Suchanfragen über das Masterportal beantwortet.
Der Request wird korrekt abgesetzt und im Browser wird auch die korrekte Antwort zurückgegeben.
Das Masterportal kommt an der Stelle jedoch nicht weiter und gibt an der Konsole folgende Meldung aus:
TypeError: t.addEventListener is not a function
In der Netzwerkanalyse wurde der Request jedoch korrekt gestellt und beantwortet, z.B:
Getestet habe ich auch mit dem Portal des LGV und kam dort zu dem gleichen Ergebnis.
Weiter ist aufgefallen, dass z.B. bei der Gemarkung die Nummer als ID für die Übergabe verwendet werden muß. Gibt es eine Möglichkeit, den Namen in der DropDown - Box zu verwenden und die Nummer an die StoredQuery zu übergeben?
Zu Testzwecken haben wir zuerst den Gemarkungsnamen und dann die Gemarkungsnummer ausgewählt. Das ist natürlich nicht praktikabel. Optimal wäre es, wenn der Gemarkungsname mit
der entsprechenden Nummer in Klammern dahinter ausgewählt wird und die Gemarkung nur mit der Nummer an die Stored Query übergeben wird z.B. gemarkung=0123 .
Die Auswahl der Gemarkungsnummer sollte nicht über options in der config.json deklariert werden, da bei uns im Vorfeld zuerst die Gemeinde/Stadt und dann die zugehörigen Gemarkungen ausgewählt werden sollen, was voraussetzt, dass die Zuordnung der Gemarkungen zu den Gemeinden in der lgv-config/gemarkung.json erfolgen soll.
Comments (17)
-
-
- changed status to open
-
Sehr geehrter Karl-Heins Heinemann,
der Problematik haben wir uns angenommen und werden zeitnah eine Rückmeldung geben. -
Die Nutzung des WFS-Gs dürfte nach den Änderungen durch https://bitbucket.org/geowerkstatt-hamburg/masterportal/pull-requests/3065 ungeeinschränkt funktionieren.
Da die Antwort eines WFS-G strukturell leicht anders geschaffen ist, muss dieser Masterportal-seitig anders geparsed werden. Aus diesem Grund gibt es den Parametergazetteer
mitnamespaces
undmemberSuffix
.Für den Anwendungsfall, dass der Name einer Gemarkung angezeigt, allerdings die Gemarkungsnummer versendet werden soll, kann der Parameter
usesId
genutzt werden. Voraussetzung ist jedoch, dass der Parameteroptions
als leerer String gesetzt wurde, also der Inhalt aus derselectSource
bereitgestellt wird. Dies kann bspw. im Portalmaster
betrachtet werden.Die Werte der Gemeinden / Städte können auch in der
selectSource
auftauchen. Ein vorstellbares Beispiel wäre{ "Hamburg": { "id": "hh", "gemarkungen": [ {...} ] }, "Kiel": { "id": "hh", "gemarkungen": [ {...} ] } }
Allerdings ist dies zum aktuellen Zeitpunkt nicht vereinbar mit der Anforderung, dass bei der Gemarkung die Gemarkungsnummer mit angezeigt wird und an den Dienst gesendet wird.
Durch eine Anpassung der Entwicklung könnte die Anforderung jedoch umgesetzt werden.Für genauere Informationen zu den einzelnen Parametern siehe https://bitbucket.org/geowerkstatt-hamburg/masterportal/src/b211f590120fae5af072a5a680d0990bf73af0af/doc/config.json.de.md?at=fix%2Fwfs-search#markdown-header-portalconfigmenutoolwfssearch
-
-
assigned issue to
-
assigned issue to
-
-
assigned issue to
-
assigned issue to
-
reporter Sehr geehrte Damen und Herren,
prinzipiell funktioniert die Flurstückssuche. Allerdings ist mir aufgefallen, dass die Einstellung des Zoomlevels keine Auswirkungen hat. Der Zoomlevel geht auf die Nummer 5, das Einsetzen folgender Parameter hat keine Auswirkungen auf den Maßstab bei der Suche:
"zoomLevel": 9, "startZoomLevel":9,
In der Ergebnisliste werden bei uns die Attribute nicht mit Werten befüllt, verwende ich die Mustersuche von Hamburg in unserem Testprojekt, dann werden die Werte angezeigt. Die Ergebnisliste ist wie folgt für unser Verbandsgebiet definiert:
}, "resultList": { "gemarkung": "Gemarkung", "flurstuecksnummer": "Flurstücknummer", "flurstuecksflaeche": "Flurstückfläche", "kreisname": "Kreisname", "kreis": "Kreis", "land": "Land", "regierungsbezirk": "Regierungsbezirk", "status": "Status", "geometry": "Geometrie" },
Evt. helfen hier die URL’s aus der Konsole weiter:
Krefeld:
Hamburg:
Mit freundlichen Grüßen
Karl-Hans Heinemann
-
Sehr geehrter Herr Heinemann,
die Parameter
zoomLevel
(deprecated)/startZoomLevel
(neuer Name) gibt es laut Dokumentation nur an derPortalconfig.mapView
– da sie beide erwähnen, rate ich einmal darauf, dass der Zoom Level an der falschen Stelle konfiguriert wurde. Richtig wärezoomLevel
unterPortalconfig.menu.tool.parcelSearch
.Die
resultList
sieht für mich so erstmal richtig aus. Würden Sie mir bitte einmal ihre komplette Konfiguration an das Ticket anhängen? Dann kann ich mir beide Sachen einmal genauer anschauen.Viele Grüße
-
reporter - attached wfssearch.zip
<div class="preview-container wiki-content"><!-- loaded via ajax --></div> <div class="mask"></div> </div>
</div> </form>
-
reporter Anbei das angehängte Testportal. Bei der alten Flurstückssuche (ParcelSearch) wird korrekt auf den Zoomlevel 9 gesprungen, bei der neuen auf den Zoomlevel 5, was vermutlich default ist. Die neue Suche ist ein Test und geht über den Gemarkungsnamen auf die Gemarkungsnummer. Wir sind hier noch dabei den WFS_DOG so anzupassen, dass die Suche direkt über den Namen erfolgen kann.
Mit freundlichen Grüßen
Karl-Hans Heinemann
-
Bezüglich der Feature-Attribute habe ich einen Bug gefunden, der durch den Merge Request https://bitbucket.org/geowerkstatt-hamburg/masterportal/pull-requests/3171 behoben wird.
In der aktuellen Version können die Attribute auch schon angezeigt werden, indem die Reihenfolge der Namespaces angepasst wird. "http://www.adv-online.de/namespaces/adv/dog" (bzw. der Namespace, hinter dem dann die Attribute liegen, falls sich hier etwas ändert) muss in der Namespace-Liste der aktuellen Version noch an erster Stelle stehen. Sobald der Merge Request eingespielt ist, spielt die Reihenfolge ab dem nächsten Release keine Rolle mehr.
Den Zoomlevel schaue ich mir als nächstes an.
-
Der Zoomlevel war in
WfsSearch
im Gegensatz zuParcelSearch
schlicht nicht implementiert. Ich habe das Feature fürWfsSearch
in diesem Merge Request nachgetragen. https://bitbucket.org/geowerkstatt-hamburg/masterportal/pull-requests/3172/issue-655-add-zoom-level-to-wfs-search -
reporter Danke für den Hinweis mit dem Voranstellen des Namespace von adv-online. Mit dieser Konfiguration wird die Ergebnisliste gefüllt.
Wir haben die Suche jetzt soweit mit dem WFS-Dog angepaßt, dass eine Suche über die Drop Down Listen Kreis → Gemeinde → Gemarkungsname → Flur → Flurstück in unserer Testumgebung funktioniert.
Mir ist noch aufgefallen, dass die bisherige Flurstückssuche keine Ergebnisliste anzeigt, sondern direkt die Navigation in der Karte startet. Daher die Frage, ob der wfssearch soweit noch angepaßt werden kann, dass optional eine Suche ohne die Anzeige einer Ergebnisliste möglich ist?
Mit freundlichen Grüßen
Karl-Hans Heinemann
-
Guten Tag,
den Vorschlag von Herrn Heinemann für Suche ohne die Anzeige einer Ergebnisliste finde ich auch gut und würde mich dem anschließen. Eine Möglichkeit, die Ergebnisliste zumindest zur Seite zu bewegen wäre auch hilfreich.
Mit freundlichen Grüßen
Deyana Atanasova
-
Momentan ist das über Konfiguration nicht zu erreichen.
Ich finde aber auch plausibel, dass bei einem Einzelergebnis optional direkt auf dieses gezoomed wird – quasi ein “zoomToSingleResultImmediately“-Flag. Im gleichen Zuge wäre auch eine nichtblockierende (nichtmodale) Liste schön – die ist zwar bei vielen/langen Ergebnissen angenehm groß, aber eben nicht immer. Und im Vordergrund blockierend eine Liste anzeigen, während im Hintergrund schon gezoomed wird, kommt mir auch erstmal merkwürdig vor …
Hier ist die Implementierung nicht mehr trivial und ich denke, dass sie als Feature Request in der IP abgestimmt werden sollte. Ich stelle das Issue von daher einmal von Bug auf Enhancement um.
Viele Grüße
-
- marked as enhancement
-
- removed responsible
- Log in to comment
Nach einigen Tests mit unserem WGS-G können wir aus Bremen das gleiche Fehlverhalten auch bestätigen.