Association-übergreifende Constraints

Sprache INTERLIS
1

A und G seien zwei zusammen assoziierten Klassen. Folgende Bedingungen sind gewünscht:

  1. „alle G’s, die sich auf einem gemeinsamen A beziehen, dürfen nicht überlappen“

  2. „alle G’s, die sich auf einem gemeinsamen A beziehen, müssen einen eindeutigen Code besitzen“

Wie kann man sie implementieren? Ich habe Verschiedenes ausprobiert ohne grosser Erfolg. Beispiel:

INTERLIS 2.4;
MODEL min_test (de) AT "https://localhost/" VERSION "2026-10-06" =
  IMPORTS GeometryCHLV95_V2;
  TOPIC Test =
    CLASS G =
        Code: MANDATORY TEXT*1;
        Geometrie: MANDATORY GeometryCHLV95_V2.MultiSurfaceWithoutArcs;
    END G;
    CLASS A =
    END A;
    ASSOCIATION A_G =
        ARole -- {0..1} A;
        GRole -- {1..*} G;
    END A_G;
    CONSTRAINTS OF A =
!! 1) fails: java.lang.NullPointerException
!!        MANDATORY CONSTRAINT INTERLIS.areAreas(THIS, UNDEFINED, GRole->Geometrie);
    END;
!! 2) compiles but validation never throws (some parts are probably UNDEFINED, so checks are skipped)
    VIEW G_UniqueCodeInA
        JOIN OF G1 ~ G, G2 ~ G;
        WHERE G1->ARole == G2->ARole;
    =
        MANDATORY CONSTRAINT (G1 != G2) => (G1->Code != G2->Code);
    END G_UniqueCodeInA;
  END Test;
END min_test.
2

Ich könnte mir vorstellen, dass areAreas() keine Geometrien vom Typ MULTISURFACE unterstützt (sondern nur SURFACE).

ili2c sollte aber deshalb trotzdem keine NPE werfen…

3

Ich glaub nicht, dass es an dem liegt. MultiSurface in areAreas wurde bereits in anderen Modellen verwendet, z.B. Kant_Koordination_NHG_LV95 (ist zwar ili2.3, sollte aber keine Rolle spielen?).

4

Sollte der Constraint nicht so formuliert werden:

CONSTRAINTS OF A =
    MANDATORY CONSTRAINT
        INTERLIS.areAreas(GRole, UNDEFINED, >>G->Geometrie);
END;

Aber das wird m.E. trotzdem nicht funktionieren, weil areAreas als dritte Attribut eine Surface verlangt. Siehe INTERLIS-Dokumentation `RESTRICTION (SURFACE)`.

Und Join-Views wertet Ilivalidator nicht aus, nur Projektionen.

5

Mit diesem Vorschlag bekomme ich

Name Geometrie is not applicable to CLASS min_test.Test.A.

Dann… Seht ihr Wege, die Bedingungen anders zu modellieren, sodass sie valid und auch vom ilivalidator gecheckt werden?

6

Der Fehler ist nun, dass ilivalidator vergisst, dass es eigentlich „Attribut Geometrie der Klasse G“ sein sollte. Er verliert dieses Wissen und darum dann die Fehlermelung mit „A“. Das ist noch losgelöst vom Multisurface-Problem.

Andere Variante, von der anderen Seite her validieren?

CONSTRAINTS OF G =
    MANDATORY CONSTRAINT
        NOT (DEFINED(ARole))
        OR INTERLIS.areAreas(
            ARole->GRole,
            UNDEFINED,
            >>Geometrie
        );
END;

Aber dann hast du wohl das Problem, dass die areAreas-Funktion x-fach aufgerufen wird. Auch das löst das Multisurface Problem noch nicht.

Ich glaube, man müsste ilivalidator/iox-ili ändern, damit Multisurfaces funktionieren würde. Sonst müsstest du das Modell ändern und „BAG OF SurfaceStructure“ machen.

Frage 2 „eindeutiger Code“:

CONSTRAINTS OF G =
    UNIQUE ARole, Code;
END;

Geht das?

7

VIelen Dank für die Vorschläge, es funktioniert alles bis auf das MultiSurface-Problem.

Es wäre natürlich schön, könnte man areAreas und Verwandten erweitern damit MultiSurface auch erlaubt sind.
Oder alternativ die INSPECTION OF für MULTI’s zu erweitern, um Sichten der Einzelgeometrien zu bekommen (die man dann areAreas-constrainen könnte). Inspektionen funktionieren ja bereits bei BAG/LIST und Linie → Segment, das wäre m.E. eine natürliche Erweiterung.

1 „Gefällt mir“