Beitragsseiten

Seite 3 von 6

 

7.3 Das räumliche Modell

7.3.1 Übersicht

Bislang wurden nur einfache geometrische Elemente betrachtet, die in Form von einzelnen Punkten bzw. Punktsequenzen gegeben sind. Diese Klassen sollen jetzt verwendet werden, um räumliche Objekte mit zusätzlichen Eigenschaften zu bilden. Besonderes Augenmerk gilt hier den topologischen Beziehungen zwischen den Geo-Objekten, da diese häufig in räumlichen Analysen Verwendung finden. In einem weiteren Schritt wird das Modell um einen zeitlichen Bezug erweitert. Die Geometrie-Klassen sind zwar in ihrer Struktur auf diesen Aspekt hin ausgelegt, aber in den bisherigen Ausführungen wurden noch keine Information zur zeitlichen Gültigkeit räumlicher Daten explizit berücksichtigt.

Abbildung 53: Klassendiagramm für räumlich-temporale Objekte



Quelle: Eigener Entwurf

Zunächst erfolgt eine Unterscheidung in einzelne Geo-Objekte und in Objektgruppen, die als eine Einheit angesprochen werden können. Da die Klassen STObject und STObjectSet beide von STGeoObject abgeleitet sind, sind beide Konstrukte gleichwertig als Funktions­parameter verwendbar. Wichtiger ist aber diese Generalisierung hinsichtlich der Abge­schlossenheit von Operationsergebnissen. Für eine Funktion, die alle von einer gegebenen Linie geschnittenen Flächen ermittelt, kommt als Ergebnis eine einzelne Fläche, mehrere Flächen oder die leere Menge in Frage. Da eine Variable vom Typ STGeoObject sowohl einzelne Objekte als auch Mengen referenzieren kann bzw. für die leere Menge auf Null gesetzt wird, müssen in der Implementierung keine umständlichen Fallunterscheidungen getroffen werden.

7.3.2 Die STObject-Klassen

Instanzen der von STObject abgeleitetenKlassen beschreiben einzeln identifizierbare räumliche Entitäten der Realwelt zu definierten Zeitabschnitten. Während die Klas­sifizierung der Feature-Klassen thematischen Aspekten folgt, sind Geo-Objekte primär durch ihre geometrischen Eigenschaften geprägt.

Die wichtigste Eigenschaft jeder STObject–Instanz ist deshalb seine geometrische Be­schreibung, die durch eine Instanz einer GGeometry-Klasse gegeben ist. Da die von STObject abgeleiteten Klassen unterschiedliche Geometrie-Typen verwenden, kann in dieser abstrakten Oberklasse keine entsprechende Assoziation hergestellt werden. Ersatz­weise wird eine virtuelle Funktion GetGeometry() eingeführt, die in den Ableitungen zu überschreiben ist. Grundsätzlich folgt die Klassenbildung zwei Prinzipien:

  1. Nach der geometrischen Dimension werden Punkte (0D) , Linien (1D) und Flächen (2D) unterschieden.

  2. Hinsichtlich der topologischen Eigenschaften erfolgt eine Unterteilung in ”Spaghetti”-Klassen, die keinen topologischen Konsistenzbedingungen unterliegen, und topo­logisch strukturierten Klassen, die Inzidenz- und Adjazenzbeziehungen abbilden.

7.3.2.1 Spaghetti-Ebene

Geo-Objekte dieser Ebene sind einfach strukturiert. Jedes STPoint-Objekt referenziert ein Exemplar der Klasse GPoint, das die Position angibt. Instanzen der Klassen STLine und STArea verweisen auf ein GPointSeq - Objekt, wobei für Flächen angenommen wird, daß der erste und der letzte Punkt in der Liste miteinander verbunden sind.

Abbildung 54: Spaghetti-Flächen



Quelle: Eigener Entwurf

Zusätzlich kann jedes STArea-Objekt beliebig viele Objekte gleichen Typs aufnehmen. Damit können Instanzen dieser Klasse auch Polygone mit Löchern darstellen. Um die Darstellung der Löcher von der äußeren Umrandung abgrenzen zu können, wird per Kon­vention vereinbart, daß die umschriebene Fläche immer rechts der Linie liegt. Da die Punkte in einer Punktsequenz sortiert und deshalb gerichtet vorliegen, beschreibt eine Um­randung im Uhrzeigersinn eine Fläche und eine Umrandung gegen den Uhrzeigersinn ein Loch. Diese Konvention besitzt somit die Funktion eines Vorzeichens, die eine von einer Punktsequenz umschlossenen Fläche dahingehend beschreibt, ob sie im Anwendungs­kontext zu einem anderen Geo-Objekt hinzuzählen oder abzuziehen ist. Neben der Dar­stellung von Löchern können damit auch Flächen verglichen werden, wobei das ”Vorzeichen” angibt, ob es sich um eine Flächenzunahme oder –abnahme handelt.

7.3.2.2 Topologie-Ebene

Das Design der topologisch strukturierten Klassen orientiert sich an dem in Kapitel 6.2.3 vorgestellten Konzept nach DAVID/ RAYNAL/ SCHORTER 1993. Hier soll zunächst die grundlegende Realisierung erläutert werden (vgl. Abbildung 55).

Abbildung 55: Die Topologische Struktur



Quelle: Eigener Entwurf

Jeder Knoten ist in seiner Position durch eine Instanz von GPoint festgelegt. Die topo­logische Struktur wird hier durch eine Liste der eingehenden Kanten abgebildet. Da alle Kanten vom Typ STEdge gerichtet sind, wird jede Verbindungslinie zumindest indirekt von zwei Kanten referenziert, je eine für jede Richtung. Die Verbindungslinie ist geometrisch durch eine GSecPointSeq-Instanz repräsentiert, die von einem GPlanarLayer-Objekt verwaltet wird. Eine direkte Referenz auf die Geometrie richten nur Objekte von SEdgePos (”positive Kante”) ein. Da jede Kante einen Zeiger auf die inverse Kante be­sitzt, kann eine Instanz von SEdgeNeg (”negative Kante”) über diese Verbindung auf die Geometrie zugreifen, ohne diese selbst direkt referenzieren zu müssen. Zusätzlich besitzt jede Kante einen Zeiger auf den Endknoten sowie die Fläche, die rechts von ihr liegt. Da­mit verfügen die Knoten und Kanten neben ihrer geometrischen Beschreibung über fol­gende Informationen, über die die drei Permutationen und damit ein vollständiges Netz­werk festgelegt sind:

  • Kante (SEdge, spezialisiert in SEdgePos und SEdgeNeg): inverse Kante, Endknoten, Fläche rechts.

  • Knoten (SNode): Liste der eingehenden Kanten

In der Arbeit von DAVID/ RAYNAL/ SCHORTER 1993 sind alle Permutationen als Pointer umgesetzt. Das ist hier durch die Erweiterung auf temporale Daten nicht möglich. Eine Kante kann zum Beispiel für zwei unterschiedliche Zeitpunkte auch verschiedene Nachfolger besitzen. Aus der Datenstruktur selbst läßt sich lediglich die - Permutation in Form der inversen Kante direkt ablesen. Da die anderen Verknüpfungen algorithmisch bestimmt werden müssen, ist es hier notwendig, die Permutationen durch Funktionen zu ersetzen. Das Ergebnis jeder Funktion ist vom Typ SEdge.

  1. Die Funktion GetInverse() entspricht der - Permutation und gibt die von dem einge­richteten Zeiger referenzierte Kante zurück.

  2. Die - Permutation für eine gegebene Kante läßt sich anhand des Endknotens be­stimmen und wird durch die Funktion GetNextOpposite() ersetzt. Dazu muß eine Routine lediglich den Endknoten gegen den Uhrzeigersinn durchlaufen und die erste gefundene eingehende Kante zurückliefern.

  3. Die durch bestimmte Kante erhält man mittels der Funktion GetSuccessor(), die einer Kombination von und entspricht.

  4. Zur Ergänzung wird eine Funktion GetPredecessor() eingeführt, die den Vorgänger einer Kante ermittelt und die Umkehrung von GetSuccessor() darstellt.

Schon die beiden Funktionen GetInverse() und GetOpposite() würden ausreichen, den Graphen vollständig zu beschreiben, aber die zusätzlichen Funktionen erleichtern die De­finition von Flächen.

Die Flächen selbst benötigen nur eine beliebige Kante der Umrandung. Die restlichen Segmente lassen sich dann iterativ mit Hilfe der GetSuccessor()-Funktion bestimmen.

7.3.2.3 Die Geo-Objekt-Mengen

Für GIS-Applikationen ist es sinnvoll, mehrere Geo-Objekte zu einer Gruppe zusammen­zufassen und als eine Einheit ansprechen zu können. Dabei sind aber zwei Fälle zu unter­scheiden, die dazu führen, diese Aggregation auf verschiedenen Ebenen eines objekt­orientierten GIS durchzuführen:

  1. Leitet man die Zusammenfassung primär aus semantischen Aspekten ab, sollte dies auf der Feature-Ebene durchgeführt werden. Beispielsweise könnte man das Feature “Stadtbezirk” thematisch in die Bestandteile “Straßennetz”, “Baublöcke”, “Park­flächen” usw. zerlegen. Da die einzelnen Bestandteile bereits thematische Einheiten darstellen, die neben den rein räumlichen Eigenschaften weitere beschreibende Attri­bute besitzen, ist es günstiger, diese als Feature-Typen in eine Klasse “Stadtbezirk” zu integrieren.

  2. Das Beispiel des Straßennetzes zeigt einen Anwendung, bei der es sinnvoll ist, die Zusammenfassung auf der Ebene der Geo-Objekte durchzuführen, da hier die räum­lichen Eigenschaften im Vordergrund stehen. Applikationen zur Netzwerknavigation benötigen Informationen, welche Netzwerke in einer Datenbank zur Verfügung stehen und wie die einzelnen Elemente darin miteinander verbunden sind. Ein anderes An­wendungsbeispiel sind Geo-Objekte, die das System wegen topologischen Kon­sistenzbedingungen an Kreuzungspunkten segmentiert, wie etwa einzelne Straßen oder Flüsse. Eine Aggregation fügt diese Teilstücke wieder zu einem durchgehenden Strang zusammen, ohne daß die Information über Kreuzungspunkte verdeckt würde.

Abbildung 56: Klassendiagramm für Geo-Objekt-Mengen



Quelle: Eigener Entwurf

Innerhalb der Klassen für Objektmengen erfolgt eine Differenzierung in heterogene und homogene Mengen (Klassen STCollection und STConstrainedSet). Heterogene Mengen können Elemente verschiedener Typen aufnehmen, während homogene Mengen auf eine bestimmte Ableitung von STObject festgelegt sind. Für Objekte von STSet_0D gilt, daß alle Elemente vom Typ STObject_0D sein müssen, womit hier Instanzen der Klassen STPoint sowie STNode zulässig sind. Analog hierzu verhalten sich die Klassen STSet_1D und STSet_2D, die einfache Objektsammlungen für Elemente mit festgelegter Dimension darstellen.

Die Klassen STNetwork und STCoverage bilden im Datenmodell den Ausgangspunkt für wichtige analytische Möglichkeiten eines GIS. Instanzen von STNetwork bilden Netz­werke ab, die in Fom von STEdge-Instanzen gegeben sind. Benutzerdefinierte Ableitungen kann ein Anwendungsprogrammierer um Methoden zur Behandlung typischer Netzwerk-Probleme erweitern, mit denen Aufgaben wie das Handlungsreisenden-Problem, kürzeste Wege in einem Netzwerk oder Erreichbarkeitsanalysen abgedeckt werden können. STCoverage-Objekte nehmen disjunkte STFace-Instanzen auf, die einen Gesamtraum hin­sichtlich eines Merkmales beschreiben.