Funktion INTERLIS.areAreas

Wie werden die Geometrien in der Funktion INTERLIS.areAreas in INTERLIS 2.4 verarbeitet?

In der Klasse A ist definiert:

Art: (a,b,c);
Geometrie: MANDATORY SURFACE WITH (STRAIGHTS, ARCS) VERTEX GeometrieCHLV95_V2.Coord2 WITHOUT OVERLAPS > 0.002;

die Prüfung der Konsistenzbedingung erfolgt in einer View:

View Art_a
  PROJECTION OF A;
  WHERE Art ==# a;
  =
  ALL OF A;
SET CONSTRAINT INTERLIS.areAreas(ALL, UNDEFINED, >> Geometrie);
END Art_a;

Berücksichtigt die Funktion INTERLIS.areAreas, dass die Geometrie der Klasse A Overlaps innerhalb des Toleranzwertes zulässt? Wenn nein, wie wäre der Toleranzwert in der Funktion zu implementieren? Der ilivalidator-1.12.0-0d0c3903d0cd203caac2ae987f9040c2b79ddb42 detektiert Overlapsfehler, obwohl diese innerhalb des Toleranzwertes liegen.

Hast du einen Beispieldatensatz mit Modell?

Vielleicht gleiches Problem wie hier: ILI 2 accept valid AREA overlaps · Issue #366 · claeis/ilivalidator · GitHub

Ah Moment:

Beispiel für Validierungsmodell:

1 „Gefällt mir“

In Zusammenhang mit dem DMAV wurde mir zugetragen, dass die Funktion INTERLIS.areAreas bei den Geodatenmodellen ID 73 und 145 (Nutzungsplanung) angewendet wurde und dort bei der Validierung mit dem ILI-Validator Fehlermeldungen verursacht hat, die nicht nachvollziehbar waren. Ich vermute, dass es (wie beschrieben) darauf zurückzuführen ist, dass INTERLIS 2.4 noch nicht vollständig in allen Tools implementiert ist.

In Zusammenhang mit dem DMAV wurde mir zugetragen, dass die Funktion INTERLIS.areAreas bei den Geodatenmodellen ID 73 und 145 (Nutzungsplanung) angewendet wurde und dort bei der Validierung mit dem ILI-Validator Fehlermeldungen verursacht hat, die nicht nachvollziehbar waren.

Dies ist korrekt und bezieht sich auch auf den von @edigonzales erwähnten Issue #366. Die im März 2023 nach einem Patch Change publizierten Nutzungsplanmodelle sind jedoch weiterhin in INTERLIS 2.3 modelliert, nicht in ILI 2.4. Es handelt sich also nicht um eine Problematik, die mit einem Sprachwechsel verbunden ist.

Bei den erwähnten Modellen liegt ein weiteres INTERLIS.areAreas-Problem beim Ressourcen-Verbrauch: RAM Verbrauch Validierung · Issue #374 · claeis/ilivalidator · GitHub

Wäre wohl nicht schlecht, wenn man sich dieser Thematik (366 und 374) im Rahmen DMAV annimmt. Sonst ist Frustration vorprogrammiert.

Ja, die Funktion INTERLIS.areAreas() sollte den Overlap aus der Wertebereichsdefinition des Attributes berücksichtigen.

Die aktuelle Implementierung im ilivalidator macht das aber nicht richtig (ilivalidator#366)

INTERLIS.areAreas() funktioniert im ilivalidator für INTERLIS 2.3 und 2.4 identisch.

Wir beobachten markant zunehmende Anforderungen im Bereich einer zuverlässigen AREA- und areAreas-Validierung in jüngster Zeit. Ein baldiges Beheben der bestehenden Mängel würde verschiedene Vorhaben unterstützen. Aus meiner Sicht würde es Sinn machen, die Interessenten dieser Issues zu formieren und eine baldige Behebung an die Hand zu nehmen. Was sind Eure Meinungen dazu?

3 „Gefällt mir“

We’re going full circle :slight_smile:

Am Einfachsten wäre es, wenn eine Organisation das Reparieren / Refactoring der AREA-Prüfung beauftragt (als erstes). Anschliessend kann die Performance gesteigert werden (als zweites).

1 „Gefällt mir“

z.K. AREA-Logging: "polygons overlay" not showing coordinates · Issue #376 · claeis/ilivalidator · GitHub