Sowohl das MOBILE-System als auch das GIS ArcView bieten ein umfangreiches
System an Datentypen an.
Prinzipiell bestehen mehrere Möglichkeiten, die Datenschnittstelle auf der
Grundlage des einen oder anderen Systems zu realisieren. Diese Entscheidung
muß anhand der Analyse der vorhandenen Datentypen und
Datenaustauschformate gefällt werden.
Alternative 1: Die Datentypen des GIS werden als Grundlage des
Austauschs favorisiert und im Mobile-Kernsystem verlustfrei verfügbar
gemacht.
Alternative 2: Die Datentypen des MOBILE-Kernsystems werden als
Grundlage des Austauschs favorisiert und im GIS verlustfrei verfügbar
gemacht.
Alternative 3: Eine anderweitig standardisierte Menge von Datentypen als
Grundlage des Austauschs wird favorisiert und die Datentypen des
MOBILE-Kernsystems sowie des GIS ArcView darauf abgebildet.
Im MOBILE-Kernsystem sind noch keine Austauschformate definiert, jedoch bietet
die zu seiner Implementation benutzte Programmiersprache Java als flexible,
allgemeine Programmiersprache eine sehr gute Grundlage für eine Anpassung
an anderweitig gestellte Anforderungen. Die Analyse kann sich daher
zunächst auf das GIS ArcView konzentrieren.
Alternative 3 wäre die vielversprechendste Lösung, wenn bereits die
Datentypen oder die Austauschformate ArcViews an weitverbreitete Standards
angepaßt wären und so nur eine Seite der anfallenden Konvertierung
zu programmieren wäre. ArcView unterstützt jedoch nur einige,
für das Anwendungsgebiet des Mobile-Systems nicht vorrangig relevante
Bildformate sowie das weitverbreitete dBASE-Format (vgl. Abschnitt Das GIS
ArcView, Verwaltung (S. 66).
Alternative 1 wäre besonders einfach, wenn die von ArcView eingesetzten
Austauschformate hinreichend mächtig und dokumentiert wären, um alle
benötigten Datentypen abzubilden. Beides zusammen ist nicht der Fall.
* Das dBASE-Format als tabellarisches Format ist nur bedingt für
raumbezogene Daten geeignet. Raumbezogene Daten können zum Beispiel die
Angabe von Polylinien enthalten. Polylinien besitzen eine je nach Anzahl der
Linien stark variierende Länge, was Tabellen mit festen Obergrenzen
für Feldlängen ungeeignet macht, da entweder Daten abgeschnitten
werden oder im schlechtesten Fall für den Austausch von n Datensätzen
bei dem maximalen Polylinienspeicherplatzbedarf lmax eine ungenutzte
Datenübertragung von (n-1)*(lmax-1) auftritt. Im Mittel
beträgt die ungenutzte Datenübertragung immerhin noch
(n-1)*(lmax/2), gleichverteilten Polylinienspeicherplatzbedarf
vorausgesetzt.
* ASCII[15]-Tabellen mit festen
Spaltenlängen unterliegen den gleichen Beschränkungen.
* Für das von ArcView benutzte Format zum Austausch von raumbezogenen
Daten, sogenannte shape files, liegt keine Dokumentation vor.
* Für das Format ARC/INFO liegt ebenfalls keine Dokumentation vor, zudem
kann es von ArcView nur gelesen werden.
* Die zahlreichen Bildformate sind im Anwendungsbereich Verkehr nur sehr
eingeschränkt brauchbar, da hier in in erster Linie Bedarf an
Vektor-Datenstrukturen besteht. Hinzu kommt, daß die in ArcView
verfügbaren Bildformate nur für eine Visualisierung, nicht aber eine
Verarbeitung geeignet sind.
Als Lösung bleibt nur das zunächst nicht weiter strukturierte
ASCII-Zeichenformat. Da es sowohl von Java als auch von ArcView gelesen und
geschrieben werden kann, bietet es sich zur Entwicklung eines eigenen
Datenformates an.
Erneut stellt sich die Frage, ob die Datentypen ArcViews oder die des
Mobile-Kernsystems der Struktur des Austauschformats zugrunde gelegt werden
sollen. Die Wahl fällt hier auf die Mobile-Datentypen als Grundlage, da
sie
* bereits als internes Austauschformat zwischen den einzelnen Bausteinen
verwendet werden und
* die zum Import und Export entwickelten Konverter auch zur Anbindung weiterer
GIS benutzt werden können.
Um eine gute Dokumentationsgrundlage für das Austauschformat zu schaffen,
wird eine Grammatik entwickelt.
Da es wünschenswert ist, bei der Entwicklung der nötigen Konverter
auf manuell erzeugte Testdateien zurückgreifen zu können, sollten die
von der Grammatik erzeugten Dateien gut lesbar sein. Daneben sollte sie leicht
zu parsen sein und einen typisierten Datenaustausch ermöglichen.
Die Grammatik des Austauschformates ist im Abschnitt Grammatik der
Repräsentation der zwischen ArcView und MSL ausgetauschten Datentypen
(S. 110) dokumentiert.
Der Umfang der konvertierbaren Datentypen findet seine Obermenge in der zur
Verfügung stehenden Menge an MSL-Daten-Typen. Diese Menge ist jedoch, da
die MSL-Daten-Typen mit dem Ziel guter Erweiterbarkeit konzipiert wurden, nicht
fest.
Wünschenswert ist natürlich, alle MSL-Daten-Typen konvertieren zu
können. Zur Minimierung des Programmieraufwands muß dieser Anspruch
sinnvoll zurückgeschraubt werden. Einige Datentypen sind zum Beispiel
nicht für ein GIS, sondern für interne Kommunikationszwecke gedacht,
etwa EOL. Andere Datentypen sind sehr speziell und daher
möglicherweise nur von begrenztem Nutzen, wie
TableOfEmissionFactors. Dritte wiederum sind eher rasterorientierte
Datenstrukturen, die vom GIS ArcView nicht adäquat unterstützt
werden, wie Grid.
Unbedingt erforderlich sind hingegen allgemeine Datentypen wie
RealNumber, Text, Boolean und Table.
Daneben stehen weitere, anwendungsbezogene Datentypen auf der Bedarfsliste, die
wegen ihrer relativ geringen Komplexität leicht zu konvertieren sind.
Je nach Anwendungsgebiet eines Simulationsmodells werden sehr unterschiedliche
Datentypen benötigt. Für Hydrologische Modellierung siehe etwa
121[BSV93].
Im Anwendungsgebiet des MOBILE-Systems, die umweltbezogene Simulation von
Verkehr und Logistik, sind es primär vektororientierte Datentypen, daneben
besteht ein Bedarf an 3D-rasterorientierten Datentypen für
Ausbreitungsmodelle von Gasen in der Luft. Letztere unterstützt jedoch
ArcView nicht, so daß die Wahl auf vektororientierte Datentypen
fällt. Diese sind Punkte, Polylinien und Polygone, aber auch Angle,
Duration, Length und Weight. Um nicht zu frühzeitig eine
Einschränkung auf nur zwei-dimensionale Punkte festzulegen, sollen auch
dreidimensionale Punkte konvertierbar sein, wenngleich eine Dimension nur als
Attribut ausgewertet werden kann.
Desweiteren sollen auch einfache spezielle Datentypen aus dem Bereich
umweltbezogener Verkehr konvertierbar sein, wie Velocity, Concentration,
EmissionFactor, EmissionRate und TrafficFlow.
In der Programmiersprache Avenue fehlt die Möglichkeit, ein Script
rekursiv aufzurufen, da jedes Script nur einmal gleichzeitig ablaufen kann.
Dies erschwert das Parsen komplexer Datentypen, wenn sie rekursiv definiert
sind, wie etwa der MSL-Daten-Typ UntypedMatrix, der Java-seitig
wiederum Objekte vom Typ UntypedMatrix enthalten darf. Dies ist von
unmittelbarer Bedeutung bei der Konvertierung aus der
Austauschrepräsentation in die Avenue-Repräsentation und umgekehrt.
Entweder muß deshalb die Rekursionstiefe auf eine kleine, natürliche
Zahl beschränkt werden oder es muß ganz auf rekursiv definierte
Typen verzichtet werden. Im ersten Fall könnte dies in Avenue mittels
einer endlichen Zahl von Scripte realisiert werden, die bis auf den Namen
identisch sind. Dies stellt aber keine befriedigende Lösung dar, da
hierfür ein Avenue-Script n-fach kopiert werden muß, wenn die
Rekursionstiefe n erreicht werden soll.
Java-seitig rekursiv definierte MSL-Typen wie etwa UntypedMatrix
werden zur Konvertierung zugelassen, aber nur mit Rekursionstiefe null. Das
bedeutet, sie können zwar nichtrekursive Typen (NonRecursiveType)
enthalten, nicht aber wiederum Matrizen. Ein Versuch, verschachtelte Matrizen
zu übertragen, wird daher als Fehler zurückgewiesen.
Um der Anforderung an die Erweiterbarkeit der Datenschnittstelle gerecht zu
werden, soll ein Leitfaden zur Erstellung neuer Konverter Bestandteil der
Dokumentation sein. Desweiteren sollen alle zentralen Informationen über
die Schnittstelle auch im WWW als Online-Hilfe zur Verfügung stehen.
Diesem Zweck dient auch die Verfügbarkeit dieser Arbeit im WWW unter
[Hup98] sowie[Hup98a].
Die Erstellung neuer Konverter wird am Beispiel des Datentyps
RoadNetwork beschrieben. RoadNetwork wird für die
Fallstudie Kurierdienst, die im Rahmen des Mobile-Projektes durchgeführt
wird, benötigt.
Die Funktionalität der Programmierschnittstelle wird anhand eines
einfacheren Beispiels aus dem Bereich der Verkehrssimulation erläutert. Es
handelt sich dabei um das SimpleEmissionModel, das zu Testzwecken der
ObjectBase als Simulationsmodellbaustein entwickelt wurde und daher bereits
verfügbar ist.
15] American Standard Code for Information Interchange