Die in Teilen vorgestellten Komponenten der Schnittstelle zwischen dem
MOBILE-Kernsystem und dem GIS ArcView werden nachfolgend anhand eines einfachen
Anwendungsbeispiels in ihrer Zusammenarbeit erläutert.
Das Anwendungsbeispiel verwendet ein einfaches Emissionsmodell, welches bereits
als Baustein der ObjectBase des MOBILE-Systems vorliegt, und zwar als
Simulationsmodellbaustein SimpleEmissionModel im package
Mobile.Simulator.Examples. Die Dokumentation dazu findet sich unter
[Mey97].
Das Beispiel besteht aus zwei Experimenten: einem Basis-Experiment für das
SimpleEmissionModel (Abb. 33) und einem höheren Experiment
für das SimpleEmissionModel (Abb. 34). Zu diesen beiden
Experimenten gehören Bausteine, die die von mir im Rahmen meiner
Diplomarbeit erstellte Schnittstelle zwischen dem Mobile-Kernsystem und dem GIS
ArcView nutzen.
Aus[Mey97] geht hervor, welche Parameter und Ein- bzw. Ausgabevariablen das
SimpleEmissionModel verwendet.
Modellparameter:
* emissionFactors: eine Tabelle mit Emissionsfaktoren in [g/(KFZ km)]
zu 1 bis n Schadstoffen
* pollutant: Bezeichung des Schadstoffs, für den die
Emissionsrate bestimmt werden soll
* streetLength: Länge der betrachteten Straße
(Linienquelle) in [km]
Eingabevariablen:
* trafficFlow: Verkehrsstärke in[Kfz/h]
* velocity: mittlere Geschwindigkeit
Ausgabevariablen:
* emissionRate: Emissionsrate in [g/s] für den spezifizierten
Schadstoff
Bei der Konzeption des Beispielexperiments steht zunächst einmal
unabhängig von konkreten Realisierungsmöglichkeiten die Frage im
Vordergrund, ob das Modell überhaupt mit einem GIS gekoppelt werden
sollte.
Durch die Verwendung des eindeutig raumbezogenen Parameters
streetLength (eine eindimensionale Raumangabe, s. Abschnitt
Raum und Raumbezug in Geographischen Informationssystemen, S. 18) ist
die notwendige Bedingung für die Kopplung erfüllt, nämlich
daß raumbezogene Daten benutzt oder produziert werden. Da eine Länge
genausogut nicht-geographischer Raumbezug sein könnte, muß erst noch
die hinreichende Bedingung erfüllt sein: Es muß ein geographischer
Raumbezug durch die zu verwendenden Daten hergestellt werden, d.h. es
müssen Daten vorhanden (oder in Erwartung) sein, die einen geographischen
Raumbezug aufweisen. Dies ist der Fall, da unter anderem die Geometrie-Daten
des Straßennetzes von Hamburg im GIS ArcView zur Verfügung
stehen.
Desweiteren soll überlegt werden, welche der verwendeten Daten (Parameter
und Variablen) zur Vorhaltung in einem GIS typischerweise geeignet wären
und welche weniger.
Die Entscheidung ist für den Parameter streetLength nach eben
Gesagtem klar. Er ist eindeutig raumbezogen, sollte also aus dem GIS gewonnen
werden.
Der Parameter pollutant ist für sich genommen ohne Raumbezug, und
sie hängen auch nicht von geographischen Gegebenheiten ab, sondern einzig
von der Fragestellung der BenutzerIn.
Der Parameter emissionFactor kann als ebenso gegeben betrachtet werden
wie pollutant. Es wäre aber auch denkbar, daß die
Emissionsfaktoren auch von geographischen Faktoren abhängen, etwa von der
Steigung der Straße oder vom Straßentyp.
Um das Beispiel nicht zu überfrachten wird angenommen, daß
emissionFactor außerhalb des GIS vorgegeben wird. Gleiches
gilt für den Parameter pollutant.
Die nächste Überlegung gilt den Variablen trafficFlow und
velocity. Sie sind zum einen abhängig von der Straße, in
der sie auftreten und zum anderen von der Zeit.
Die Abhängigkeit von der Straße stellt einen indirekten
Raumbezug dar (vgl. vorgenannten Abschnitt). Dieser Umstand
prädestiniert sie, im GIS gespeichert zu werden. Die fiktiven, manuell
erstellten Daten könnten etwa Ergebnisse von Messungen in der
Realität sein oder Ergebnisse eines Experiments mit einem
Verkehrsumlegungsmodell (vgl.[HMP97]). Die Zuordnung der Straße zu
trafficFlow und velocity wird über den sie
repräsentierenden Straßennamen geleistet.
Für die Abhängigkeit von der Zeit existieren in ArcView keine
besonderen Analysemöglichkeiten. Deswegen wird in diesem Beispiel die
Behelfslösung verwendet , die Zeit als Teil des Titels der Tabelle zu
speichern. So ist sie auch für eventuelle Benutzerinteraktionen
ersichtlich. Verkehr schwankt in Abhängigkeit von der Tageszeit, vom
Wochentag, der Jahreszeit und weiteren, nicht so regelmäßigen
Faktoren wie Schulferien oder Feiertagen. Die fiktiven Werte wären in
diesem Sinne interpretierbar entweder als stündlich aufgelöste
generalisierte Tagesganglinie oder als Ganglinie eines bestimmten Tages, dessen
ebenso fiktives Datum hier allerdings fehlt.
Abschließend ist noch zu konzeptionieren, wo die aus dem
SimpleEmissionModel gewonnenen Daten zu speichern sind. Zunächst einmal
werden sie im Rahmen des MOBILE-Systems als Objekt der Objektbank
abgespeichert (vgl.[Müg97]). An die Speicherung könnte sich
allerdings noch eine Visualisierung im GIS anschließen bzw. ihr
vorausgehen. Um das Beispiel nicht zu überladen ist dies hier aber nicht
ausgeführt.
Zusammenfassend können also folgende Anforderungen an ein auf dem
SimpleEmissionModel basierendes Experiment in Hinblick auf die
Kopplung mit einem GIS gestellt werden:
* Die Variablen trafficFlow und velocity sollen als
Zeitreihen in Abhängigkeit von der Straße aus einer Datenquelle, die
das GIS benutzt, geliefert werden. Die Straße wird dabei durch den
Straßennamen repräsentiert.
* Die Parameter pollutant und emissionFactor werden als
gegeben angenommen und daher nicht weiter betrachtet.
* Der Parameter streetLength wird aus dem GIS gewonnen
* die Ausgangsvariable emissionRate wird als Zeitreihe in
Abhängigkeit von der Straße bzw. des Straßennamens in einer
Datensenke aufgezeichnet. Eine Visualisierung im GIS kommt in Frage, ist aber
in diesem Beispiel nicht umgesetzt.[22]
Zur Umsetzung der gestellten Anforderungen sind zwei Datenquellen auf zwei
unterschiedlichen Experimentebenen günstig:
Für das Basisexperiment ist der Datenquellenbaustein
TrafficFlowAndVelocityGenerator
implementiert. Er bekommt als Parameter einen Straßennamen und erstellt
aus der in Form von 24 Tabellen vorliegenden Zeitreihe der mittleren
Geschwindigkeiten und Verkehrsstärken aller Straßen eine
Zeitreihe der mittleren Geschwindigkeiten und Verkehrsstärken für
eine Straße.
Zur Erstellung dieser Zeitreihe wird 24 mal unter Angabe des
Straßennamens und der Stunde des Tages aus dem Java-seitigen
Generator ein korrespondierendes Avenue-Script aufgerufen. Dieses
greift auf die Zeitreihe aller Straßen zu. Es wählt anhand der
Stunde des Tages die passende Tabelle und selektiert in dieser einen Datensatz
anhand des Straßennamens, um dem Datensatz die mittlere Geschwindigkeit
und die Verkehrsstärke zu entnehmen. Die mittlere Geschwindigkeit und die
Verkehrsstärke werden an den Java-seitigen Generator
zurückgegeben und dort als zwei verschiedene, aber gleichgetaktete
Zeitreihen von trafficFlow bzw. velocity ausgegeben.
Zu beachten ist, daß die Zeitreihe aller Straßen eine Konstante
ist, die im korrespondierenden Avenue-Script fest angegeben ist. Dies
schöpft die konzipierten Möglichkeiten des MOBILE-Systems nicht aus.
Den Möglichkeiten entsprechend würde die Zeitreihe als ein weiterer
Parameter des Basis-Experiments mit angegeben, um auch für andere
Tagesgänge flexibel einsetzbar zu sein. Hierfür kann als Referenz der
Name des Projekts verwendet werden, in dem sich die Tabellen befinden, besser
aber würden die als Konzept vorliegenden ArcView-Datenreferenzen (s.
S 83) verwendet.
Würde der Parameter streetLength des SimpleEmissionModel
auf derselben (Zeit-)reihenebene angesiedelt werden wie trafficFlow
und velocity, so müßte streetLength 24 mal
konstant ausgegeben werden. Weder entspricht dies dem MOBILE-Konzept noch gibt
es die Möglichkeit, eine Variable des Datenflusses auf die Ebene der
Parameter zu bringen, da die Variablen erst zur Laufzeit des Experiments
bestimmt werden, die Parameter aber bereits zur Instantiierungszeit in der
Objektbank vorliegen müssen. Da im Mobile-Konzept ebenfalls nicht
vorgesehen ist, zur Instantiierungszeit erst eine Berechnung eines Parameters
vorzunehmen, bleibt nur die Möglichkeit, den Parameter von einer Variablen
einer höheren Experimentebene gleichsam herunterzureichen. Ein
höheres Experiment, welches das Basis-Experiment einmal für jede
Straße ausführt, erfüllt diesen Zweck. Eine Alternative stellt
auch hier das Konzept der ArcView-Datenreferenzen dar (s. S. 83).
Zur Versorgung des Basis-Experiments mit Daten werden wiederum atomare
Bausteine eingesetzt, und zwar eine Datenquelle, die eine Reihe von
Straßennamen produziert, und eine Auswertungsmethode, die für jeden
Straßennamen eine Straßenlänge produziert. Zusätzlich
reicht die Auswertungsmethode auch noch den jeweils zugehörigen
Straßennamen durch.
Die höhere Ebene des Experiments wird nur durch das Enthaltensein eines
Experiments bestimmt, die sonstigen Bausteine können hingegen atomar sein.
Die direkte Nutzung der Schnittstelle zum GIS ArcView ist sogar
ausschließlich atomaren Bausteinen vorbehalten, komplexe Bausteine
benötigen die indirekte Nutzung durch atomare Bausteine.
Zum Zeitpunkt der Fertigstellung des einfachen Anwendungsbeispiels stand auf
dem Macintosh noch kein komplettes lauffähiges MOBILE-Kernsystem zur
Verfügung. Deshalb kann das MOBILE-System nicht zum Testen des
Laufzeitverhaltens der Bausteine mit Nutzung der Schnittstelle zu ArcView bzw.
des dazu korrespondierenden Avenue-Scripts genutzt werden.
Zum Test wurden die Bausteine run()-Methoden der Java-Klassen zu
main()-Methoden folgendermaßen umgearbeitet:
* Test-Eingabedaten für die InputPorts sind als Aufrufparameter der
main()-Methode implementiert. Sie werden in der
Benutzungsschnittstelle der MRJ-Virtual Machine (JBindery) im Feld "Optional
Parameters" eingegeben.
* Ausgabedaten werden nicht an OutputPorts, sondern auf den
Standardausgabestrom geschrieben. Dies ist java.lang.System.out().
Für den Baustein TrafficFlowAndVelocity ist die Ausgabe des
Testlaufs für die Eingabe "Schanzenstr." wiedergegeben, dabei sind die
Ergebnisse für die Stunden 4 bis 22 weggelassen. Der erläuternde Text
würde so nicht auf den OutputPort geschrieben, sondern dient nur
der Illustrierung der Bedeutung der Zahlen für diesen Test.
Stunde des Tages: 1.0
Verkehrsstärke: 60.0[Kfz/h] Maßeinheit Kfz/h
mittlere Geschwindigkeit: 50.0 [km/h] Maßeinheit km/h
Stunde des Tages: 2.0
Verkehrsstärke: 80.0[Kfz/h] Maßeinheit Kfz/h
mittlere Geschwindigkeit: 50.0 [km/h] Maßeinheit km/h
Stunde des Tages: 3.0
Verkehrsstärke: 90.0[Kfz/h] Maßeinheit Kfz/h
mittlere Geschwindigkeit: 50.0 [km/h] Maßeinheit km/h
[...]
Stunde des Tages: 23.0
Verkehrsstärke: 180.0[Kfz/h] Maßeinheit Kfz/h
mittlere Geschwindigkeit: 48.0 [km/h] Maßeinheit km/h
Stunde des Tages: 24.0
Verkehrsstärke: 70.0[Kfz/h] Maßeinheit Kfz/h
mittlere Geschwindigkeit: 49.0 [km/h] Maßeinheit km/h
Verkehrsstärke EOD
mittlere Geschwindigkeit EOD
Mit dem Signal EOD zeigen die OutputPorts den nachfolgenden
InputPorts das Ende der Reihe an (s. [Müg97]).
[22] Eine Umsetzung mit einem eingebetteten Simulationsmodell s.[Mey97a].