Das Modul wird aktiviert, indem in der Steuerdatei arc_egmo.ste über den Eintrag EXTERNE_DATEN im Block STEUERDATEIEN auf eine Datei mit Informationen zu den externen Daten verwiesen wird. Der Name dieser Informationsdatei für die externen Daten ist frei wählbar und wird über den Eintrag EXTERNE_DATEN vorgegeben.
Auszug aus arc_egmo.ste
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
STEUERDATEIEN
…
EXTERNE_DATEN externeDaten
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Die Datei externeDaten.ste ist in Blöcke untergliedert, wobei jeder Block für eine externe Datengrundlage steht und deren räumlich und zeitlich differenzierte Verwendung organisiert. Jeder Block wird durch eine Kennung eingeleitet. Welche Blöcke bzw. welche externen Daten verarbeitet werden sollen, wird durch den Modulentwickler in den Modulen festgelegt. Wie diese Daten dann genutzt werden, ist durch den Nutzer in der Modul.ste zu spezifizieren.
Die zugeordneten Blöcke enthalten wiederum Steuerwörter, die dazu dienen, den Zugriff auf die eigentlichen externen Daten zu organisieren. So ist das Verzeichnis und der Namen der Datei mit den externen Daten anzugeben, die Raumgeometrien, für die die Daten vorliegen, zu definieren und die Verknüpfung mit den Zielgeometrien, auf die die externen Daten gebunden werden sollen, festzulegen.
Über den OBJEKTTYP wird festgelegt, ob die externen Daten in einer der unterstützten Basisgeometrien (EFL | TG | FGW) vorliegen. Ist dies nicht der Fall, erfolgt hier kein oder ein nicht identifizierbarer (d.h. weder EFL noch TG oder FGW) Eintrag.
Mit welchen Basisgeometrien die Verknüpfung erfolgen soll, wird entweder programmintern festgelegt (s. Ini-Routine zur Nutzung der externen Daten im Kap. E2.2) oder über den Eintrag ZUORDNUNG_AUF in der Steuerdatei angegeben. Die Zuordnungsgeometrie (hier EFL) muss wiederum eine der Standardgeometrien von ArcEGMO sein. Diese kann direkt (EFL | TG | FGW) angegeben werden. Möglich ist aber auch die Angabe der Modellebene (MET | ABI | RD | GW | Q), in der die externen Daten verwendet werden, wobei dann programmintern die Raumauflösung, in der diese Modellebene arbeitet, verwendet wird.
Beim Einlesen wird getestet, ob die Tabelle der externen Daten genauso viele Einträge (Zeilen) aufweist wie die aktuell eingelesenen (eventuelle Selektionen werden berücksichtigt) Standardgeometrien aus dem GIS-Verzeichnis. Sind beide gleich, wird angenommen, dass beide Geometrien direkt verknüpft werden können. Die Verknüpfung erfolgt direkt unter Nutzung der schon abgeleiteten Relationen zwischen den Basisgeometrien (hier EFL – TG). Weist die Tabelle der externen Daten mehr oder weniger Einträge als die aktuellen Standardgeometrien auf, wird die Verknüpfung über die OBJEKTID hergestellt. Zu beachten ist, insbesondere dann, wenn die externe Datentabelle weniger Einträge als Standardgeometrien aufweist, dass bestimmten Objekten der Bezugsgeometrien keine Werte zugewiesen werden können.
Unterstützt werden die folgenden Strukturen, in denen die externen Daten vorliegen können:
a) Relatetabellen zu den Basisgeometrien,
b) Attribute der Basisgeometrien,
c) eigenständige Geometrien.
A) Relatetabellen zu den Basisgeometrien
Folgen der Blockkennung genau zwei weitere Informationen, werden diese als Dateityp und Name der Datendatei, letztere u.U. ergänzt durch den absoluten oder relativen Pfad (relativ zum Projektpfad) interpretiert.
Die externen Daten werden dann als komplettes shape oder als Tabelle in den unterstützten Formaten (ASCII | DBASE) in einem separaten Verzeichnis (hier aaa_Daten) erwartet.
Auszug aus externeDaten.ste
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
MONERIS1 DBASE ..aaa_DatenTG.dbf
OBJEKTTYP TG
OBJEKTID TG_DIS
ZUORDNUNG_AUF EFL
…
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
B) Attribute der Basisgeometrien
Stehen hinter der Blockkennung nicht genau zwei weitere Informationen, werden die externen Daten im GIS-Verzeichnis gesucht, und zwar als Attribute der Basisgeometrien (EFL | TG | FGW). Welche dies sind, wird über den OBJEKTTYP angegeben. Die OBJEKTID ist die SchlüsselID der externen Daten. Sie muss somit eindeutig sein, weil sie zur Verknüpfung der externen Daten mit den Modellierungs- bzw. Basisgeometrien von ArcEGMO dient.
Auszug aus externeDaten.ste
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
MONERIS
OBJEKTTYP TG
OBJEKTID TG_DIS
ZUORDNUNG_AUF EFL
…
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
C) Eigenständige Geometrien
Liegen die externen Daten als eigenständige Geometrien vor (z.B. Bilanzgebiete oder Regionen), wird dies über den Objekttyp erkannt, wenn entweder das Schlüsselwort OBJEKTTYP fehlt, der Eintrag hinter dem Schlüsselwort fehlt oder der Eintrag nicht einer Basisgeometrie zugeordnet werden kann.
Auszug aus externeDaten.ste
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
MONERIS_MET DBASE ..Datenmoneris.dbf
OBJEKTTYP
OBJEKTID EZG
ZUORDNUNG_AUF EFL
ZUORDNUNGSSCHLUESSELWORT MONERIS_GEBIET
…
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Über das Attribut in der externen Datenbasis erfolgt die Verknüpfung mit den Bezugsgeometrien (hier EFL, angegeben über das Schlüsselwort ZUORDNUNG_AUF), und zwar mit dem Attribut, das über das ZUORDNUNGSSCHLUESSELWORT (hier MONERIS_GEBIET) in der Strukturdefinitionsdatei der Bezugsgeometrie (hier efl.sdf) vorzugeben ist. Dies bedeutet, dass die eigentliche GIS-Verknüpfung zwischen den externen Daten und den Bezugsgeometrien und das Anlegen des Verknüpfungsattributs (hier MONERIS_GEBIET) schon im Preprocessing bei der GIS-Datenaufbereitung erfolgt sein muss.
Zeitauflösung und Namenskonventionen
Mit den weiteren Einträgen werden dann die zeitliche Diskretisierung der Daten und die vorhandenen Datentypen in der Datenbasis festgelegt.
Fehlt das Steuerwort ZEITDISKRETISIERUNG oder ist diese mit -1 angegeben (analog Zeitdiskretisierung der Ergebnisse in der result.ste) werden die einmalig zu Beginn (ini-Teil der Modellebene oder des aufrufenden Moduls) eingelesenen Daten beibehalten. Ist der Eintrag 0, 1 oder 2 werden die Daten im angegebenen Aktualisierungsrythmus (täglich, monatlich, jährlich) aktualisiert.
Die Namen der dafür einzulesenden Datendateien leiten sich aus dem angegebenen Namen (…invekos.dbf) ab, wobei programmintern vor dem Dateityp der Zeitbezug (…invekos.dbf) eingeschoben wird. Die Namenskonvention für die Zeitbezüge entspricht den bekannten, d.h. in ArcEGMO genutzten Konventionen, d.h. Jahreswerte JJJJ, Monatswerte MM.JJJJ und Tageswerte TT.MM.JJJJ.
Steht hinter der Zeitdiskretisierung (≥ 0) ein weiterer Eintrag, wird zusätzlich zu den Daten, die dem aktuellen Termin zugeordnet sind, ein weiterer, einen Zeitschritt in der Zukunft liegender Datensatz (zum Beispiel für Düngegabe im Herbst, die im Frühjahr schon mit bekannt sein muss) eingelesen. Zu beachten ist, dass die Strukturen dieser Dateien mit unterschiedlichem Zeitbezug identisch sein müssen, da nur bei der Initialisierung der externen Daten die Verknüpfung mit den Modellierungsgeometrien erfolgt.
Die weiteren Einträge kennzeichnen die Datentypen und deren Attributnamen in der Datenbasis, die potenziell für die Modellierung genutzt werden könnten.
Welche Attribute dann wirklich verwendet werden, wird modellspezifisch in der modul.ste festgelegt.
Auszug aus externeDaten.ste
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
INVEKOS_JJJJ DBASE ..aaa_Dateninvekos.dbf
ZEITDISKRETISIERUNG 2 1 /* -1 Gesamtzeitraum [default] */
/* 0 Tag, 1 Monat, 2 Jahr, 3 Stunden */
…
FRUCHTARTEN FRUCHTART
N_MINERALISCH Nmin
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++