# Association-übergreifende Constraints **URL:** \ **Category:** Sprache INTERLIS\ **Tags:** ili24\ **Created:** [6. Oktober 2026 um 21:01 UTC](https://interlis.discourse.group/t/association-uebergreifende-constraints/505 "2026-10-06T21:01:32Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![qwenger](https://avatars.discourse-cdn.com/v4/letter/q/839c29/32.png) [@qwenger](https://interlis.discourse.group/u/qwenger)\ **Post date:** [6. Oktober 2026 um 21:01 UTC](https://interlis.discourse.group/t/association-uebergreifende-constraints/505/1 "2026-10-06T21:01:32Z")
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: ```auto 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. ``` ---
**Author:** ![beistehen](https://yyz2.discourse-cdn.com/free1/user_avatar/interlis.discourse.group/beistehen/32/7_2.png) [@beistehen](https://interlis.discourse.group/u/beistehen)\ **Post date:** [7. Oktober 2026 um 06:21 UTC](https://interlis.discourse.group/t/association-uebergreifende-constraints/505/2 "2026-10-07T06:21:49Z")
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… ---
**Author:** ![qwenger](https://avatars.discourse-cdn.com/v4/letter/q/839c29/32.png) [@qwenger](https://interlis.discourse.group/u/qwenger)\ **Post date:** [7. Oktober 2026 um 07:48 UTC](https://interlis.discourse.group/t/association-uebergreifende-constraints/505/3 "2026-10-07T07:48:59Z")
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?). ---
**Author:** ![edigonzales](https://yyz2.discourse-cdn.com/free1/user_avatar/interlis.discourse.group/edigonzales/32/4_2.png) [@edigonzales](https://interlis.discourse.group/u/edigonzales)\ **Post date:** [7. Oktober 2026 um 08:20 UTC](https://interlis.discourse.group/t/association-uebergreifende-constraints/505/4 "2026-10-07T08:20:51Z")
Sollte der Constraint nicht so formuliert werden: ```auto 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](https://docs.interlis.guru/refhb/main/#3_14_C1) `RESTRICTION (SURFACE)`. Und Join-Views wertet Ilivalidator nicht aus, nur Projektionen. ---
**Author:** ![qwenger](https://avatars.discourse-cdn.com/v4/letter/q/839c29/32.png) [@qwenger](https://interlis.discourse.group/u/qwenger)\ **Post date:** [7. Oktober 2026 um 08:45 UTC](https://interlis.discourse.group/t/association-uebergreifende-constraints/505/5 "2026-10-07T08:45:37Z")
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? ---
**Author:** ![edigonzales](https://yyz2.discourse-cdn.com/free1/user_avatar/interlis.discourse.group/edigonzales/32/4_2.png) [@edigonzales](https://interlis.discourse.group/u/edigonzales)\ **Post date:** [7. Oktober 2026 um 09:10 UTC](https://interlis.discourse.group/t/association-uebergreifende-constraints/505/6 "2026-10-07T09:10:55Z")
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? ```auto 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“: ```auto CONSTRAINTS OF G = UNIQUE ARole, Code; END; ``` Geht das? ---
**Author:** ![qwenger](https://avatars.discourse-cdn.com/v4/letter/q/839c29/32.png) [@qwenger](https://interlis.discourse.group/u/qwenger)\ **Post date:** [8. Oktober 2026 um 13:36 UTC](https://interlis.discourse.group/t/association-uebergreifende-constraints/505/7 "2026-10-08T13:36:06Z")
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.