Fehler beim Stylen von WFS anhand einer rule/condition

[Deyana Atanasova]

Guten Tag,

folgender Fehler ist bei uns in Bezug auf das Stylen von Features aus einem WFS anhand eines Attributes (rule/condition) aktuell: Wenn ein Styling für eine festgelegte ‘rule’ bestimmt ist, werden letzten Endes im Client alle Features dargestellt: diejenigen, die der Bedingung entsprechen in dem gesetzten Style und die restlichen in einem Standard-Style. Es gibt dabei natürlich die Möglichkeit, diese restlichen Features „unsichtbar“ zu stylen, aber diese sind dann trotzdem als Geometrie präsent und können bei der Info-Abfrage auf einem Feature abgefragt werden, was zu Verwirrung führt. Wir haben in dem Kontext mit dem Parameter „styleMultiGeomOnlyWithRule“ versucht uns zu helfen. Dabei besteht jedoch das Problem, dass er nur bei Multi-Geometrien greift, und nicht bei einfachen Features, was bei uns meistens der Fall ist.

Die Fehlfunktionalität tritt seit der Version 2.16.0 auf. Bis dahin wurden nur die gestylten Features angezeigt.

Für uns ist die Funktionalität sehr wichtig. Können wir auf eine baldige Lösung hoffen?

Herzlichen Dank vorab für Rückmeldungen/Lösung.

Viele Grüße aus Bremen.

[mbgvhh]

Dies ist ein Duplikat von https://bitbucket.org/geowerkstatt-hamburg/masterportal/issues/862/style-parameter-stylemultigeomonlywithrule .

[Dennis Sen]

Moin @Inka Dudek ,

ich habe zu diesem Issue widersprüchliche Informationen in der Codebasis gefunden. Da du “styleMultiGeomOnlyWithRule“ eingeführt hast, kannst du mir vielleicht mehr dazu sagen?

• Problem: Einfache Geometrien eines WFS, zu denen keine Style-Regel passt, haben trotzdem einen Style.
• Hinweis, dass das so falsch ist: In der style.json.md steht:

💡 Hint: If no rule's conditions are met, an empty style object is used, effectively rendering the feature invisible.

Unless this is desired behavior, we suggest providing a rule without conditions as fallback.

• Hinweis, dass das so richtig ist: Im Changelog zur v2.21 steht:

Added style.json parameter "styleMultiGeomOnlyWithRule". If true, **no** fallback for styling of multiGeometries is used. Default is false, means the the previous behavior.

Meine Interpretation: Die erste Stellt sagt “ungestylte Features sind unsichtbar” (und sollten damit imo auch kein Klick-GFI produzieren), die zweite “ungestylte Features bekamen bisher Defaultstyle”. (In letzterem Fall gäbe es eine Lücke dafür, Einfache-Geometrie-Features zu verstecken.)

Mir kommt die erste Lösung plausibler vor. Wenn man Features ohne Fallback-Style unsichtbar lässt, gibt es bei der Konfiguration die Option selbst einen Fallback pro Style zu setzen. (“Unless this is desired behavior, we suggest providing a rule without conditions as fallback.“)

Falls die style.json.md dahingehend veraltet ist und das (vermutlich ältere?) Verhalten nicht wiederhergestellt werden soll, könnte ich auch ein neues Flag “styleSingleGeomOnlyWithRule“ einführen und die Doku in der style.json.md aktualisieren.

Mir persönlich kommt es aber so vor, dass diese styleOnlyWithRule-Flags das unnötig komplex machen. Aber vielleicht kenne ich auch nur den Anwendungsfall für die Defaultstyles nicht. (Vielleicht sollten damit sehr viele Kopien eines Fallback-Styles vermieden werden?)

Kannst du mir sagen, welcher Ansatz da aus eurer Sicht der richtige ist? Oder vielleicht übersehe ich ja auch noch etwas anderes Wichtiges.

[Inka Dudek]

Sven sagt dazu : ich würde es auch so sehen wie Dennis. Also, dass nur Features gezeichnet werden die einer condition entsprechen. Man hat ja dann die Möglichkeit einen Fallback anzugeben. 

Ich denke so war das von Anfang an vorgesehen, da das auch schon in der Version 2.5.0 so in der Doku steht: https://bitbucket.org/geowerkstatt-hamburg/masterportal/src/v2.5.0/doc/style.json.md und im BB-Issue der Hinweis steht, dass das Fehlverhalten erst ab Verison 2.16.0 auftaucht.

styleMultiGeomOnlyWithRule bezieht sich nur auf MultiGeometrien und war eine Sonderlocke für die Echtzeitdaten. Das steht also nicht im Zusammenhang mit deiner Frage.

[Dennis Sen]

870.zip ist eine Testkonfiguration für den Dev-Mode, für die PR-Abnahme.

Ein PR in der masterportalAPI https://bitbucket.org/geowerkstatt-hamburg/masterportalapi/pull-requests/95 läuft jetzt. Nach Release und dann beim nächsten Update im Masterportal sollte es dann wieder wie gewohnt funktionieren.

Die Prüfung könnte aber etwas dauern; ich glaube da kann man gut versehentlich nebenher was anderes kaputt machen …

[Dennis Sen]

Der PR wurde jetzt in die masterportalAPI gemerged.

[Dennis Sen]

Die masterportalAPI wurde released und direkt im Masterportal verbaut. Damit sind die Änderungen im nächsten Release enthalten.

Ich schließe mal übersichtshalber. Sollten sich doch noch Probleme ergeben, gern wieder öffnen.

Viele Grüße