Überarbeitung der Synthetisierungsregeln

changed milestone to %Release 8.0

@OC000013872076 @OC000007434449 @bhinkeldey zur Info

marked this issue as related to #38

changed the description

Das o.g. Konzept erscheint in sich schlüssig. Wichtig ist für eine mögliche Auswertung vor allem eine durchgängige Regelung für alle Daten. Die bisherige Unterscheidung und Aufsplittung der Attribute anhand der Dateninhalte war, denke ich, das Hauptproblem.

Einen Stolperstein sehe ich noch in dem Separator für multiple Werte "||" im Zusammenspiel mit dem Separator für Sub-Attribute "|". Bei einer simplen Stringverarbeitung bzw. Suchfunktion ist eine Unterscheidung nur schwerlich möglich, da der Separator für Sub-Attribute "|" in dem für multiple Werte "||" enthalten ist. Vielleicht wäre alternativ "][" möglich (wobei die Klammern am Anfang und Ende eines Strings wegfielen)

Der beschriebene Weg sollte auf jeden Fall schon einmal umgesetzt werden, er löst aber leider noch nicht das Problem bei der Auswertung innerhalb der Style-Dateien für die WMS-Dienste. Durch fehlende Filtermöglichkeiten im OGC-Schema können weder multiple Werte noch Sub-Attribute oder auch multiple Werte in Sub-Attributen unterschieden werden.

changed the description

Danke für das Feedback. Ich habe den Separator für multiple Werte angepasst, fand allerdings die eckigen Klammern wirken, als hätte man vergessen sie vorher zu öffnen bzw. am Ende zu schließen :)

Haben Sie ein Beispiel für Probleme mit multiplen Sub-Attributen in SE-Styles @OC000013872076 ?

Liegt es an der Darstellung? Oder soll der Separator für multiple Werte "::" (2 Doppelpunkte) sein? Damit hätten wir ja dasselbe Problem bei multiplen Enumerationsattributen (1 Doppelpunkt).

Bei den eckigen Klammern lag's tatsächlich an der Optik, davon abgesehen gibt's natürlich noch jede Menge Alternativen zu ::, wie \\ oder -- - wichtig wäre wohl nur, dass der Separator nicht oder nur höchst unwahrscheinlich in textlichen Festsetzungen (z.B. Attribute texte, refTextInhalt) vorkommt.

Es fällt mir allerdings schwer nachzuvollziehen, inwiefern :: als Separator mit dem : in Subattributen kollidiert. In welchen Fällen würde man, etwa in einem OGC Filterausdruck, den String nach einem einzelnen Doppelpunkt durchsuchen? Um festzustellen, ob ein komplexes Attribut vorliegt? Oder geht es um Auswertungen?

Ich wäre davon ausgegangen, dass die Separatoren hauptsächlich in Clients zur Formatierung genutzt werden, in HTML also z.B. | durch <br> und :: z.B. durch <hr> oder so ersetzt werden.

Mit folgendem Filter könnte man prüfen, ob ein multiples Enumerationsattribut nur einen bestimmten Wert aufweist:

    <ogc:Filter>
      <ogc:And>
        <ogc:PropertyIsEqualTo>
          <ogc:Function name="IsPoint">
            <ogc:PropertyName>xplan:position</ogc:PropertyName>
          </ogc:Function>
          <ogc:Literal>true</ogc:Literal>
        </ogc:PropertyIsEqualTo>
        <ogc:PropertyIsLike wildCard="*" singleChar="." escape="!">
          <ogc:PropertyName>xplan:massnahme</ogc:PropertyName>
          <ogc:Literal>*(1000)</ogc:Literal>
        </ogc:PropertyIsLike>
        <ogc:PropertyIsLike wildCard="*" singleChar="." escape="!">
          <ogc:PropertyName>xplan:gegenstand</ogc:PropertyName>
          <ogc:Literal>*(2000)</ogc:Literal>
        </ogc:PropertyIsLike>
        <ogc:Not>                                                                                                             
          <ogc:PropertyIsLike wildCard="*" singleChar="." escape="!">                                                         
            <ogc:PropertyName>xplan:gegenstand</ogc:PropertyName>                                                                         
            <ogc:Literal>*::*</ogc:Literal>                                                                                  
          </ogc:PropertyIsLike>                                                                                               
        </ogc:Not>
      </ogc:And>
    </ogc:Filter>

Habe gerade 'mal in unserem Fundus an Beispielplänen geschaut:

| kommt bei ein paar Plänen bei der Angabe von Schalldruckpegeln vor, wobei hier manchmal auch ein großes I verwendet wird (die betreffende Kommune verwendet die XPlanBox):

Häufig wird | verwendet als Separator für z.B. xplan:name, xplan:referenzName, xplan:beschreibung,

Ich könnte mit vorstellen, dass | auch als Separator bei xplan:schluessel verwendet wird.

Interessant, das kommt in unseren Daten so glaube ich nicht vor. Spricht auf jeden Fall gegen die Verwendung der Pipe, zumindest alleinstehend. || würde vermutlich gehen.

changed milestone to %Release 8.1

removed milestone %Release 8.1

changed milestone to %Release 9.0

Überarbeitung der Synthetisierungsregeln

Designs

Child items ...

Activity

Consent