Grundlagen der Topologie

Dieses Thema gilt nur für ArcEditor und ArcInfo.

Topologie ist eine Sammlung von Regeln, die in Verbindung mit einem Satz von Editier-Werkzeugen und -Techniken eine genauere Modellierung geometrischer Beziehungen durch die Geodatabase ermöglicht. Zur Implementierung der Topologie werden in ArcGIS Regeln verwendet, die definieren, wie geographischer Raum für mehrere Features gleichzeitig genutzt werden kann, sowie eine Reihe von Werkzeugen zur integrierten Bearbeitung von Features mit gemeinsamer Geometrie. Eine Topologie wird in einer Geodatabase in Form einer oder mehrerer Beziehungen gespeichert, die festlegen, wie sich die Features in einer oder mehreren Feature-Classes Geometrie teilen. Die Features, die Bestandteil einer Topologie sind, bleiben Simple-Feature-Classes. Eine Topologie ändert nicht die Definition der Feature-Class, sondern dient als Beschreibung der möglichen räumlichen Beziehungen zwischen Features.

Gründe für die Verwendung einer Topologie

Topologien sind bereits seit langem eine grundlegende Anforderung an GIS-Systeme in Bezug auf Datenmanagement und -integrität. Im Allgemeinen werden mit einem topologischen Datenmodell räumliche Beziehungen verwaltet, indem räumliche Objekte (Punkt-, Linien- und Flächen-Features) als zugrunde liegende grafische Darstellungen topologischer Grundelemente (Knoten, Flächen und Kanten) dargestellt werden. Diese Grundelemente werden zusammen mit ihren wechselseitigen Beziehungen und ihren Beziehungen zu den Features definiert, deren Grenzen sie darstellen, indem die Feature-Geometrien in einem planaren Graphen topologischer Elemente abgebildet werden.

Der grundlegende Zweck einer Topologie besteht darin, die Datenqualität der räumlichen Beziehungen zu gewährleisten und die Datenerfassung zu unterstützen. Mithilfe einer Topologie können in vielen Situationen auch räumliche Beziehungen analysiert werden. Beispielsweise können benachbarte Polygone mit denselben Attributwerten durch Auflösen der Grenzen zusammengeführt werden, oder es kann ein Netzwerk der Elemente in einer Topologiegrafik durchlaufen werden.

Mit einer Topologie kann auch modelliert werden, wie die Geometrien einer Reihe von Feature-Classes integriert werden können. Gelegentlich wird dies als vertikale Integration von Feature-Classes bezeichnet.

Gemeinsame Geometrien von Features in einer Topologie

Features können Geometrien in einer Topologie gemeinsam verwenden. Im Folgenden werden einige Beispiele für benachbarte Features beschrieben:

• Flächen-Features können gemeinsame Grenzen haben (Polygon-Topologie).
• Linien-Features können gemeinsame Endpunkte haben (Kanten-Knoten-Topologie).

Darüber hinaus können mit einer Geodatabase-Topologie auch gemeinsame Geometrien zwischen Feature-Classes verwaltet werden. Beispiel:

• Linien-Features können gemeinsame Segmente mit anderen Linien-Features haben. Flurstücke können beispielsweise in Blöcken verschachtelt sein:
• Flächen-Features können mit anderen Flächen-Features lagegleich sein.
• Linien-Features können sich Endpunkt-Stützpunkte mit anderen Punkt-Features teilen (Node-Topologie).
• Punkt-Features können mit Linien-Features lagegleich sein (Punktereignisse).

Hinweis:

Flurstücke wurden normalerweise mithilfe von Simple-Feature-Classes und Geodatabase-Topologie verwaltet, damit die Feature-Classes, die zum Modellieren von Flurstücken, Grenzen, Eckpunkten und Passpunkten benötigt werden, die erforderlichen Regeln zur Lagegleichheit erfüllen. Eine andere Möglichkeit zur Verwaltung von Flurstücken ist die Verwendung einer Parcel Fabric, die diese Layer automatisch für Sie bereitstellt. Eine Fabric verwaltet ihre eigene interne Topologie, ohne dass eine Geodatabase-Topologie gepflegt oder eine topologische Bearbeitung für die von den Flurstücken verwendeten Layer durchgeführt werden muss.

Ein Hauptunterschied der Modellierung von Flurstücken als Simple Features und Flurstücken in einer Fabric besteht darin, dass die Grenzen von Fabric-Flurstücken ("Linien" in einer Fabric) nicht gemeinsam genutzt werden. Jede Grenze eines Flurstücks weist also einen vollständigen Satz von Linien auf. Die Fabric-Linien benachbarter Flurstücke überschneiden sich und sind lagegleich.

Parcel Fabrics können trotzdem an der Geodatabase-Topologie beteiligt sein. Wenn überlappende Grenzlinien unterschiedliche Geometrien aufweisen, werden die Linien zerteilt, und die Topologiegrafik wird wie üblich erstellt.

Zwei Ansichten: Features und topologische Elemente

In der folgenden Abbildung wird veranschaulicht, wie ein Polygon-Layer beschrieben und verwendet werden kann:

• Als Sammlungen geographischer Features (Punkte, Linien und Polygone)
• Als Graph topologischer Elemente (Knoten, Kanten, Flächen und deren Beziehungen)

Das heißt, dass Sie über zwei Möglichkeiten für das Arbeiten mit Features verfügen: In einer Ansicht sind Features durch ihre Koordinaten definiert, und in der anderen sind Features in einem gerichteten Graphen ihrer topologischen Elemente dargestellt.

Entwicklung einer Geodatabase-Topologie aus ArcInfo-Coverages

Hinweis:

Sie müssen diesen ausführlichen Abschnitt nicht durchlesen, um Geodatabase-Topologien zu implementieren. Dieser Abschnitt empfiehlt sich jedoch, wenn Sie sich für die historische Entwicklung der Konzepte zum Verwalten von Topologien in Datenbanken interessieren.

Ursprung von "Arc-Node" und "georelational"

Anwender von ArcInfo-Coverages schätzen und nutzen bereits seit langem die Vorteile von Topologien beim Verwalten der räumlichen Integrität von Daten.

Im Folgenden werden die Elemente des Datenmodells von ArcInfo-Coverages erläutert.

In einem Coverage wurden die Feature-Grenzen und -Punkte in wenigen Hauptdateien gespeichert, die in ArcInfo Workstation gespeichert und verwaltet werden. Die ARC-Datei enthielt die lineare oder Polygongrenzengeometrie in Form von topologischen Kanten, die als "Arcs" bezeichnet wurden. Die LAB-Datei enthielt Punktpositionen, die als Label-Punkte für Polygone oder als einzelne Punkt-Features verwendet wurden, beispielsweise für ein Quellen-Feature-Layer. In weiteren Dateien wurden die topologischen Beziehungen zwischen den einzelnen Kanten und Polygonen definiert und gespeichert.

In der PAL-Datei (steht für "Polygon-Arc-Liste") wurden beispielsweise Reihenfolge und Richtung der Arcs in den einzelnen Polygonen aufgelistet. In ArcInfo wurden die Koordinaten der einzelnen Polygone für Anzeige-, Analyse- und Abfrageoperationen mit Softwarelogik zusammengestellt. Auf der Grundlage der geordneten Liste von Kanten in der PAL-Datei wurden die Kantenkoordinaten in der ARC-Datei gesucht und zusammengestellt. Die Polygone wurden bei Bedarf zur Laufzeit zusammengestellt.

Das Coverage-Modell bot verschiedene Vorteile:

• Die Topologie wurde in einer einfachen Struktur verwaltet.
• Kanten konnten digitalisiert und einmalig gespeichert, aber für viele Features gemeinsam verwendet werden.
• Es konnten Polygone mit einer enormen Größe (mit Tausenden von Koordinaten) dargestellt werden, da Polygone als geordnete Gruppe von Kanten (Arcs) definiert wurden.
• Die Topologiespeicherstruktur des Coverage war intuitiv. Die physischen topologischen Dateien wurden von den ArcInfo-Anwendern sofort verstanden.

Hinweis:

Interessante historische Tatsache: Der Begriff "Arc" in Verbindung mit dem Tabellen-Manager "Info" führte zum Produktnamen "ArcInfo" und damit zu allen nachfolgenden "Arc"-Produkten in der Esri Produktfamilie – ArcView, ArcIMS, ArcGIS usw.

Coverages hatten jedoch auch einige Nachteile:

• Einige Operationen wurden sehr langsam ausgeführt, da viele Features bei Bedarf on-the-fly zusammengestellt werden mussten. Zu diesen zählten alle Polygone und Multipart-Features wie Regionen (der Coverage-Begriff für Multipart-Polygone) und Routen (der Begriff für Multipart-Linien-Features).
• Topologische Features (wie Polygone, Regionen und Routen) konnten erst nach der Erstellung der Coverage-Topologie verwendet werden. Beim Bearbeiten von Kanten musste die Topologie neu erstellt werden. (Hinweis: Schließlich wurde die Teilverarbeitung eingeführt, bei der nur die geänderten Teile der Coverage-Topologie neu erstellt werden mussten.) Wenn Änderungen an Features in einem topologischen Dataset vorgenommen werden, muss im Allgemeinen ungeachtet des Speichermodells ein geometrischer Analysealgorithmus ausgeführt werden, um die topologischen Beziehungen neu zu erstellen.
• Coverages waren auf die Bearbeitung durch einen Anwender beschränkt. Da die Synchronisierung des topologischen Graphen mit den Feature-Geometrien sichergestellt werden musste, konnte zu einem gegebenen Zeitpunkt jeweils nur ein Anwender die Topologie aktualisieren. Anwender konnten ihre Coverages kacheln und eine gekachelte Datenbank für die Bearbeitung verwalten. Dadurch konnten einzelne Anwender jeweils eine Kachel sperren und bearbeiten. Für die allgemeine Verwendung und Bereitstellung von Daten konnten Anwender Kopien ihrer Kacheln an ein mosaikartiges Daten-Layer anhängen. Mit anderen Worten: Die von ihnen bearbeiteten gekachelten Datasets wurden nicht direkt von allen Anwendern der Organisation gemeinsam verwendet. Sie mussten erst konvertiert werden, was zusätzlichen Arbeits- und Zeitaufwand mit sich brachte.

Shapefiles und das Speichern einfacher Geometrien

Anfang der 1980er Jahre wurden Coverages als wesentliche Verbesserung gegenüber den älteren polygon- und linienbasierten Systemen betrachtet, in denen Polygone als vollständige Schleifen gespeichert wurden. In diesen älteren Systemen wurden alle Koordinaten für ein Feature in der Geometrie der einzelnen Features gespeichert. Vor der Einführung von Coverages und ArcInfo wurden diese einfachen Polygon- und Linienstrukturen verwendet. Diese Datenstrukturen waren unkompliziert, hatten jedoch den Nachteil der "doppelt digitalisierten Grenzen". Das bedeutet, dass Koordinaten der benachbarten Teile von Polygonen mit gemeinsamen Kanten in den Geometrien beider Polygone enthalten waren. Der grundlegende Nachteil bestand darin, dass GIS-Software damals nicht die Integrität der gemeinsamen Kanten sicherstellen konnte. Darüber hinaus waren die Kosten für die Speicherung sehr hoch. Anfang der 1980er Jahre hatte ein 300 MB-Festplattenlaufwerk die Größe einer Waschmaschine und kostete 30.000 Dollar. Die Verwaltung von zwei oder mehr Darstellungen von Koordinaten war aufwändig, und die Berechnungen dauerten viel zu lange. Daher bot die Verwendung einer Coverage-Topologie echte Vorteile.

Mitte der 1990er wuchs das Interesse an unkomplizierten geometrischen Strukturen, da die Kosten für Festplattenspeicher und allgemein für Hardwareprodukte sanken, während die mögliche Rechengeschwindigkeit anstieg. Gleichzeitig stieg die Verfügbarkeit von vorhandenen GIS-Datasets, und die Arbeit von GIS-Anwendern umfasste nicht mehr ausschließlich die Datenerfassung, sondern auch die Nutzung, die Analyse und die gemeinsame Verwendung von Daten mit anderen.

Anwender forderten eine bessere Performance bei der Arbeit mit den Daten (beispielsweise, dass keine Computerkapazitäten zum Ableiten von Polygongeometrien belegt werden, wenn diese benötigt werden. Die Feature-Koordinaten dieser 1.200 Polygone sollen einfach so schnell wie möglich bereitgestellt werden.) Die ständige Verfügbarkeit der gesamten Feature-Geometrie war bei weitem effizienter. Mehrere tausend geographische Informationssysteme waren in Gebrauch und zahlreiche Datasets waren direkt verfügbar.

Damals wurde das Esri Shapefile-Format von Esri entwickelt und veröffentlicht. Shapefiles lag ein sehr einfaches Speichermodell für Feature-Koordinaten zugrunde. Jedes Shapefile stellte eine einzige Feature-Class (von Punkten, Linien oder Polygonen) dar und verwendete ein einfaches Speichermodell für die Koordinaten des Features. Shapefiles konnten auf einfache Weise aus ArcInfo-Coverages sowie aus vielen anderen geographischen Informationssystemen erstellt werden. Sie wurden allgemein als De-facto-Standard akzeptiert und werden bis heute häufig eingesetzt.

Einige Jahre später entwickelte ArcSDE erstmalig ein ähnlich einfaches Speichermodell in relationalen Datenbanktabellen. Eine Feature-Tabelle konnte ein Feature pro Zeile mit der Geometrie in einer der Spalten zusammen mit anderen Feature-Attributspalten enthalten.

Ein Beispiel für eine Feature-Tabelle von Polygonen für Bundesstaaten wird unten veranschaulicht. Jede Zeile stellt einen Bundesstaat dar. Die Shape-Spalte enthält die Polygon-Geometrie der einzelnen Bundesstaaten.

Dieses Modell für Simple Features ist hervorragend für die SQL-Verarbeitungs-Engine geeignet. Durch die Nutzung von relationalen Datenbanken konnte der Umfang der GIS-Daten und die Anzahl der Anwender erheblich gesteigert werden, ohne dass dadurch die Performance beeinträchtigt wurde. Dies war der Anfang für die Nutzung von RDBMS zum Verwalten von GIS-Daten.

Shapefiles wurden vielfach eingesetzt, und durch die Verwendung von ArcSDE wurde dieser Mechanismus der Simple Features zum grundlegenden Feature-Speichermodell in RDBMS. (Zur Unterstützung der Interoperabilität setzte sich Esri als führender Autor der OGC- und ISO-Spezifikation für Simple Features ein.)

Die Speicherung von Simple Features hatte eindeutige Vorteile:

• Die vollständige Geometrie für die einzelnen Features ist jeweils in einem Datensatz gespeichert. Die Daten müssen nicht zusammengestellt werden.
• Die Datenstruktur (das physische Schema) ist sehr einfach, schnell und skalierbar.
• Programmierer können auf einfache Weise Schnittstellen entwickeln.
• Interoperabilität ist gegeben. Häufig wurden einfache Konvertierungsprogramme geschrieben, um Daten aus diesen einfachen Geometrien in eine Vielzahl von Formaten bzw. aus diesen Formaten umzuwandeln. Shapefiles fanden breite Anwendung als Datenverwendungs- und -austauschformat.

Die Nachteile bestanden darin, dass die Datenintegrität, die durch die Topologie gewährleistet wurde, nicht so leicht für Simple Features implementiert werden konnte. Daher nutzten Anwender ein Datenmodell zum Bearbeiten und Verwalten (z. B. Coverages) und ein anderes für die Bereitstellung (beispielsweise Shapefiles oder ArcSDE-Layer).

Anwender stützten sich beim Bearbeiten und Bereitstellen von Daten zunehmend auf diesen Hybridansatz. Sie konnten beispielsweise ihre Daten in Coverages, CAD-Dateien und anderen Formaten bearbeiten. Anschließend konvertierten sie ihre Daten in Shapefiles, um sie bereitzustellen und zu verwenden. Obwohl also die Struktur mit Simple Features ein hervorragend geeignetes Format für die direkte Verwendung war, unterstützte es nicht die topologische Bearbeitung und die Verwaltung von Daten gemeinsamer Geometrien. Datenbanken für die direkte Verwendung konnten die einfachen Strukturen nutzen, für die Bearbeitung wurde jedoch ein anderes topologisches Format verwendet. Dies hatte Vorteile bei der Bereitstellung. Der Nachteil bestand jedoch darin, dass die Daten veralteten und aktualisiert werden mussten. Der Ansatz funktionierte, bei der Aktualisierung der Informationen gab es jedoch stets Verzögerungen. Mit einem Wort: Die Topologie fehlte.

Was für GIS erforderlich war und nun vom Geodatabase-Topologiemodell implementiert wird, ist ein Mechanismus, mit dem Features mithilfe von einfachen Feature-Geometrien gespeichert werden, der es jedoch erlaubt, Topologien für diese einfache, offene Datenstruktur zu verwenden. Das heißt, dass Anwender die Vorteile beider Ansätze nutzen können – die eines Transaktionsdatenmodells, das topologische Abfragen, die Bearbeitung gemeinsamer Geometrien und komplexe Datenmodelle ermöglicht sowie die Datenintegrität sicherstellt, jedoch auch die eines einfachen, hoch skalierbaren Datenspeichermechanismus, der auf offenen, einfachen Feature-Geometrien basiert.

Dieses Datenmodell für die direkte Verwendung ist schnell, unkompliziert und effizient. Zudem kann es von vielen Anwendern gleichzeitig direkt bearbeitet und gepflegt werden.

Die Topologieumgebung in ArcGIS

Die Topologie wurde nicht nur als reines Datenspeicherungsproblem betrachtet. Die vollständige Lösung bietet Folgendes:

• Ein vollständiges Datenmodell (Objekte, Integritätsregeln, Bearbeitungs- und Validierungswerkzeuge, eine Topologie- und Geometrie-Engine, mit der Datasets beliebiger Größe und Komplexität verarbeitet werden können, sowie eine Vielzahl von topologischen Operatoren, Kartenanzeigen und Abfragewerkzeugen)
• Ein offenes Speicherformat mit einer Reihe von Datensatztypen für Simple Features und einer topologischen Schnittstelle zum Abfragen von einfachen Features, zum Abrufen von topologischen Elementen und zum Navigieren durch deren räumliche Beziehungen (z. B. zum Bestimmen von benachbarten Flächen und deren gemeinsamen Kanten oder von Routen entlang verbundener Linien)
• Die Möglichkeit, die Features (Punkte, Linien und Polygone) sowie die topologischen Elemente (Knoten, Kanten und Flächen) zusammen mit deren Beziehungen untereinander bereitzustellen
• Einen Mechanismus, der Folgendes unterstützt:
  • Außerordentlich umfangreiche Datasets mit mehreren Millionen Features
  • Die Möglichkeit, dass viele Anwender die Daten gleichzeitig bearbeiten und pflegen können
  • Ständig verfügbare und direkt verwendbare Feature-Geometrien
  • Unterstützung von topologischer Integrität und topologischem Verhalten
  • Ein System mit hoher Performance, das auf viele Anwender und Bearbeiter skaliert werden kann
  • Ein flexibles und einfaches System
  • Ein System, in dem die SQL-Engine und Transaktionsumgebung des RDBMS genutzt werden
  • Ein System, das viele Bearbeiter, lang andauernde Transaktionen, die Archivierung der Historie und Replikation unterstützt

Bei der Validierung einer Geodatabase-Topologie werden die gemeinsamen Koordinaten von Features bestimmt (sowohl innerhalb einer Feature-Class als auch zwischen Feature-Classes). Mit einem Cluster-Algorithmus wird sichergestellt, dass die gemeinsamen Koordinaten dieselbe Lage aufweisen. Diese gemeinsamen Koordinaten werden als Teil der einfachen Geometrie der einzelnen Features gespeichert.

Dies ermöglicht sehr schnelle und skalierbare Suchvorgänge topologischer Elemente (Knoten, Kanten und Flächen). Dieser Ansatz bietet zudem den Vorteil, dass er sich gut für die SQL-Engine und die Transaktionsmanagementumgebung des RDBMS eignet und mit diesen skaliert.

Wenn bei der Bearbeitung und Aktualisierung Features hinzugefügt werden, können diese direkt verwendet werden. Die aktualisierten Flächen auf der Karte ("nicht überprüfte Flächen") werden bei Aktualisierungen der einzelnen Feature-Classes entsprechend gekennzeichnet und verfolgt. Anwender können die nicht überprüften Flächen jederzeit topologisch analysieren und validieren, um eine fehlerfreie Topologie zu erzeugen. Nur die Topologie für die nicht überprüften Flächen muss erneut erstellt werden. Dies spart Verarbeitungszeit.

Topologische Grundelemente (Knoten, Kanten und Flächen) und ihre Beziehungen zueinander sowie ihre Features können effizient bestimmt und zusammengestellt werden. Dies hat mehrere Vorteile:

• Features werden in Form von einfachen Feature-Geometrien gespeichert. Dieses Speichermodell ist offen sowie effizient und kann auf große Datenmengen und viele Anwender skaliert werden.
• Dieses Datenmodell für Simple Features ist ein Mehrbenutzer-Transaktionsmodell. Im Unterschied dazu sind die älteren topologischen Speichermodelle nicht skalierbar, und Transaktionen durch mehrere Bearbeiter sowie viele andere Workflows des GIS-Datenmanagements werden nur umständlich unterstützt.
• Geodatabase-Topologien unterstützen uneingeschränkt alle Funktionen für lang andauernde Transaktionen und die Versionierung der Geodatabase. Geodatabase-Topologien müssen nicht gekachelt werden, und viele Anwender können die topologische Datenbank gleichzeitig bearbeiten, auch individuelle Versionen bestimmter Features, wenn dies erforderlich sein sollte.
• Feature-Classes können auf eine beliebige Größe anwachsen (Hunderte Millionen von Features). Die Performance verbleibt dabei sehr gut.
• Die Implementierung der Topologie ist additiv. Typischerweise können Sie sie einem vorhandenen Schema von räumlich in Beziehung stehenden Feature-Classes hinzufügen. Die Alternative besteht darin, alle vorhandenen Feature-Classes neu zu definieren und in neue Datenschemas zu konvertieren, die topologische Grundelemente enthalten.
• Zum Bearbeiten von Geometrien und zum Verwenden der Daten sind nicht zwei oder mehr, sondern lediglich ein Datenmodell erforderlich.
• Interoperabilität ist gegeben, weil sich die gesamte Speicherung der Feature-Geometrien an den Open Geospatial Consortium- und ISO-Spezifikationen für Simple Features orientiert.
• Die Datenmodellierung ist wirklichkeitsnäher, da sie auf realen Features (wie Flurstücken, Straßen, Bodentypen und Wasserscheiden) und nicht auf topologischen Grundelementen (wie Knoten, Kanten und Flächen) basiert. Die Anwender befassen sich daher mit den Integritätsregeln und dem Verhalten der tatsächlichen Features und nicht mit den Integritätsregeln der topologischen Grundelemente. Beispiel: Wie verhalten sich Flurstücke? Dies führt zu einer wirksameren Modellierung für alle Arten von geographischen Features. In der Folge verbessert dies unsere Wahrnehmung von Straßen, Bodentypen, Zähleinheiten, Wasserscheiden, Gleisnetzen, Geologie, Waldbeständen, Landschaftsräumen, physischen Merkmalen usw.
• Geodatabase-Topologien stellen dieselben Informationen wie gespeicherte topologische Implementierungen bereit: Entweder Sie speichern ein topologisches Liniendiagramm und bestimmen die Feature-Geometrie (wie ArcInfo-Coverages), oder Sie speichern die Feature-Geometrie und bestimmen die topologischen Elemente und Beziehungen (wie Geodatabases).

In Fällen, in denen Anwender die topologischen Grundelemente speichern möchten, können Topologien und ihre Beziehungen auf einfache Weise erstellt und zu den verschiedensten Zwecken im Zusammenhang mit Analysen und der Interoperabilität in Tabellen veröffentlicht werden. (Beispiel: Anwender möchten ihre Features in einem Oracle Spatial-Warehouse veröffentlichen, in dem Tabellen mit topologischen Grundelementen gespeichert sind.)

In pragmatischer Hinsicht ist die Implementierung von ArcGIS-Topologien eine gute Lösung. Ohne Beeinträchtigung der Performance kann eine Skalierung auf außergewöhnlich große Geodatabases und Mehrbenutzersysteme erfolgen. Es sind Validierungs- und Bearbeitungswerkzeuge zum Erstellen und Verwalten von Topologien in Geodatabases verfügbar. Es werden vielfältige und flexible Werkzeuge für die Datenmodellierung bereitgestellt, mit denen Anwender praktische, funktionstüchtige Systeme in Dateisystemen, in beliebigen relationalen Datenbanken und für eine beliebige Anzahl von Schemas zusammenstellen können.