# ilivalidator-Fehler: gleicher TID in externem Katalog und in Datenobjekt

**URL:** <https://interlis.discourse.group/t/ilivalidator-fehler-gleicher-tid-in-externem-katalog-und-in-datenobjekt/383>\
**Category:** INTERLIS Werkzeuge\
**Created:** [16. Mai 2025 um 07:42 UTC](https://interlis.discourse.group/t/ilivalidator-fehler-gleicher-tid-in-externem-katalog-und-in-datenobjekt/383 "2025-05-16T07:42:02Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![peterstaub](https://yyz2.discourse-cdn.com/free1/user_avatar/interlis.discourse.group/peterstaub/32/8_2.png) [@peterstaub](https://interlis.discourse.group/u/peterstaub)\
**Post date:** [16. Mai 2025 um 07:42 UTC](https://interlis.discourse.group/t/ilivalidator-fehler-gleicher-tid-in-externem-katalog-und-in-datenobjekt/383/1 "2025-05-16T07:42:02Z")

</div>

In meinem Anwendungsfall wird ein externer Katalog zu einem Modell geladen und zur Klassierung von Datenobjekten verwendet.  
Im externen Katalog kommt `TID="1001"` vor. In meinen Datenobjekten gibt es ebenfalls ein Objekt mit `TID="1001"`.

Der ilivalidator gibt mir dazu eine Fehlermeldung aus. Sollte das aber nicht „gefressen“ werden? Die korrekte Referenzierung sollte doch über die Modelldefinitionen und die Namensqualifizierungen sichergestellt sein?  
M.E. kann es nie ausgeschlossen werden, dass in einem externen, eingebundenen Datensatz eine gleiche TID vorkommt, wie in meinen Transferdaten… (?)

Oder verstehe ich hier etwas konzeptionell grundfalsch?

---

<div class="post-metadata">

**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:** [16. Mai 2025 um 09:28 UTC](https://interlis.discourse.group/t/ilivalidator-fehler-gleicher-tid-in-externem-katalog-und-in-datenobjekt/383/2 "2025-05-16T09:28:08Z")

</div>

Meine Recherche dazu im Referenzhandbuch hat folgendes ergeben:

> Es ist grundsätzlich möglich, dass ein Transfer Behälter aus verschiedenen Modellen enthält.

(RefHB ILI24, Kap. 4.2.4)

und

> In der Transferart FULL müssen alle %Tid% innerhalb des gesamten Transfers eindeutig sein. In der Transferart INITIAL oder UPDATE müssen die %Tid% global eindeutige OID’s sein.

(Kap. 4.3.7)

Zudem: Wird innerhalb der Transferdatei _keine_ Transferart angegeben, so wird FULL angenommen (Kap. 4.3.7). FULL ist meines Wissens der Normalfall, deshalb gehe ich in deiner Fragestellung ebenfalls davon aus.

Daraus ziehe ich den Schluss, dass die Fehlermeldung gerechtfertigt ist, da RefHB-konform („alle TID im Transfer müssen eindeutig sein“). Wie weit eine Deklaration der Transferart als INITIAL etwas bringen würde, erschliesst sich mir aus obigem Zitat nicht.

Tönt das plausibel?

---

<div class="post-metadata">

**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:** [16. Mai 2025 um 09:33 UTC](https://interlis.discourse.group/t/ilivalidator-fehler-gleicher-tid-in-externem-katalog-und-in-datenobjekt/383/3 "2025-05-16T09:33:12Z")

</div>

Und noch eine Ergänzung:

> [@peterstaub](#):
>
> M.E. kann es nie ausgeschlossen werden, dass in einem externen, eingebundenen Datensatz eine gleiche TID vorkommt, wie in meinen Transferdaten… (?)

Doch, dies kann ausgeschlossen werden, wenn die TID als OID definiert würde, da es per Definition nicht zwei identische OID geben darf.

---

<div class="post-metadata">

**Author:** ![peterstaub](https://yyz2.discourse-cdn.com/free1/user_avatar/interlis.discourse.group/peterstaub/32/8_2.png) [@peterstaub](https://interlis.discourse.group/u/peterstaub)\
**Post date:** [16. Mai 2025 um 11:02 UTC](https://interlis.discourse.group/t/ilivalidator-fehler-gleicher-tid-in-externem-katalog-und-in-datenobjekt/383/4 "2025-05-16T11:02:14Z")

</div>

Danke für die Replik! Ja, mit OID wäre das alles obsolet.

Aber: die externen Kataloge sind ja nicht Teil des Transfers! Es werden nur Referenzen darauf erfasst, und bei der vollständigen Datenvalidierung muss deshalb mittels `ilidata: ...` angegeben werden, in welchem Dataset die Kataloge zu finden sind…

---

<div class="post-metadata">

**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:** [16. Mai 2025 um 11:18 UTC](https://interlis.discourse.group/t/ilivalidator-fehler-gleicher-tid-in-externem-katalog-und-in-datenobjekt/383/5 "2025-05-16T11:18:50Z")

</div>

> [@peterstaub](#):
>
> Aber: die externen Kataloge sind ja nicht Teil des Transfers!

Doch, aus meiner Sicht sind sie Teil des Transfers. Der Transfer ist einfach auf mehrere Transferdateien aufgeteilt. Transferdateien, die mittels `ilidata:...` angegeben werden, werden genauso validiert wie lokal vorliegende Transferdateien.

---

<div class="post-metadata">

**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:** [16. Mai 2025 um 11:21 UTC](https://interlis.discourse.group/t/ilivalidator-fehler-gleicher-tid-in-externem-katalog-und-in-datenobjekt/383/6 "2025-05-16T11:21:05Z")

</div>

Für mich gehören sie auch zum Transfer. Kataloge und dergleichen gibt es ja nicht gemäss Referenzhandbuch, sondern sie sind eine „künstliche“ Erfindung. Sonst müsste man solche Anwendungsfälle explizit im Referenzhandbuch regeln.

---

<div class="post-metadata">

**Author:** ![peterstaub](https://yyz2.discourse-cdn.com/free1/user_avatar/interlis.discourse.group/peterstaub/32/8_2.png) [@peterstaub](https://interlis.discourse.group/u/peterstaub)\
**Post date:** [16. Mai 2025 um 11:26 UTC](https://interlis.discourse.group/t/ilivalidator-fehler-gleicher-tid-in-externem-katalog-und-in-datenobjekt/383/7 "2025-05-16T11:26:01Z")

</div>

OK, kann man akzeptieren. Dann muss klar sein, dass bei der Serialisierung keine gleichlautenden TID wie in eingebundenen Katalogen geschrieben werden. Merci für die Inputs!

---

<div class="post-metadata">

**Author:** ![ThomasMarti](https://yyz2.discourse-cdn.com/free1/user_avatar/interlis.discourse.group/thomasmarti/32/73_2.png) [@ThomasMarti](https://interlis.discourse.group/u/ThomasMarti)\
**Post date:** [20. Mai 2025 um 09:55 UTC](https://interlis.discourse.group/t/ilivalidator-fehler-gleicher-tid-in-externem-katalog-und-in-datenobjekt/383/8 "2025-05-20T09:55:53Z")

</div>

Wir haben das Gleiche Problem in der kommunalen Nutzungsplanung. Der Katalog hat vierstellige IDs und kommt separate daher. Wenn nun der Datenlieferant ebenfalls vierstellige IDs verwendet, gibt es einen Konflikt.

Wir haben nun die Datenlieferanten angewiesen, gültige STANDARDOIDs zu verwenden für das Datenmodell, damit das Problem umgangen werden kann. In der Übergangszeit, bis alle Datensätze umgestellt sind, schalten wir die OID-Prüfung via toml-File aus.

---

<div class="post-metadata">

**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:** [20. Mai 2025 um 10:21 UTC](https://interlis.discourse.group/t/ilivalidator-fehler-gleicher-tid-in-externem-katalog-und-in-datenobjekt/383/9 "2025-05-20T10:21:36Z")

</div>

> [@ThomasMarti](#):
>
> schalten wir die OID-Prüfung via toml-File aus.

Oh, wie geht denn das? Ich dachte, das sei nicht möglich 🤯 (oder hat sich das in den sechs Jahren seit der Erfassung [dieses Issues](https://github.com/claeis/ilivalidator/issues/200) geändert?).

---

<div class="post-metadata">

**Author:** ![ThomasMarti](https://yyz2.discourse-cdn.com/free1/user_avatar/interlis.discourse.group/thomasmarti/32/73_2.png) [@ThomasMarti](https://interlis.discourse.group/u/ThomasMarti)\
**Post date:** [20. Mai 2025 um 10:43 UTC](https://interlis.discourse.group/t/ilivalidator-fehler-gleicher-tid-in-externem-katalog-und-in-datenobjekt/383/10 "2025-05-20T10:43:03Z")

</div>

Den Parameter --config mitgeben

```auto
--config "P:\.......\config_oid_off.toml"

```

Und in der .toml-Datei die Prüfung ausschalten:

```auto
["Laermempfindlichkeitsstufen_BL_V2_LV95.Laermempfindlichkeitsstufen.Planung.Planung_ID"]
type="off"
["Laermempfindlichkeitsstufen_BL_V2_LV95.Laermempfindlichkeitsstufen.Beschluss.Beschluss_ID"]
type="off"
["KommunaleNutzungsplanung_BL_V2_LV95.NutzungsplaeneKommunal.Planung.Planung_ID"]
type="off"
["KommunaleNutzungsplanung_BL_V2_LV95.NutzungsplaeneKommunal.Beschluss.Beschluss_ID"]
type="off"

```

---

<div class="post-metadata">

**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:** [20. Mai 2025 um 10:59 UTC](https://interlis.discourse.group/t/ilivalidator-fehler-gleicher-tid-in-externem-katalog-und-in-datenobjekt/383/11 "2025-05-20T10:59:33Z")

</div>

Ah, merci. Aber das sind keine _echten_ OID, sondern normale Attribute, die den Aufbau einer STANDARDOID haben müssen.

```auto
    CLASS Planung =
      Planung_ID : INTERLIS.STANDARDOID;
      Name : MANDATORY TEXT*254;
      Typ : MANDATORY Planungstyp;
      Nummer : TEXT*10;
	  Gemeinde_ID_BFS : MANDATORY 2761 .. 2895;
      Rechtsstatus : MANDATORY RechtsstatusArt;
    END Planung;

```

Die Validierung des Attributs kann man wie beschrieben deaktivieren. Die OID selber ist davon jedoch nicht betroffen, was aus konzeptioneller Sicht durchaus Sinn macht: Jedes Objekt hat per Definition eine Identität.
