Habe das Problem, dass ich mittels des Detailgeometrie Elements eines Normschachts mehrere „Bauwerke“ mit einer Umzäunung darstellen will.
Es ist aber nur ein SURFACE Element erlaubt (korrekt?), also werden die 2 „Bauwerke“ als Löcher in der äußeren POLYLINE interpretiert, statt die äußere POLYLINE als eigenständiges Bauwerk (der Zaun).
Lösungsvorschläge?
Ja, gemäss Datenmodell ist nur 1 SURFACE-Geometrie erlaubt:
CLASS Abwasserbauwerk (ABSTRACT) EXTENDS VSA_BaseClass =
...
Detailgeometrie: Base_LV95.Surface;
...
END Abwasserbauwerk;
und
Surface = SURFACE WITH (STRAIGHTS, ARCS) VERTEX LKoord WITHOUT OVERLAPS > 0.050;
Dein Problem lässt sich leider nicht lösen; der Geometietyp SURFACE beschreibt eine sogenannte Einzelfläche, die 1 äusseren Rand und keinen, einen oder mehrere innere Ränder haben kann (siehe Referenzhandbuch Kapitel 2.8.13.2).
Ok, dann werde ich die einzelnen Bauwerke jeweils an einen Schacht binden, der „Zaun“ muss dann eben wegfallen oder an ein Sonderbauwerk gehen, den darf ich dann aber nicht als eine umschliessende POLYLINE definieren, sondern eher als eine dünne Schlaufe mit kleiner Lücke, sonst sieht das in der Schraffierung wieder blöd aus.
Du könntest eine Modellerweiterung schreiben (INTERLIS), die an das Abwasserbauwerk anschliesst.
Z.B. eine Klasse „Mobiliar“, mit Attribut „AbwasserbauwerkRef“ und weiteren Attributen wie „Art“, „Typ“, „Höhe“, „Material“, … etc
Falls du das Modell dann exportiert oder abgibst, musst du dann aber die Erweiterung mit abgeben. Oder in ein Repository veröffentlichen.
Das wäre tatsächlich eine Möglichkeit, die mir nicht offensichtlich war. Danke!
Da ich den VSA-DSS Export ohnehin direkt nach ISYBAU wandle, ohne dass dieser das Haus verlässt, müsste ich prüfen, wie ich das dann in ISYBAU abbilde. VSA-DSS bzw. TEKSI wastewater ist hier nur temporärer Notbehelf, bis ich ein ISYBAU INTERLIS Modell und ein darauf basierendes TEKSI Datenmodell entwickelt habe.
Danach sollte ich „nativ“ ISYBAU in der INTERLIS Variante importieren & exportieren können (das XML in der DATASECTION sollte dann gemäß dem veröffentlichten ISYBAU XML Schema validieren).
(das XML in der DATASECTION sollte dann gemäß dem veröffentlichten ISYBAU XML Schema validieren)
Wenn du ein ISYBAU INTERLIS-Modell erstellt hast (entspricht vorbildlich dem Modellbasierten Ansatz 
), so würde ich nach einem Umbau von VSA-DSS nach ISYBAU unbedingt die bereits vorhandenen Tools aus der ili2db-Reihe verwenden, um das Transferfile (XML) herzuleiten. Das erhältst du ja gratis dazu! Manuell oder semi-automatisch an der XML-Datei herumzuwirken ist fehleranfällig und nicht nachhaltig.
Aber vielleicht hast du das ja gar nicht vor und ich habe den Use Case nicht verstanden.
Ja, klar will ich die INTERLIS toolchain weiterhin verwenden! Deswegen auch ISYBAU als INTERLIS Modell. Ich bin faul.
Ich fange einfach ein Isybau-2006.ili an und jage es solange durch ili2c, bis die XML Schema Ausgabe dem veröffentlichten ISYBAU XML Schema entspricht.
Nur muss ich das wohl weitgehend selber machen, da die LLMs mich im Stich gelassen haben: GPT und INTERLIS: Erste Erfahrungen mit ChatGPT und GitHub Copilot - #4 von fxd
Besser als die LLMs sind also offenbar noch immer die Menschen mit ihren Erfahrungen. Wer weiss, wenn du deine Ideen in einem öffentlichen Git-Repo publizierst und über deine Erfahrungen berichtest, so musst du vielleicht nicht alles alleine machen, weil andere diese Ideen mittragen könnten …
Ich hatte schon in FOSSGIS Liste angefragt, aber bislang keine Rückmeldung erhalten: