Kurzer Überblick zum Überprüfen von Konflikten

Dieses Thema gilt nur für ArcEditor und ArcInfo.

ArcGIS erkennt Konflikte beim Abgleichen. Konflikte treten in folgenden Fällen auf:

• In der derzeit bearbeiteten und in der Zielversion wird dasselbe Feature aktualisiert.
• Ein einzelnes Feature wird in einer Version aktualisiert und in einer anderen gelöscht.
• Ein topologisch in Beziehung stehendes Feature bzw. eine Beziehungsklasse wird in der derzeit bearbeiteten und in der Zielversion geändert.

Wenn Konflikte bestehen, löst ArcGIS diese je nach gewählter Einstellung zugunsten der Repräsentation in der Editierversion oder in der Zielversion. Nachdem die Konflikte gelöst sind, können Sie diese einzeln überprüfen und bei Bedarf Änderungen vornehmen. Wenn z. B. ein Konflikt zugunsten der Editierversion gelöst wurde, können Sie diese Fassung durch die Fassung in der Zielversion ersetzen oder mit den Editierwerkzeugen auf andere Weise ändern.

Interaktive Konfliktlösung

Wenn Sie den Abgleich vornehmen und dabei Konflikte festgestellt werden, können Sie diese im interaktiven Dialogfeld "Konflikte" überprüfen. Dieses enthält alle Klassen sowie die jeweiligen Features oder Zeilen, die in Konflikt stehen. Außerdem können Sie darin folgende Aktionen ausführen:

• Ermitteln der in Konflikt stehenden Felder oder Zeilen
• Anzeigen von Konflikten
• Lösen von Konflikten durch Festlegen der Repräsentation, mit der Features oder Attribute ersetzt werden sollen

Ermitteln der in Konflikt stehenden Felder oder Zeilen

Alle in Konflikt stehenden Klassen und Features werden im Listenfeld links oben im Dialogfeld "Konflikte" aufgeführt. Dieser Liste "Konflikte" können Sie die Gesamtzahl der überprüften Konflikte und die Gesamtzahl der Konflikte in allen Feature-Classes entnehmen. Anfänglich sind diese Zahlen gleich. Im folgenden Beispiel stehen insgesamt zwei Objekte in Konflikt, von denen bisher keines überprüft wurde.

Conflicts (2/2)

Unter "Konflikte" finden Sie eine Liste der Feature-Classes, die Konflikte enthalten, gefolgt von der Anzahl der gesehenen oder ersetzten Konflikte in der Feature-Class und der Anzahl der Konflikte in der Feature-Class. In diesem Beispiel enthalten zwei Feature-Classes jeweils einen Konflikt.

Conflicts (2/2)

   sde.RJP.ponds (1/1)

   sde.RJP.lakes (1/1)

Unter jeder Feature-Class sind die ObjectIDs für die in Konflikt stehenden Features aufgeführt. In diesem Beispiel besteht ein Konflikt für ObjectID 30 in der Ponds-Feature-Class und ein Konflikt für Feature 11 in der Lakes-Feature-Class.

Conflicts (2/2)

   sde.RJP.ponds (1/1)

        30

   sde.RJP.lakes (1/1)

        11

Keines der Objekte wurde gesehen oder ersetzt. Sie können dies daran erkennen, dass das Verhältnis zwischen überprüften Konflikten und der Gesamtzahl der Konflikte für jede Feature-Class immer noch (2/2) bzw. (1/1) lautet. Ein weiteres Anzeichen dafür, dass keiner der Konflikte gesehen oder ersetzt wurde, ist die Fettformatierung aller ObjectIDs und Feature-Classes.

Wenn Sie Objekte als gesehen markieren (siehe "Als gesehen markieren" oder "Als nicht gesehen markieren" weiter unten) oder Objekte ersetzen (siehe "Auflösen von Konflikten" weiter unten), reduziert sich die erste Zahl in der Klammer. Außerdem wird die überprüfte ObjectID nicht mehr fett formatiert angezeigt. Wenn alle ObjectIDs in einer Feature-Class als gesehen oder ersetzt markiert wurden, wird auch die Feature-Class selbst nicht mehr fett formatiert angezeigt. Wenn Sie im Beispiel zu den Teichen und Seen die ObjectID 30 als gesehen markiert haben, wird im Listenfeld des Dialogfeldes "Konflikte" Folgendes angezeigt:

Conflicts (1/2)

   sde.RJP.ponds (0/1)  

        30      

   sde.RJP.lakes (1/1)

        11

Wenn ein zweites Ponds-Feature in Konflikt stehen würde, könnte die Liste folgendermaßen aussehen:

Conflicts (2/3)

   sde.RJP.ponds (1/2)

        5  

        30    

   sde.RJP.lakes (1/1)

        11

Diese Liste gibt an, dass im Ergebnis des Abgleichs insgesamt drei Konflikte vorhanden sind und einer der drei Konflikte gesehen oder ersetzt wurde. Die Liste gibt auch an, dass das in Konflikt stehende Feature mit der ObjectID 30 gesehen oder ersetzt wurde und dieses Feature der Ponds-Feature-Class angehört.

Wenn Sie ein einzelnes Feature in der Liste auswählen, werden in der Liste auf der rechten Seite des Dialogfeldes "Konflikte" die Spalten und Attribute in der Version vor dem Abgleich, der Konfliktversion und der gemeinsamen Vorgängerversion des Features angezeigt.

• Die Version vor dem Abgleich stellt die von Ihnen vorgenommenen Änderungen am Feature und an den Attributen dar.
• Die Konfliktversion stellt das Feature und dessen Attribute in der von einem anderen Benutzer bearbeiteten und abgeglichenen Version dar.
• Die gemeinsame Vorgängerversion ist die Repräsentation des Features und der zugehörigen Attribute in deren Zustand in der Datenbank. Dies entspricht dem Zustand des Features und der Attribute vor sämtlichen Änderungen.

Ein roter Punkt links vom Feldnamen kennzeichnet einen Konflikt. Wenn beispielsweise die Geometrie des Features in verschiedenen Versionen bearbeitet wurde, wird ein roter Punkt neben dem Feld "Shape" angezeigt.

Wenn weitere Attributfelder in Konflikt stehen würden, wird neben diesen ebenfalls ein roter Punkt angezeigt. Wenn ein Feature in einer der Versionen gelöscht wurde, wird "<Gelöscht>" als Attributwert dieser Version angezeigt.

Wenn Sie die in Konflikt stehenden Attribute und Werte für alle Repräsentationen eines Features anzeigen, können Sie die Unterschiede zwischen den Attributwerten erkennen und leichter entscheiden, welche Repräsentation der Daten beibehalten werden soll.

Anzeigen von Konflikten

Wenn Sie im Dialogfeld auf die Schaltfläche "Konfliktanzeige" klicken, werden unten im Dialogfeld zwei Repräsentationen der in Konflikt stehenden Features angezeigt: die Version vor dem Abgleich und die Konfliktversion.

Mit den Dropdown-Listen unter den einzelnen Repräsentationen können Sie zwischen drei unterschiedlichen Repräsentationen der in Konflikt stehenden Features wechseln: Version vor dem Abgleich, Konfliktversion und gemeinsame Vorgängerversion. Beachten Sie, dass sich diese nur unterscheiden, wenn die Geometrien der Features in Konflikt stehen.

Unter jeder Repräsentation wird eine Werkzeugleiste angezeigt, mit deren Werkzeugen Sie navigieren und die entsprechende Repräsentation identifizieren können.

Sie können zu einer bestimmten Version eines in Konflikt stehenden Features auf der Karte zoomen, indem Sie in der Liste mit der rechten Maustaste darauf klicken und anschließend auf "Auf Version vor dem Abgleich zoomen", "Auf Konfliktversion zoomen"oder "Auf gemeinsame Vorgängerversion zoomen" klicken.

Wenn Geometriekonflikte bestehen, können Sie auch unterschiedliche Repräsentationen der Karte anzeigen, indem Sie im Listenfeld mit der rechten Maustaste auf das Feld "Shape" und anschließend auf "Anzeige" klicken.

Dadurch wird das Dialogfeld "Einstellungen: Konfliktanzeige" geöffnet. Klicken Sie auf die Repräsentation, die Sie auf der Karte anzeigen möchten.

Nachdem Sie auf OK geklickt haben, wird auf der Karte Folgendes angezeigt:

• Die Repräsentation in der Konfliktversion (Zielversion) wird rot dargestellt.
• Die Repräsentation vor dem Abgleich wird grün dargestellt.
• Die Repräsentation in der gemeinsamen Vorgängerversion wird blau dargestellt.

In der folgenden Abbildung wird veranschaulicht, was bei den oben angegebenen Einstellungen für die Konfliktanzeige auf der Karte angezeigt wird:

Wenn im Dialogfeld "Einstellungen: Konfliktanzeige" nur "Aktuelle Version darstellen" aktiviert wurde, wird auf der Karte beispielsweise Folgendes angezeigt:

Wenn Sie die Konflikte angezeigt haben, können Sie diese als gesehen markieren oder eine Ersetzungsoption zum Lösen des Konflikts auswählen.

"Als gesehen markieren" oder "Als nicht gesehen markieren"

Wie im Abschnitt "Ermitteln der in Konflikt stehenden Felder oder Zeilen" erwähnt wurde, können Sie ein Feature als gesehen markieren. Damit geben Sie an, dass Sie den Konflikt überprüft haben, derzeit aber keine Ersetzungsoption auswählen möchten. Sie können verfolgen, welche Features Sie in der Liste überprüft haben, weil die als gesehen markierten Features nicht mehr fett formatiert sind.

Wenn Sie einen Feature-Konflikt später behandeln möchten, können Sie in der Konfliktliste mit der rechten Maustaste auf die ObjectID und dann auf "Als nicht gesehen markieren" klicken. Auf diese Weise wird das Feature wieder fett formatiert.

Lösen von Konflikten

• Attributersetzung
• Feature-Ersetzung
• Ersetzung auf Klassenebene
• Vollständige Ersetzung
• Geometrien zusammenführen

  Dies erfolgt auf Feldebene und ist ausdrücklich mit einem Shape-Attribut verbunden. Die Option zum Zusammenführen von Geometrien ist verfügbar, wenn ein Konflikt vorliegt, der das Feld "Shape" betrifft. Wenn zwei Benutzer die Geometrie desselben Features, jedoch nicht denselben räumlichen Bereich des Features bearbeiten, haben sie die Option, den Konflikt zu lösen, indem sie die Geometrien zusammenführen und beide Bearbeitungen annehmen.

  Die Option zum Zusammenführen von Geometrien ist nur im Kontextmenü des Feldes "Shape" verfügbar.
  Nach dem Zusammenführen von Geometrien ist das Endergebnis ein Feature, dass die Änderungen von beiden Benutzern enthält:
  Wenn die Änderungen eines Benutzers in den gleichen Bereich fallen, der auch von dem anderen Benutzer bearbeitet wurde, überlappen die bearbeiteten Bereiche. Zwar kann die Option zum Zusammenführen von Geometrien verfügbar sein, ihre Ausführung schlägt aber fehl. In diesem Fall wird die folgende Fehlermeldung angezeigt:

Konflikte in geometrischen Netzwerken

Wenn Sie Netzwerk-Features bearbeiten, können Konflikte durch Änderungen am geometrischen Netzwerk oder am logischen Netzwerk hervorgerufen werden.

Wenn Sie beispielsweise einer Leitung eine Absperrarmatur hinzufügen, wird die Leitung nicht physisch im geometrischen Netzwerk, sondern im logischen Netzwerk geteilt. Daher wird sie logisch bearbeitet, ohne dass direkt die Geometrie der Leitung bearbeitet wird. Wenn in der Zielversion, mit der Sie abgleichen, die Leitung ebenfalls verändert wurde, dann führt die neu eingefügte Armatur zu einem Konflikt mit der Leitung.

Die Überprüfung eines Konflikts, an dem Feature-Classes aus einem geometrischen Netzwerk beteiligt sind, erfordert Kenntnisse darüber, wie der Befehl "Ersetzen durch" im Dialogfeld "Konflikte" die vorhandene Netzwerk-Topologie in der Editiersitzung aktualisiert.

Im oben aufgeführten Beispiel für die Absperrarmaturen einer Leitung haben zwei Benutzer die Wasserleitung geändert, einer durch Änderung eines Attributs und der andere durch Einfügen einer neuen Armatur. Zur Überprüfung des Konflikts werden lediglich die Unterschiede untersucht, um festzustellen, dass der Konflikt gültig und keine weitere Aktion erforderlich ist. Da die Leitung das korrekte Attribut für den Durchmesser enthält und die neue Armatur korrekt mit der Leitung verbunden ist, sind keine weiteren Schritte erforderlich. Es gibt jedoch Fälle, in denen durch das Lösen von Konflikten, an denen eine Junction-Feature-Class beteiligt ist, auch die verbundenen Netzwerkkanten aktualisiert werden.

Konflikte in Feature-bezogener Annotation

Beim Arbeiten mit einer Feature-bezogenen Annotation müssen Sie sich einer Regel bewusst sein: Wenn ein Feature ersetzt wird, das eine Feature-bezogene Annotation aufweist, werden sowohl das Feature als auch die Annotation durch das neue Feature bzw. die neue Annotation ersetzt. Daher müssen Sie die neue Annotation möglicherweise weiter bearbeiten, damit nicht zwei Annotations vorliegen.

Beispiel: Es besteht ein Konflikt, bei dem ein Feature verschoben und seine Annotation anders platziert wurden. In der Konfliktversion wurden die gleichen Änderungen durchgeführt, das Feature verschoben und die Annotation gedreht. Wenn Sie das Feature durch das Feature in der Konfliktversion ersetzen, wird die vorhandene Feature-bezogene Annotation gelöscht, das in Konflikt stehende Feature wird eingefügt und eine neue Annotation wird erstellt. Sie müssen die neue Annotation dann bearbeiten, indem Sie sie nach Bedarf verschieben und drehen.

Möglicherweise tritt auch folgende Situation auf: Ein anderer Bearbeiter hat ein Feature in der Default-Version der Geodatabase gelöscht, wodurch auch die zugehörige Feature-bezogene Annotation gelöscht wurde. Sie haben die eben gelöschte Annotation in einer Child-Version der Geodatabase bearbeitet. Wenn Sie beim Abgleich entscheiden, das Feature durch die Editierversion zu ersetzen, wird das in der Default-Version gelöschte Feature und dessen zugehörige Annotation ersetzt. Zudem erhalten Sie die Annotation aus Ihrer Editiersitzung, wodurch Sie über zwei Annotations für dasselbe Feature verfügen.

Konflikte in Beziehungen

Beziehungen weisen Abhängigkeiten auf, die einer Feature-bezogener Annotation ähneln. Wenn ein Feature aus einer ursprünglichen Beziehungsklasse gelöscht wird, kann dies eine Meldung auslösen, die darauf hinweist, dass ein Feature aus der Zielbeziehungsklasse gelöscht werden soll. Daher müssen Sie sich der Folgen bewusst sein, zu denen das Bearbeiten von Konflikten mit Feature-Classes, die an Beziehungsklassen beteiligt sind, führen kann.

Im Folgenden ist ein Beispiel eines Konflikts dargestellt, der zwischen Beziehungsklassen auftreten kann:

• Sie aktualisieren das Primärschlüsselfeld in der Ursprungsklasse, wodurch die Beziehung in Version A aufgehoben wird.
• Gleichzeitig aktualisieren Sie das auf die Zielklasse bezogene Feature in Version B.
• Da die Zielklasse von der ursprünglichen Klasse abhängig ist, wird beim Abgleichen der Versionen ein Konflikt festgestellt.

Weiteres Beispiel:

• In einem Feature-Dataset zu Stromversorgern löschen Sie einen Mast mit einer Beziehung zu einer Umspannstation, wodurch die zugehörige Umspannstation ebenfalls gelöscht wird.
• In einer anderen, gleichzeitig stattfindenden Editiersitzung ändert ein Bearbeiter die Attribute der Umspannstation, die Sie eben indirekt durch das Löschen des zugehörigen Mastes gelöscht haben.
• Beim Abgleichen der Änderungen wird ein Konflikt zwischen dem Aktualisieren und dem Löschen entdeckt.

Wenn in diesem letzten Beispiel ein zweiter Bearbeiter alle Konflikte durch die Repräsentationen in der Editiersitzung ersetzt hat, werden der Mast und die Umspannstation, die in Ihrer Editiersitzung gelöscht wurden, neu erstellt. Zudem wird die Umspannstation aus der Sitzung des zweiten Bearbeiters erstellt, wodurch Sie über zwei Umspannstationen verfügen. Auf der Karte können Sie dies möglicherweise gar nicht erkennen, da die Umspannstationen in diesem Fall übereinander positioniert sind. In der Attributtabelle sind jedoch zwei Datensätze für die Umspannstation vorhanden.

Konflikte in Topologien

Da Features in Feature-Classes, die an einer Topologie beteiligt sind, die gleiche Geometrie wie andere Features aufweisen können, unterscheidet sich die Überprüfung von Konflikten zwischen verschiedenen Versionen topologischer Feature-Classes vom Ersetzen in Konflikten mit Simple-Feature-Classes. Sie unterscheidet sich außerdem von der Ersetzung in Konflikten mit geometrischen Netzwerken, Beziehungsklassen und Feature-bezogener Annotation.

Wenn eine Feature-Class, die Teil einer Topologie ist, bearbeitet wird, können gleichzeitig andere in topologischer Beziehung stehende Features geändert werden. Die geänderten Features können derselben Feature-Class oder einer bzw. mehreren anderen Feature-Classes angehören. Zur einfacheren Erkennung neuer Topologiefehler, die durch die Bearbeitung entstanden sein können, zeichnen Topologien die Bereiche, in denen eine Bearbeitung erfolgte, als nicht überprüfte Bereiche auf. Durch die Bearbeitung von Features in einer Topologie werden nicht überprüfte Bereiche erzeugt.

Neue Topologiefehler können auftreten, wenn die bearbeiteten Parent- und Child-Versionen abgeglichen werden. Dies gilt selbst dann, wenn die Fehlerbereiche in den einzelnen Versionen überprüft wurden und frei von Fehlern sind. Um solche Topologiefehler zu erkennen, werden die geänderten Bereiche in einer Child-Version alle in den Status "nicht überprüft" zurückgesetzt, nachdem Änderungen aus der Parent-Version im Zuge eines Abgleichs eingebracht wurden. Nach dem Abgleich können diese Bereiche erneut überprüft und eventuelle Fehler erkannt werden.

Auch durch einen Abgleich von zwei Versionen, die keine aktiven nicht überprüften Bereiche enthalten, können nicht überprüfte Bereiche erzeugt werden. Alle nicht überprüften Bereiche in der Child-Version, ob sie validiert wurden oder nicht, gelten nach dem Versionsabgleich als nicht überprüfte Bereiche. Im Allgemeinen gilt beim Versionsabgleich:

• Nicht überprüfte Bereiche, die die Child-Version von der Parent-Version geerbt hat, gelten auch nach erfolgter Validierung in der Child-Version nach dem Abgleich als nicht überprüfte Bereiche.
• Nicht überprüfte Bereiche, die für ein neues, geändertes oder gelöschtes Feature in der Child-Version erzeugt wurden, gelten auch nach erfolgter Validierung nach dem Abgleich als nicht überprüfte Bereiche.