Wenn Sie eine Karte herunterladen und offline nehmen, die einen editierbaren Feature-Service enthält, in dem für die traditionelle Versionierung registrierte Daten verwendet werden, wird aus der von den veröffentlichten Daten verwendeten Version eine Replikatversion erstellt. Außerdem wird ein Feature-Service-Replikat erstellt und mit der Replikatversion verknüpft. Wenn ein Client Änderungen mit dem Feature-Service-Replikat synchronisiert, werden die Änderungen auf die neue Replikatversion angewendet. Um die Änderungen in die veröffentlichte Version zu übernehmen und für andere freizugeben, sind deshalb zusätzlich die Vorgänge Abgleichen und Zurückschreiben erforderlich.
Wenn die Karte einen schreibgeschützten Feature-Service enthält (nur "Abfrage" und "Synchronisieren" sind im Feature-Service aktiviert) und der Feature-Service versionierte Daten enthält, wird beim Herunterladen der Karte keine Replikatversion erstellt. Entsprechend wird keine Replikatversion, wenn Daten während der Workflows einer verteilten Kollaboration kopiert werden. Wenn Clients sich in diesen Fällen mit dem Feature-Service synchronisieren, haben sie Zugriff auf alle an den Quelldaten erfolgten Änderungen.
Hinweis:
Selbst wenn der Feature-Service schreibgeschützt ist (also nur "Abfrage" und "Synchronisieren" aktiviert sind), muss der Datenbankbenutzer, der beim Veröffentlichen eine Verbindung zur Geodatabase herstellt, über Berechtigungen zum Bearbeiten der Daten verfügen.
Um dem Feature-Service-Besitzer oder ArcGIS Server-Administrator die Wahl zu ermöglichen, in welcher Weise traditionelle Versionen für einen bestimmten editierbaren Feature-Service erstellt werden sollen, gibt es die zwei folgenden Möglichkeiten. Diese Optionen werden beim Veröffentlichen des Feature-Service vom Publisher festgelegt.
Für jede Offline-Karte eine Version erstellen
Dies ist die Standardoption. Bei Wahl dieser Option wird jedes Mal, wenn eine Karte mit einem editierbaren Feature-Service offline genommen wird, eine Replikatversion aus der veröffentlichten Version generiert. Der Name der Replikatversion enthält die folgenden Angaben:
- den Namen des Benutzers, der die Karte herunterlädt
- den Namen des Feature-Service
- eine eindeutige Kennung (ID)
Mit diesen drei Komponenten wird ein eindeutiger Name der Replikatversion sichergestellt. Wenn beispielsweise ein Benutzer namens Bob eine Karte herunterlädt, die den Feature-Service NetFS enthält, dann könnte der Name der erstellten Replikatversion Bob_NetFS_1404578882000 lauten. Wenn derselbe Benutzer die Karte mehrfach herunterlädt (beispielsweise mit mehr als einem Gerät), werden bei der Synchronisierung von jedem Gerät verschiedene Replikatversionen verwendet. So ist der Zugriff eines Geräts auf Änderungen, die über andere Geräte vorgenommen wurden, nicht möglich. Neu heruntergeladene Karten entsprechen jedoch der veröffentlichten Version. Wenn derselbe Benutzer die Karte mehrfach herunterlädt (beispielsweise mit mehr als einem Gerät), werden bei der Synchronisierung von jedem Gerät verschiedene Replikatversionen verwendet. Da heruntergeladene Karten von der verwendeten Anwendung zur Offline-Bearbeitung heruntergenommen werden, lassen sich ihre Replikatversionen abgleichen, zurückschreiben und löschen.
Hinweis:
Wenn Sie den Feature-Service mit aktivierter Synchronisierung auf einer eigenständigen ArcGIS Server-Site ohne einzelne Benutzerkonten veröffentlicht haben, lautet der Name der Replikatversion "Esri_Anonymous_<Feature-Service-Name>_<ID>".
Replikatversionsnamen sind auf 30 Zeichen begrenzt. Der Feature-Service-Teil des Namens wird entsprechend gekürzt.
Für jeden Benutzer eine Version erstellen
Bei Wahl dieser Option wird für jeden Benutzer, der eine Karte herunterlädt, die einen editierbaren Feature-Service enthält, eine Replikatversion generiert. Wenn z. B. dieselbe Karte von 10 Benutzern heruntergeladen wird, dann werden 10 Replikatversionen erzeugt. Jede Replikatversion gehört zu einem bestimmten Benutzer, und der Name der Replikatversion beruht auf dem Benutzernamen und dem Service-Namen (z. B. Joe_InspectionFS). Wenn ein Benutzer die Karte mehrfach herunterlädt (beispielsweise mit mehr als einem Gerät), wird bei der Synchronisierung von jedem Gerät jeweils dieselbe Replikatversion verwendet. So hat ein Gerät Zugriff auf Bearbeitungen von anderen Geräten. Neu heruntergeladene Karten sind jedoch nur so aktuell wie zum letzten Abgleichszeitpunkt der Replikatversion des Benutzers. Eine Replikatversion eines Benutzers bleibt die gesamte Nutzungsdauer einer heruntergeladenen Karte über bestehen.
Hinweis:
Wenn Sie diese Option nutzen, sollten Sie entweder die ArcGIS Server-Site mit einem Portal verbinden oder Benutzerkonten in ArcGIS Server konfigurieren. Wenn Sie dies unterlassen, erhält die erstellte Replikatversion den Namen Esri_Anonymous_<Feature-Service-Name>, und jeder Benutzer, der sich mit dem Portal verbindet, um die Webkarte mit dem Feature-Service offline zu nehmen, wird dieselbe Replikatversion nutzen.
Beispiel-Workflows
In den folgenden Beispiel-Workflows werden die in den beiden vorangegangenen Abschnitten beschriebenen Versionsoptionen verwendet:
- Karten zwecks Datenverwaltung herunterladen
- Karten für ein Projekt von kurzer Dauer herunterladen
- Karten für ein fortdauerndes Projekt herunterladen
Die folgende Tabelle enthält einen Vergleich der Komponenten der einzelnen Workflows:
| Download zwecks Datenverwaltung | Download für ein Projekt von kurzer Dauer | Download für ein fortdauerndes Projekt | |
|---|---|---|---|
Geodatabase-Version, aus der der Feature-Service veröffentlicht wurde | |||
Es wird jeweils eine Replikatversion erstellt | Heruntergeladene Karte | Benutzer | Benutzer |
Anzahl der erstellten Replikatversionen | Viele | Wenige | Wenige |
Latenz zwischen Offline-Bearbeitung und -Aktualisierungen gegenüber der Default-Version | Niedrig | Hoch (1 Woche) | Hoch (täglich) |
In Qualitätsprüfung einbezogene Karten | Eine Karte | Alle Karten | Alle Karten |
Häufigkeit, mit der Replikatversionen gelöscht werden | Täglich | Bei Beendigung des Projekts | Nie |
Karten zwecks Datenverwaltung herunterladen
In diesem Workflow überprüft ein Organisationsmitglied mithilfe von ArcGIS Pro oder einer benutzerdefinierten mobilen App vor Ort Änderungen aus Karten mit Markups. In diesem Fall werden die Daten für die traditionelle Versionierung registriert, und die bearbeitenden Personen möchte eine Karte herunterladen, die die neuesten Daten aus der Default-Version der Geodatabase enthält. Zurück im Büro und bei bestehender Netzwerkverbindung synchronisieren die Mitarbeiter die vor Ort vorgenommenen Änderungen, entfernen die Karte, führen einen Abgleich der Replikatversion der Karte mit der Default-Geodatabase-Version durch und veranlassen das Zurückschreiben. Der Vorgang kann sich mehrmals am Tag wiederholen. Nach Abschluss jedes Vorgangs löschen die Mitarbeiter die Replikatversion.
Hierfür steht den Mitgliedern der Büromitarbeitergruppe im Organisationskonto der Firma eine Webkarte zur Verfügung. Mitarbeiter, die dieser Gruppe angehören, können mithilfe der App, die auf einem mobilen Gerät im internen Netzwerk im Büro ausgeführt wird, auf die Webkarte zugreifen. Vor Verlassen des Büros lädt der Mitarbeiter die Karte in die App herunter. Vor Ort kann er dann die angeforderten Aktualisierungen ohne Netzwerkverbindung überprüfen. Zurück im Büro werden die Korrekturen des Mitarbeiters mit dem Feature-Service synchronisiert, mit der Default-Version abgeglichen und in diese zurückgeschrieben.
In den folgenden Abschnitten wird dieser Workflow beschrieben:
- Einen Feature-Service veröffentlichen
- Eine Webkarte erstellen
- Herunterladen der Webkarte
- Synchronisieren von Änderungen
Einen Feature-Service veröffentlichen
Um die Webkarte erstellen zu können, muss zunächst ein Feature-Service veröffentlicht werden.
Der Publisher startet ArcGIS Pro und fügt einer Karte Daten aus der Default-Version hinzu. In diesem Beispiel enthalten die Daten neue Sensoren aus einer Feature-Class in der Enterprise-Geodatabase des Unternehmens. Die Feature-Class ist als versioniert registriert.
Der Publisher veröffentlicht einen Feature-Layer namens NetFS, der registrierte Daten aus ArcGIS Pro referenziert.
Während des Veröffentlichungsvorgangs bearbeitet der Publisher die folgenden Einstellungen auf der Registerkarte Konfiguration des Feature-Layers, damit der Layer offline verwendet und bearbeitet werden kann:
- Unter Bearbeitung aktivieren und Editoren Folgendes erlauben:, Features hinzufügen, aktualisieren und löschen wird die vollständige Bearbeitung der Daten ermöglicht.
- Synchronisierung aktivieren ermöglicht die Offline-Verwendung des Layers.
- Unter Synchronisieren, Für jede heruntergeladene Karte eine Version erstellen wird für die Offline-Karte eine eindeutig benannte Replikatversion erstellt, wenn der Außendienstmitarbeiter die Karte herunterlädt. Diese Replikatversion wird dann verwendet, wenn der Mitarbeiter Änderungen synchronisiert.
Der Publisher gibt den Service auch für die Gruppe der Büromitarbeiter frei, sodass die Daten auch für andere Mitglieder der Organisation zugänglich sind.
Eine Webkarte erstellen
Nachdem Sie einen Feature-Service erstellt haben, können Sie als nächsten Schritt eine Webkarte erstellen. Der Publisher meldet sich hierfür bei seiner Organisation (ArcGIS Enterprise bzw. ArcGIS Online) an, erstellt dann eine Webkarte, fügt der Karte den Feature-Layer hinzu und gibt die Karte für die Gruppe der Büromitarbeiter frei. Die Eigenschaft "Offline-Modus" der Webkarte wird aktiviert, um die Karte für die Offline-Verwendung verfügbar zu machen. Jetzt können die Mitglieder der Büromitarbeitergruppe die Karte herunterladen.
Herunterladen der Webkarte
Die Mitarbeiter können die verfügbare Webkarte in eine App auf ihrem mobilen Gerät herunterladen, um angeforderte Aktualisierungen vor Ort zu überprüfen. Hierfür startet ein Mitarbeiter namens Bob die App auf seinem mobilen Gerät, während dieses mit dem Netzwerk verbunden ist. Er meldet sich bei der Organisation an und lädt die Webkarte auf sein Gerät herunter.
Zu Beginn des Downloads wird eine Replikatversion mit dem Namen Bob_NetFS_1404578882000 aus der veröffentlichten Version (Default) in der Backend-Geodatabase erstellt. Da für den Service eingestellt wurde, für jede heruntergeladene Karte eine Version zu erstellen, wird ein eindeutiger Versionsname angelegt. Der Name setzt sich zusammen aus dem Anmeldenamen des Außendienstmitarbeiters (Bob), dem Namen des Feature-Service (NetFS) und einer eindeutigen ID. Diese Replikatversion wird zum Synchronisieren der heruntergeladenen Karte verwendet.
Anschließend werden die Daten auf das Gerät heruntergeladen, und die App wechselt die Karte, um die lokalen Daten zu referenzieren. Nun können an der Karte Änderungen vorgenommen werden, ohne dass man dafür mit dem Netzwerk verbunden sein muss.
Synchronisieren von Änderungen
Vor Ort fällt Bob auf, dass sich einer der Sensoren auf der falschen Straßenseite befindet, also nicht ordnungsgemäß positioniert ist. Bob nimmt diese Korrektur in der mobilen App vor.
Im Laufe des Tages könnte Bob andere Standorte aufsuchen und weitere Korrekturen vornehmen. Bei verfügbarer Verbindung könnte Bob seine Änderungen auch von unterwegs synchronisieren. Zurück im Büro stellt Bob über das mobile Gerät eine Verbindung mit dem internen Netzwerk her und führt eine abschließende Synchronisierung durch. Auf diese Weise wird sichergestellt, dass alle vor Ort erfolgten Korrekturen in die Replikatversion Bob_NetFS_1404578882000 eingehen.
Nachdem nun alle Änderungen aus dem Außendienst mit der Quelle synchronisiert sind, entfernt Bob die lokale Karte aus der mobilen App und gibt das Gerät zurück. Durch den Vorgang des Entfernens der lokalen Karte wird die Replikatversion Bob_NetFS_1404578882000 mit dem Vermerk versehen, dass sie nicht länger mit einer Offline-Karte verknüpft ist. Bob stellt nun eine Verbindung zur Replikatversion Bob_NetFS_1404578882000 in ArcGIS Pro her, um sie mit der Default-Version abzugleichen und in diese zurückzuschreiben. Er wendet die attributbasierte Konflikterkennung an und löst eventuelle Konflikte manuell.
Da Bob nach dem Speichern der Änderungen zurück zur Default-Version wechselt, löscht er die Replikatversion Bob_NetFS_1404578882000.
Bob stellt fest, dass weitere Außendiensteinsätze erforderlich sind, um die Daten ordnungsgemäß zu aktualisieren. Für jeden dieser Einsätze muss eine neue Karte heruntergeladen und eine neue Bob_NetFS_<ID>-Replikatversion erstellt werden. Jede neue Replikatversion enthält die aktuellen Änderungen aus der Default-Version. Diese Replikatversionen verbleiben so lange in der Geodatabase, bis deren Zuordnung zu einer Karte aufgehoben wird, um sie abzugleichen und zurückzuschreiben.
Außer Bob können auch andere Mitarbeiter gleichzeitig ähnliche Aufgaben ausführen.
Nachdem Bobs Änderungen mit der Default-Version abgeglichen und in diese zurückgeschrieben wurden, löscht Bob seine Bob_NetFS_<ID>-Replikatversionen.
Karten für ein Projekt von kurzer Dauer herunterladen
In diesem Beispiel nehmen Außendienstmitarbeiter versionierte Daten offline, um Änderungen vorzunehmen. Die versionierten Daten in der Quell-Geodatabase referenzieren eine Projektversion, bei der es sich um eine Child-Version der Default-Version handelt.
Außendienstmitarbeiter synchronisieren ihre Änderungen täglich morgens und abends mit der Projektversion. Mithilfe eines nächtlichen Abgleich- und Zurückschreiben-Prozesses werden die Replikatversionen der Außendienstmitarbeiter mit den Änderungen ihrer Kollegen aktuell gehalten. Beim morgendlichen Synchronisationsvorgang sieht jeder Außendienstmitarbeiter die Änderungen der anderen. Wenn das Projekt abgeschlossen ist, wurden alle vor Ort vorgenommenen Änderungen synchronisiert und in die Projektversion eingespeist. Danach wird die Projektversion überprüft und mit der Default-Geodatabase-Version abgeglichen und in diese zurückgeschrieben. Zum Projektende löscht ein Mitarbeiter den Feature-Service und die Replikatversionen der Außendienstmitarbeiter.
In diesem Workflow beträgt die Latenz der Außendienstmitarbeiter nicht mehr als eine Woche.
Nachfolgend werden die Durchführungsschritte für diesen Workflow beschrieben:
- Einen Feature-Service veröffentlichen
- Eine Webkarte erstellen
- Herunterladen der Webkarte
- Synchronisieren von Änderungen
- Ausführen der nächtlichen Geodatabase-Verarbeitung
- Löschen der Offline-Karten und abschließendes Abgleichen und Zurückschreiben
Einen Feature-Service veröffentlichen
In diesem Beispiel muss ein Projektmanager Mitarbeiter zu Sensorinspektionen vor Ort schicken. Sensorinspektionen werden regelmäßig mehrmals im Jahr durchgeführt. Im Rahmen der Inspektionen überprüfen die Außendienstmitarbeiter die Sensoren auf Schäden und Zugänglichkeit und vermerken diese. Mithilfe dieser Angaben werden Reparaturen geplant. Zudem lässt sich erkennen, welche Sensoren gut zugänglich sind. Die Projektdauer wird für etwa eine Woche angesetzt. Für die Datenerfassung erhält jeder Außendienstmitarbeiter ein Tablet, auf dem eine benutzerdefinierte mobile App installiert ist.
Der Projektmanager plant für dieses Projekt die Erstellung und Freigabe einer Webkarte für die Inspektion von Sensoren im Organisationskonto des Unternehmens. Die Webkarte referenziert dabei einen Feature-Service, der auf der lokalen ArcGIS Server-Site des Unternehmens ausgeführt wird.
Zum Erstellen des Feature-Service fügt der Projektmanager einer Karte in ArcGIS Pro die Sensor-Feature-Class aus der Default-Version der Quell- Enterprise-Geodatabase hinzu. Die Feature-Class wurde für traditionelle Versionierung registriert. Die für die Inspektion markierten Sensoren sind gelb gefärbt.
Um die Arbeit zu organisieren, erstellt der Projektmanager eine Version aus der Default-Geodatabase-Version. Der Manager legt für die Child-Version den Namen "Inspection" fest und ändert die Karte, um diese Version zu referenzieren.
Anschließend veröffentlicht der Projektmanager einen Feature-Service namens "InspectionFS" über ArcGIS Pro.
Während des Veröffentlichungsvorgangs bearbeitet der Projektmanager die folgenden Einstellungen auf der Registerkarte Konfiguration des Feature-Layers, damit der Layer offline verwendet und bearbeitet werden kann:
- Unter Bearbeitung aktivieren und Editoren Folgendes erlauben:, Features hinzufügen, aktualisieren und löschen wird die vollständige Bearbeitung der Daten ermöglicht.
- Synchronisierung aktivieren ermöglicht die Offline-Verwendung des Layers.
- Unter Synchronisieren, Für jeden Benutzer eine Version erstellen wird für den Mitarbeiter eine Replikatversion erstellt, wenn eine Karte zum ersten Mal von einem Außendienstmitarbeiter heruntergeladen wird. Diese Replikatversion wird verwendet, wenn der Mitarbeiter Änderungen synchronisiert.
Erstellen einer Webkarte
Nach der Veröffentlichung des Feature-Service erstellt der Projektmanager im ArcGIS Enterprise-Portal eine Webkarte und gibt diese für eine Gruppe frei, die alle Außendienstmitarbeiter umfasst.
Der Projektmanager geht dazu wie folgt vor:
- Melden Sie sich bei der Organisation an.
- Erstellen Sie eine Webkarte.
- Fügen Sie der Webkarte den neu veröffentlichten Feature-Service hinzu.
- Speichern Sie die Webkarte.
- Geben Sie die Webkarte und den Feature-Service für die Gruppe frei, der die Außendienstmitarbeiter angehören.
- Aktivieren Sie die Eigenschaft "Offline-Modus" in der Webkarte, um die Karte für die Offline-Verwendung verfügbar zu machen.
Herunterladen der Webkarte
Jeder Außendienstmitarbeiter kann auf die Webkarte zugreifen, indem er sich bei bestehender Netzwerkverbindung über die mobile App bei seinem Konto in der Organisation anmeldet und die Karte zusammen mit den Daten auf sein Gerät herunterlädt.
In der folgenden Abbildung beginnt einer der Außendienstmitarbeiter (Joe) mit dem Download-Vorgang.
Anschließend wählt Joe die Ausdehnung und die Grundkarten-Auflösung für die Karte.
Zu Beginn des Downloads wird eine Replikatversion mit dem Namen "Joe_InspectionFS" aus der veröffentlichten Version in der Quell-Geodatabase erstellt. Da der Feature-Service so eingerichtet ist, dass für jeden Benutzer eine Replikatversion erstellt wird, setzt sich der Versionsname aus dem Anmeldenamen des Außendienstmitarbeiters (Joe) und dem Namen des Services, aus dem die Version erstellt wurde (InspectionFS), zusammen. Diese Replikatversion wird zum Synchronisieren der heruntergeladenen Karte verwendet.
Hinweis:
Jedes Mal, wenn Joe aus dem InspectionFS-Service eine Karte herunterlädt, verweist diese auf die Joe_InspectionFS-Replikatversion. Beispielsweise muss Joe irgendwann die lokale Karte entfernen und sie mit einer größeren Ausdehnung neu erstellen. Wenn Joe die Karte erneut herunterlädt, sind alle Bearbeitungen, die er zuvor mit der Replikatversion "Joe_InspectionFS" synchronisiert hat, in der Karte sichtbar.
Nachdem die Karte und die Daten heruntergeladen wurden, wechselt die mobile App die Karte, um die lokalen Daten zu referenzieren. Nun kann Joe die Karte bearbeiten, ohne dass er dafür mit dem Netzwerk verbunden sein muss.
Eine zweite Außendienstmitarbeiterin (Mary) führt dieselben Schritte wie Joe durch. Auf diese Weise wird die Replikatversion Mary_InspectionFS in der Quell-Geodatabase angelegt.
Synchronisieren von Änderungen
Joe ist heute im Ostteil der Karte unterwegs. Im Zuge der Inspektionen aktualisiert Joe die Statusangaben der Sensor-Features. Hat der Sensor die Inspektion bestanden, wird er grün markiert. Ist er beschädigt und muss repariert werden, wird er rot markiert.
Am Ende des Arbeitstages stellt Joe über das mobile Gerät eine Verbindung zum Netzwerk her und synchronisiert seine Änderungen mit dem Feature-Service. Auf diese Weise gelangen die Änderungen aus der Replikatversion Joe_InspectionFS in die Quell-Geodatabase.
Am Ende des Tages synchronisiert auch Mary ihre Ergebnisse aus der Sensorinspektion im Westteil der Karte.
Ausführen der nächtlichen Geodatabase-Verarbeitung
Am Abend läuft ein automatischer Vorgang, bei dem die Änderungen der Außendienstmitarbeiter abgeglichen und zurückgeschrieben werden. Bei dem Vorgang wird jede Replikatversion mit der Version "Inspection" abgeglichen und in diese zurückgeschrieben. Hierbei kommt eine Konfliktlösungsmethode zum Einsatz, bei der die letzte enthaltene Änderung beibehalten wird und die Konflikterkennung auf Attributen basiert.
Wenn alle vor Ort gemachten Änderungen in die Version "Inspection" eingegangen sind, werden Validierungsskripte an den Daten ausgeführt. Diese Skripte ermitteln Änderungen mit ungültigen Werten oder außerhalb der Grenzwerte liegenden Features und korrigieren diese. Beispielsweise muss das Statusfeld einen gültigen Statuswert aufweisen. Ist der Wert ungültig, wird er auf Prüfung erforderlich zurückgesetzt und durch gelbe Punkte symbolisiert. Nach Abschluss der Validierung gleicht der Prozess die Replikatversionen der Außendienstmitarbeiter mit der Version "Inspection" ab, sodass alle Versionen auf dem aktuellen Stand sind.
Beim Synchronisieren am nächsten Morgen sehen Joe und Mary jeweils die Aktualisierungen des anderen.
Hinweis:
Über Nacht kann außerdem ein Abgleich mit der Default-Version erfolgt sein, um Änderungen zu berücksichtigen, die seit Projektbeginn an der Default-Version vorgenommen wurden. Der Projektmanager hat jedoch entschieden, den Abgleich mit der Default-Version erst am Ende des Projekts durchzuführen. Auf diese Weise lassen sich bereits im Vorfeld Konflikte erkennen und manuell überprüfen, bevor sie in die Default-Version gelangen. Wird dieser Vorgang vor dem Ende des Projekts ausgeführt, können die Mitarbeiter zusätzliche Änderungen an den betreffenden Features vornehmen, sodass sie im abschließenden Abgleichvorgang nicht als Konflikte erscheinen.
Beachten Sie auch, dass das automatische Abgleichen und Zurückschreiben der Änderungen der Außendienstmitarbeiter in diesem Beispiel jede Nacht erfolgt. Das bedeutet, dass ein Außendienstmitarbeiter die neuesten Änderungen seiner Kollegen erst am nächsten Tag zu sehen bekommt. Um diese Latenz zu verringern, kann der Vorgang häufiger ausgeführt werden. Erfolgt er beispielsweise stündlich, könnte ein Außendienstmitarbeiter jede Stunde synchronisieren, um die aktuellen Änderungen der anderen zu erhalten.
Löschen der heruntergeladenen Karten und abschließendes Abgleichen und Zurückschreiben
Der vorstehend beschriebene Ablauf wird während der einwöchigen Projektdauer fortgesetzt. Das Projekt ist abgeschlossen, wenn alle Sensoren überprüft wurden. Am Ende des Projekts werden die Außendienstmitarbeiter gebeten, ihre letzten Änderungen zu synchronisieren und die lokale Karte aus der mobilen App zu entfernen. Nach dem Entfernen der lokalen Karten aus der mobilen App sind die Replikatversionen der Außendienstmitarbeiter nicht mehr mit einer heruntergeladenen Karte verknüpft. Anschließend beendet der Projektmanager den Feature-Service und löscht ihn.
Der Projektmanager führt abschließende Abgleich- und Zurückschreibevorgänge für die Replikatversionen aller Außendienstmitarbeiter aus und löscht jede Replikatversion. Der Projektmanager nimmt nun den Abgleich der Version "Inspection" mit der Default-Version vor und schreibt sie zurück. Während dieses Vorgangs werden Konflikte vom Projektmanager manuell geprüft und gelöst. Nach Abschluss dieses Vorgangs stehen die aktuellen Inspektionsdaten in der Default-Version allen Mitarbeitern zur Verfügung. Im letzten Schritt löscht der Projektmanager die Version "Inspection".
Karten für ein fortdauerndes Projekt herunterladen
Dieser Beispielworkflow ähnelt dem vorstehend beschriebenen Workflow (Karten für ein Projekt von kurzer Dauer herunterladen) insofern, als die Außendienstmitarbeiter unterwegs vorgenommene Änderungen synchronisieren. Sie verbinden sich mit dem Netzwerk und synchronisieren täglich morgens und abends. Ähnlich dem vorherigen Workflow wird in diesem Workflow der Feature-Service nicht direkt aus der Default-Version, sondern aus einer Qualitätssicherungsversion veröffentlicht. Das heißt, dass ein zusätzlicher Abgleich und zusätzliches Zurückschreiben erforderlich sind. Im Gegensatz zum vorherigen Workflow verbleibt die Qualitätssicherungsversion jedoch in der Geodatabase. Sie ist nicht auf die Projektdauer beschränkt.
Nachfolgend werden die Durchführungsschritte für diesen Workflow beschrieben:
- Veröffentlichen eines Feature-Service
- Erstellen einer Webkarte
- Herunterladen der Webkarte
- Synchronisieren von Änderungen
- Ausführen der nächtlichen Geodatabase-Verarbeitung
Veröffentlichen des Feature-Service
Der Projektmanager erstellt für dieses Projekt eine Webkarte für die Inspektion von Sensoren im Organisationskonto des Unternehmens und gibt diese frei. Die Webkarte referenziert dabei einen Feature-Service, der auf der lokalen ArcGIS Server-Site des Unternehmens ausgeführt wird.
Zum Erstellen des Feature-Service fügt der Projektmanager einer Karte in ArcGIS Pro die Sensor-Feature-Class aus der Default-Version der Quell- Enterprise-Geodatabase hinzu. Die Feature-Class wurde für traditionelle Versionierung registriert. Die für die Inspektion markierten Sensoren sind gelb gefärbt.
Um die Arbeit zu organisieren, erstellt der Projektmanager aus der Default-Version eine Child-Version und legt für diese den Namen "Inspection" fest. Der Manager ändert die Karte, um die Version "Inspection" zu referenzieren.
Anschließend veröffentlicht der Projektmanager einen Feature-Service namens "InspectionFS" aus der Karte in ArcGIS Pro.
Der Projektmanager aktiviert die Funktion Synchronisieren auf der Seite Service-Editor in ArcGIS Server Manager, da der Service in einer Offline-Karte verwendet werden soll. Ferner klickt er auf Erweiterte Optionen, um Feature-Service – Erweiterte Optionen anzuzeigen.
Unter Feature-Service – Erweiterte Optionen wählt der Projektmanager die Option Für jeden Benutzer eine Version erstellen. Mit dieser Option wird für jeden Außendienstmitarbeiter, der eine Karte erstmals herunterlädt, eine individuelle Replikatversion generiert. Diese Replikatversion wird dann verwendet, wenn der Mitarbeiter Änderungen synchronisiert.
Während des Veröffentlichungsvorgangs bearbeitet der Projektmanager die folgenden Einstellungen auf der Registerkarte Konfiguration des Feature-Layers, damit der Layer offline verwendet und bearbeitet werden kann:
- Unter Bearbeitung aktivieren und Editoren Folgendes erlauben:, Features hinzufügen, aktualisieren und löschen wird die vollständige Bearbeitung der Daten ermöglicht.
- Synchronisierung aktivieren ermöglicht die Offline-Verwendung des Layers.
- Unter Synchronisieren, Für jeden Benutzer eine Version erstellen wird für den Mitarbeiter eine Replikatversion erstellt, wenn eine Karte zum ersten Mal von einem Außendienstmitarbeiter heruntergeladen wird. Diese Replikatversion wird verwendet, wenn der Mitarbeiter Änderungen synchronisiert.
Erstellen einer Webkarte
Nach der Veröffentlichung des Feature-Service erstellt der Projektmanager im ArcGIS Enterprise-Portal eine Webkarte und gibt diese für eine Gruppe frei, die alle Außendienstmitarbeiter umfasst.
Der Projektmanager geht dazu wie folgt vor:
- Melden Sie sich bei der Organisation an.
- Erstellen Sie eine Webkarte.
- Fügen Sie der Karte den neu veröffentlichten Feature-Service hinzu.
- Speichern Sie die Webkarte.
- Geben Sie die Webkarte und den Feature-Service für die Gruppe frei, der die Außendienstmitarbeiter angehören.
- Aktivieren Sie die Eigenschaft "Offline-Modus" in der Webkarte, um die Karte für die Offline-Verwendung verfügbar zu machen.
Herunterladen der Webkarte
Jeder Außendienstmitarbeiter kann auf die Webkarte zugreifen, indem er sich bei bestehender Netzwerkverbindung über die mobile App bei seinem Konto anmeldet und die Karte zusammen mit den Daten auf sein Gerät herunterlädt.
In der folgenden Abbildung beginnt einer der Außendienstmitarbeiter (Joe) mit dem Download-Vorgang.
Joe wählt die Ausdehnung und die Auflösung für die Karte aus.
Zu Beginn des Downloads erstellt ArcGIS eine Replikatversion (Joe_InspectionFS) aus der veröffentlichten Version (Inspection) in der Quell-Geodatabase. Da der Feature-Service so eingerichtet ist, dass für jeden Benutzer eine Replikatversion erstellt wird, setzt sich der Versionsname aus dem Anmeldenamen des Außendienstmitarbeiters (Joe) und dem Namen des Services, aus dem die Version erstellt wurde (InspectionFS), zusammen. Diese Replikatversion wird für die Synchronisierung der Karte verwendet.
Hinweis:
Jedes Mal, wenn Joe aus dem InspectionFS-Service eine Karte herunterlädt, verweist diese auf die Joe_InspectionFS-Replikatversion. Beispielsweise muss Joe irgendwann die lokale Karte entfernen und sie mit einer größeren Ausdehnung neu erstellen. Wenn Joe die Karte erneut herunterlädt, werden alle Bearbeitungen, die zuvor mit der Replikatversion "Joe_InspectionFS" synchronisiert wurden, in der Karte angezeigt.
Nachdem die Daten und die Karte heruntergeladen wurden, wechselt die mobile App die Karte, um die lokalen Daten zu referenzieren. Nun kann Joe die Karte bearbeiten, ohne dass er dafür mit dem Netzwerk verbunden sein muss.
Eine zweite Außendienstmitarbeiterin (Mary) führt dieselben Schritte wie Joe durch. Auf diese Weise wird die Replikatversion Mary_InspectionFS in der Quell-Geodatabase angelegt.
Während Mary und Joe Änderungen vor Ort vornehmen, wird von einem Büromitarbeiter ein neuer Sensor zur Default-Geodatabase-Version hinzugefügt. Der neue Sensor gehört zu einem neuen Projekt in dem Gebiet. Sobald ein neuer Sensor installiert wurde, ist eine Inspektion erforderlich, weshalb er in Gelb angezeigt wird.
Synchronisieren von Änderungen
Joe ist heute im Ostteil der Karte unterwegs. Im Zuge der Sensor-Inspektion aktualisiert Joe den Status für die einzelnen Sensor-Features. Hat der Sensor die Inspektion bestanden, wird er grün markiert. Ist er beschädigt und muss repariert werden, wird er rot markiert.
Wenn das mobile Gerät am Ende des Arbeitstages mit dem Netzwerk verbunden wird, synchronisiert Joe seine Änderungen mit dem Feature-Service. Auf diese Weise gelangen die Änderungen aus der Replikatversion Joe_InspectionFS in die Quell-Geodatabase.
Am Ende des Tages synchronisiert auch Mary ihre Ergebnisse aus der Sensorinspektion im Westteil der Karte.
Ausführen der nächtlichen Geodatabase-Verarbeitung
Am Abend läuft ein automatischer Vorgang, bei dem die Änderungen der Außendienstmitarbeiter abgeglichen und zurückgeschrieben werden. Bei dem Vorgang wird jede unterwegs erstellte Replikatversion mit der Version "Inspection" abgeglichen und in diese zurückgeschrieben. Hierbei kommt eine Konfliktlösungsmethode zum Einsatz, bei der die letzte enthaltene Änderung beibehalten wird und die Konflikterkennung auf Attributen basiert.
Wenn alle vor Ort gemachten Änderungen in die Version "Inspection" eingegangen sind, werden Validierungsskripte an den "Inspection"-Daten ausgeführt. Diese Skripte ermitteln Änderungen mit ungültigen Werten oder außerhalb der Grenzwerte liegenden Features und korrigieren diese.
Hinweis:
Zu diesem Zeitpunkt sind Joes Änderungen bereits in die Replikatversion Mary_InspectionFS eingegangen, aber in der Replikatversion Joe_InspectionFS sind Marys Änderungen noch nicht enthalten. Das liegt daran, dass das Abgleichen und Zurückschreiben der Replikatversion Joe_InspectionFS zeitlich vor der Replikatversion Mary_InspectionFS erfolgt ist.
Der nächste Schritt im automatischen Prozess beinhaltet den Abgleich mit der und das Zurückschreiben der Version "Inspection" in die Default-Version. Der Prozess verwendet die attributbasierte Konflikterkennung und löst Konflikte automatisch. Durch den Abgleichvorgang werden die Änderungen aus der Default-Version (neuer Sensor) in die Version "Inspection" übernommen, und beim Zurückschreiben gelangen die Änderungen aus "Inspection" (Joes und Marys Änderungen) in die Default-Version.
Zum Abschluss des automatischen Vorgangs wird jede von den Außendienstmitarbeitern erstellte Replikatversion ein zweites Mal mit der Version "Inspection" abgeglichen. Jetzt sind alle Replikatversionen der Außendienstmitarbeiter auf dem aktuellen Stand.
Tipp:
Mittels Abgleich gelangen die neuesten Änderungen zu den Außendienstmitarbeitern; ein Zurückschreiben ist hingegen nicht erforderlich. In einigen Organisationen werden Änderungen möglicherweise in einem separaten Prozess in die Default-Version geschrieben, um die Änderungen auch für nicht an diesem Projekt beteiligte Nutzer zugänglich zu machen.
Wenn Joe und Mary am nächsten Morgen synchronisieren, sehen sie die von den anderen Außendienstmitarbeitern aktualisierten Sensoren sowie den neuen Sensor aus der Default-Version. Da sich der neue Sensor im östlichen Teil der Karte befindet, wird Joe den neuen Sensor inspizieren und die Ergebnisse synchronisieren. Nach Ausführung der nächtlichen Prozesse sind Joes Inspektionsdaten zum neuen Sensor am nächsten Tag in der Default-Version verfügbar.
Dieser Vorgang wird regelmäßig jeden Tag ausgeführt. Solange Joe und Mary ihre Sensor-Inspektionen noch nicht abgeschlossen haben, bleiben die Replikatversionen Joe_InspectionFS und Mary_InspectionFS erhalten. Wenn sie die Arbeit am Projekt beendet haben, können die Replikatversionen entfernt werden, nachdem Joe und Mary eine abschließende Synchronisierung vorgenommen, die Registrierung ihrer lokalen Karten aufgehoben und die Prozesse zum Abgleichen und Zurückschreiben der Replikatversionen Joe_InspectionFS und Mary_InspectionFS durchgeführt haben.